- Gói Lotusbail là một bản fork của thư viện WhatsApp Web API hợp pháp Baileys, đồng thời là một gói chứa mã độc đã được tải xuống hơn 56 nghìn lần trên npm trong 6 tháng
- Trong khi cung cấp các chức năng API hoạt động bình thường, nó đánh cắp thông tin xác thực WhatsApp, tin nhắn, danh bạ, tệp media và gửi về máy chủ của kẻ tấn công
- Dữ liệu được truyền đi sau khi trải qua nhiều lớp mã hóa và làm rối như RSA, AES, Base-91, LZString, cho phép né tránh giám sát bảo mật
- Gói này cài một cửa hậu thông qua mã ghép nối được hardcode, giúp thiết bị của kẻ tấn công được liên kết vĩnh viễn với tài khoản WhatsApp của người dùng
- Trường hợp này cho thấy mức độ tinh vi ngày càng cao của tấn công chuỗi cung ứng, đồng thời nhấn mạnh sự cần thiết của giám sát bảo mật dựa trên hành vi mà chỉ phân tích tĩnh không thể phát hiện
Tổng quan về gói Lotusbail
lotusbail là bản fork của @whiskeysockets/baileys hợp pháp, cung cấp nguyên vẹn chức năng WhatsApp Web API
- Việc gửi và nhận tin nhắn hoạt động bình thường, nên rất dễ khiến nhà phát triển cài đặt mà không nghi ngờ
- Gói này đã tồn tại trên npm trong 6 tháng và tại thời điểm bài viết vẫn còn có thể tải xuống
- Đằng sau chức năng thực tế là các hành vi độc hại như đánh cắp thông tin xác thực WhatsApp, chặn lấy tin nhắn, thu thập danh bạ, cài cửa hậu
Thông tin bị đánh cắp
- Bao gồm token xác thực và khóa phiên, toàn bộ lịch sử tin nhắn, danh sách liên hệ kèm số điện thoại, tệp media và tài liệu, cùng quyền truy cập cửa hậu duy trì lâu dài
- Mọi dữ liệu đều được mã hóa trước khi gửi tới máy chủ của kẻ tấn công
Cách thức hoạt động
Chức năng ngụy trang vẫn hoạt động thật
- Phần lớn các gói npm độc hại thường bị nhận ra dễ dàng do lỗi hoạt động hoặc mã đáng ngờ, nhưng Lotusbail ngụy trang bằng một API hoạt động bình thường
- Nó dựa trên thư viện Baileys hợp pháp và triển khai đầy đủ chức năng gửi nhận tin nhắn
- Vì vậy, một kỹ thuật social engineering đã được sử dụng để khiến nhà phát triển không nghi ngờ hành vi độc hại trong “mã đang chạy bình thường”
Đánh cắp và truyền dữ liệu
- Gói này hoạt động theo cách bao bọc client WebSocket giao tiếp với WhatsApp
- Trong quá trình xác thực, nó ghi lại thông tin xác thực; khi nhận hoặc gửi tin nhắn, nó sao chép toàn bộ nội dung
- Chức năng bình thường vẫn được giữ nguyên, chỉ khác là mọi dữ liệu đều bị gửi kép tới kẻ tấn công
- Dữ liệu bị đánh cắp được mã hóa để truyền đi bằng một triển khai RSA tùy biến
- Nó tồn tại tách biệt với mã hóa đầu cuối của chính WhatsApp và được dùng như mã hóa để né giám sát mạng
- Địa chỉ máy chủ không lộ trực tiếp trong mã, mà được giấu trong chuỗi cấu hình đã mã hóa
- Áp dụng 4 lớp làm rối gồm thao tác biến Unicode, nén LZString, mã hóa Base-91, mã hóa AES
Cài đặt cửa hậu
- Nó lạm dụng tính năng mã ghép nối thiết bị của WhatsApp để liên kết thiết bị của kẻ tấn công với tài khoản của người dùng
- Trong gói có chứa mã ghép nối hardcode được mã hóa bằng AES
- Khi người dùng xác thực, thiết bị của kẻ tấn công cũng được kết nối đồng thời, từ đó giành được quyền truy cập tài khoản lâu dài
- Kẻ tấn công có thể kiểm soát toàn bộ tài khoản, bao gồm đọc/gửi tin nhắn, tải xuống media, truy cập danh bạ
- Ngay cả khi xóa gói npm, thiết bị của kẻ tấn công vẫn tiếp tục được liên kết; chỉ khi ngắt liên kết thủ công tất cả thiết bị trong cài đặt WhatsApp mới có thể chặn được
Kỹ thuật né phân tích
- Mã có chứa 27 bẫy vòng lặp vô hạn, khiến quá trình thực thi bị dừng khi phát hiện công cụ gỡ lỗi
- Nó phát hiện debugger, tham số tiến trình, môi trường sandbox... để cản trở phân tích động
- Các đoạn mã độc có gắn chú thích, cho thấy dấu vết quản lý phát triển có hệ thống
Kết luận và hàm ý bảo mật
- Tấn công chuỗi cung ứng đang trở nên tinh vi hơn, với ngày càng nhiều trường hợp ngụy trang dưới dạng mã hoạt động bình thường
- Chỉ dựa vào phân tích tĩnh và kiểm chứng dựa trên uy tín thì khó phát hiện, cần có phân tích hành vi trong lúc chạy (behavioral analysis)
- Trường hợp Lotusbail là ví dụ khai thác lỗ hổng bảo mật kiểu “tin rằng mã an toàn chỉ vì nó chạy được”, cho thấy tầm quan trọng của việc xây dựng hệ thống giám sát hành vi runtime
- Nhóm nghiên cứu của Koi Security đã xác định được những mối đe dọa vượt qua quy trình kiểm chứng truyền thống nhờ các kỹ thuật phát hiện dựa trên runtime
1 bình luận
Ý kiến trên Hacker News
Mỗi khi xảy ra một vụ malware, thật khó chịu khi đội ngũ bảo mật lại đi theo hướng khóa dữ liệu quá mức
Việc tin nhắn WhatsApp bị rò rỉ chỉ là cái cớ, rồi cuối cùng chúng cũng sẽ đánh cắp thứ khác thôi
Nếu chặn để chỉ chữ ký nhất định mới đọc được ứng dụng, thì cả sao lưu hợp pháp hay truy cập dữ liệu chính đáng cũng trở nên bất khả thi
Tăng cường bảo mật thì tốt, nhưng kiểu phòng thủ quá tay bằng cách khóa mọi thứ lại là một vấn đề khác
Người dùng truy cập theo kiểu kết nối một client khác vào tài khoản WhatsApp, và vì thế có thể truy cập toàn bộ dữ liệu
Nếu WhatsApp cung cấp một API chính thức tử tế thì những chuyện như vậy đã ít xảy ra hơn
Tài liệu liên quan: Baileys Wiki
Ngày xưa malware nhiều hơn, nhưng đổi lại tự do và khả năng tương tác cũng lớn hơn
Tôi xem những cuộc tấn công kiểu này giờ là hệ quả có thể dự đoán trước
Các package manager như NPM có cấu trúc lấy dependency ngay trước lúc build nên về bản chất là dễ tổn thương
Vấn đề là văn hóa né qua hệ thống quản lý phiên bản nhưng lại chấp nhận vô số dependency mà không kiểm chứng
Không chỉ NPM mà Cargo, Docker, CI/CD và mọi hệ sinh thái đều có vấn đề tương tự
Kiểu “cài theo tên rồi xong” khiến mức độ dựa trên lòng tin quá lớn
Cũng không có giải pháp rõ ràng — không thể từ bỏ cộng tác, mà bảo mật tuyệt đối cũng là bất khả thi
Cuối cùng thì quái vật đã ở trong nhà rồi
Kể cả chỉ định trực tiếp git URL thì kết quả cũng sẽ như vậy
Rốt cuộc đây là vấn đề mang tính cấu trúc của chính việc quản lý dependency
Có cảm giác cần một package manager chuẩn hóa không phụ thuộc ngôn ngữ
Các tính năng như xác minh chữ ký, bảo đảm nguồn gốc, chuẩn hóa API là bắt buộc
Như vụ xz, gói đã bị nhiễm độc vẫn có thể được phát hành nguyên vẹn
Hơn nữa, system package manager hỗ trợ bản mới quá chậm nên không phù hợp cho phát triển
Đó là lý do cuối cùng vẫn cần các công cụ như npm, cargo, pip
Không phải vấn đề của package manager, mà là ngay từ đầu đã là code không đáng tin cậy
Việc tác giả malware đặt tên hàm lộ liễu như exfiltrateCredentials nghe buồn cười thật
Còn mỉa mai ở chỗ họ thêm cả phát hiện debugger nhưng lại không obfuscate code
Đúng là thời buổi malware testing cũng đã trở thành một dạng phát triển phần mềm
Câu “dependency mà developer cài vào không cần suy nghĩ” nghe rợn người
Trừ khi là tổ chức có chính sách bảo mật nghiêm ngặt, còn không thì rất khó chặn trên thực tế
Cuối cùng có lẽ giải pháp chỉ là bớt dùng npm đi
Nếu chỉ định bằng tag thì bất cứ lúc nào cũng có thể phơi ra trước tấn công chuỗi cung ứng
Ngành này vận hành trên nền niềm tin mù quáng nhiều hơn người ta nghĩ
Hệ thống triển khai tự động thậm chí còn không có thời gian để “nghĩ lại lần hai”
Sẽ thật tốt nếu JavaScript cũng có một thư viện lớn đáng tin như Apache Commons
Giới thiệu Apache Commons
Gói lotusbail là một gói npm độc hại giả mạo WhatsApp Web API
Nó đã được phát hành suốt 6 tháng và thực hiện nhiều kiểu tấn công như đánh cắp thông tin xác thực, chặn bắt tin nhắn, cài backdoor
Với các developer phụ thuộc vào hệ sinh thái JS, trên thực tế cần có chiến lược giảm thiểu rủi ro
Có nhắc đến các cách dùng Docker hoặc VM
Chúng tôi container hóa toàn bộ môi trường phát triển và khóa dependency ở phiên bản cố định
Cấm cài đặt global, cấm cập nhật tự động, bắt buộc xác minh thủ công
Với các dự án nhạy cảm thì dùng workstation chuyên dụng và khởi tạo lại định kỳ
Phiền thật, nhưng đó là kiểu bảo mật thực tế
Không thì rời khỏi hệ sinh thái JS cũng là một cách
Cần có khả năng kiểm tra ở mức OS hoặc Docker xem có cho phép kết nối mạng hay không
Dù vẫn dùng chung kernel, vậy là đủ để chặn các cuộc tấn công từ hệ sinh thái JS
Nếu npm bắt đầu có cả tấn công thoát container thì lúc đó tôi sẽ chuyển sang VM
Ban đầu tôi nghĩ đây là bảo mật quá mức, nhưng giờ thấy nó vừa nhanh vừa ổn định
Vì trong khoảng thời gian đó, tính độc hại của chúng có thể bị lộ ra
Gói này ngay từ đầu đã là một thất bại về bảo mật
Nó dùng tái triển khai xác thực client thay vì API chính thức, và để bên thứ ba xử lý khóa bí mật của người dùng
Người dùng cũng nên cẩn trọng hơn, nhưng cũng khó mà đổ lỗi hoàn toàn cho họ
Chỉ khi đăng ký vào “WhatsApp Business Platform” thì mới có thể truy cập API
Nếu có API thật sự thì những chuyện như vậy đã không xảy ra
Tuy nhiên, việc đưa khóa bí mật cho bên thứ ba trong quá trình xác thực thì rất nguy hiểm
Thông thường người ta cài những gói như vậy để tự động hóa chính tài khoản của mình
Dạo này có quá nhiều bài blog do LLM tạo ra
Chất lượng thấp nhưng chi phí gần như bằng 0, nên từ góc nhìn marketer thì rất hiệu quả
Kiểu viết truyền thống giờ đã thành legacy mất rồi
Có vẻ tấn công chuỗi cung ứng đang gia tăng. Developer nên đối phó thế nào?
Cần phát hiện các mẫu như vậy bằng quét tự động và siết chặt quy trình xác minh
Container hóa, khóa dependency, quét bảo mật, cập nhật chậm lại là điều bắt buộc
Cài npm global là lựa chọn tệ nhất
Nên tận dụng container như rootless podman hoặc VM để giảm thiểu rủi ro