- Hệ sinh thái npm đang chứng kiến biến thể mã độc phá hoại lan rộng, và đội ngũ bảo mật GitLab đã phát hiện ra điều này
- Mã độc là dạng tiến hóa của Shai-Hulud, có cơ chế lây lan kiểu sâu tự động lây nhiễm sang các gói khác của nhà phát triển bị nhiễm
- Sau khi đánh cắp thông tin xác thực từ GitHub, AWS, GCP, Azure..., nó rò rỉ dữ liệu sang kho lưu trữ GitHub do kẻ tấn công kiểm soát
- Tích hợp “công tắc deadman” xóa ngay dữ liệu người dùng nếu quyền truy cập vào GitHub và npm cùng lúc bị chặn
- GitLab xác nhận hệ thống của mình không bị nhiễm và cung cấp phương án phát hiện, ứng phó thông qua Dependency Scanning và GitLab Duo Chat
Tổng quan về cuộc tấn công
- Đội Vulnerability Research của GitLab đã phát hiện một cuộc tấn công chuỗi cung ứng quy mô lớn trong hệ sinh thái npm
- Hệ thống giám sát nội bộ đã phát hiện nhiều gói bị nhiễm
- Mã độc được xác định là biến thể của Shai-Hulud
- Mã độc tự động lây nhiễm sang các gói khác của nhà phát triển bị nhiễm thông qua cơ chế lây lan kiểu sâu
- GitLab đã xác nhận nội bộ không sử dụng các gói độc hại và chia sẻ thông tin với cộng đồng bảo mật
Cấu trúc bên trong cuộc tấn công
- Các gói npm độc hại do hệ thống giám sát nội bộ phát hiện thực hiện những chức năng sau
- Thu thập thông tin xác thực từ GitHub, npm, AWS, GCP, Azure
- Gửi dữ liệu đã đánh cắp tới kho lưu trữ GitHub do kẻ tấn công kiểm soát
- Tự động lây nhiễm sang các gói khác của nạn nhân
- Kích hoạt payload phá hoại nếu quyền truy cập hạ tầng bị chặn
- Nhiều gói bị nhiễm đã được xác nhận và cuộc điều tra vẫn đang tiếp tục
Phân tích kỹ thuật: cách cuộc tấn công diễn ra
Vector lây nhiễm ban đầu
- Mã độc xâm nhập hệ thống thông qua quy trình nạp nhiều tầng
- Trong
package.json của gói bị nhiễm, một script setup_bun.js được thêm vào
- Bề ngoài được ngụy trang là script cài đặt Bun JavaScript runtime
- Thực chất nó chạy
bun_environment.js (payload 10MB đã bị làm rối)
- Cấu trúc gồm một file loader nhỏ và payload lớn đã làm rối nhằm né tránh phát hiện
Thu thập thông tin xác thực
- Ngay khi chạy, nó thu thập token và bí mật từ nhiều nguồn khác nhau
- GitHub token (
ghp_, gho_)
- Thông tin xác thực AWS, GCP, Azure
- npm token (
.npmrc và biến môi trường)
- Dùng công cụ Trufflehog để quét toàn bộ thư mục home, tìm API key, mật khẩu, lịch sử Git...
Mạng lưới rò rỉ dữ liệu
- Dùng GitHub token đánh cắp được để tạo kho lưu trữ công khai có mô tả “Sha1-Hulud: The Second Coming.”
- Kho lưu trữ này đóng vai trò dropbox dữ liệu
- Cài đặt GitHub Actions runner để duy trì tính bền bỉ
- Nếu thiếu quyền, nó tìm các kho khác mang cùng dấu hiệu nhận diện để tái sử dụng token từ hệ thống khác
- Từ đó hình thành mạng lưới chia sẻ token phân tán
Lây lan chuỗi cung ứng
- Dùng npm token đã đánh cắp để lây nhiễm mọi gói của nạn nhân
- Tải gói gốc xuống
- Chèn
setup_bun.js làm script preinstall
- Thêm payload
bun_environment.js
- Tăng số phiên bản
- Phát hành lại gói đã nhiễm lên npm
Công tắc deadman
- Mã độc liên tục giám sát quyền truy cập vào GitHub (rò rỉ dữ liệu) và npm (lây lan)
- Nếu cả hai kênh đều bị chặn, nó ngay lập tức thực thi hành vi phá hủy dữ liệu
- Windows: xóa file người dùng và ghi đè các sector đĩa
- Unix: ghi đè file bằng lệnh
shred rồi xóa
- Nếu kho GitHub bị xóa hàng loạt hoặc npm token bị thu hồi trên diện rộng, sẽ có nguy cơ các hệ thống bị nhiễm đồng thời xóa dữ liệu
Chỉ báo xâm nhập (IoC)
- Các chỉ báo phát hiện chính
- File:
bun_environment.js (script post-install độc hại)
- Thư mục:
.truffler-cache/, .truffler-cache/extract/
- Tiến trình:
del /F /Q /S "%USERPROFILE%*", shred -uvz -n 1, cipher /W:%USERPROFILE%
- Lệnh:
curl -fsSL https://bun.sh/install | bash, powershell -c "irm bun.sh/install.ps1|iex"
Hỗ trợ phát hiện và ứng phó của GitLab
- Người dùng GitLab Ultimate có thể kiểm tra ngay mức độ phơi nhiễm bằng các tính năng bảo mật tích hợp
- Khi bật Dependency Scanning, các gói bị nhiễm trong
package-lock.json hoặc yarn.lock sẽ được tự động phát hiện
- Nếu merge request chứa gói bị nhiễm, hệ thống sẽ hiển thị cảnh báo
- Có thể tích hợp với GitLab Duo Chat để phát hiện nhanh dựa trên truy vấn
- Ví dụ: “Có dependency nào bị ảnh hưởng bởi chiến dịch Shai-Hulud v2 không?”
- Security Analyst Agent sẽ truy vấn dữ liệu lỗ hổng của dự án và trả lời ngay
- Với các nhóm quản lý nhiều kho lưu trữ, GitLab khuyến nghị kết hợp phát hiện tự động dựa trên CI/CD và ứng phó nhanh dựa trên agent
Triển vọng sắp tới
- Cuộc tấn công lần này được đánh giá là một dạng tấn công chuỗi cung ứng mới, sử dụng phá hủy dữ liệu nạn nhân để bảo vệ hạ tầng tấn công
- GitLab đang phối hợp với cộng đồng để phát triển chiến lược khôi phục an toàn và tiếp tục giám sát các biến thể bằng hệ thống phát hiện tự động
- Mục tiêu là ngăn chặn thiệt hại thứ cấp do công tắc deadman gây ra thông qua chia sẻ thông tin sớm
1 bình luận
Ý kiến trên Hacker News
Khoảng một tháng trước tôi cần làm một việc khá phiền, nên đi tìm một gói NPM
Khi chạy
brew install npm, một thác phụ thuộc đổ ập xuống; tôi dừng lại một chút để cân nhắc rủi ro và lợi ích, rồi cuối cùng quay lại bằngbrew uninstall npmThay vào đó tôi giải quyết bằng pipeline tiện ích Unix cũ cùng awk, và giờ nghĩ lại thì đó đúng là quyết định sáng suốt nhất
NPM là công cụ được tạo ra để giải quyết vấn đề tương thích trình duyệt, nên trong môi trường không có trình duyệt nó chỉ mang lại độ phức tạp không cần thiết
Nếu chạy trực tiếp trên hệ thống chính mã từ các hệ sinh thái nhiều phụ thuộc như Node hay Python, nguy cơ phơi nhiễm trước các cuộc tấn công chuỗi cung ứng là rất lớn
Vì vậy tôi thậm chí không cài sẵn trình thông dịch Python hay JS trên hệ thống mặc định
Cuối cùng tôi đã bỏ cuộc, nhưng giờ có vẻ khi đó tôi mới là người đúng
Có người nói rằng “nếu GitHub xóa hàng loạt các kho lưu trữ độc hại thì hàng nghìn hệ thống có thể đồng thời phá hủy dữ liệu người dùng”,
nghe chẳng khác gì một vụ bắt cóc con tin — nên mới có trò đùa “bắn con tin đi”
Tôi cũng là nạn nhân của đợt tấn công npm lần này
Tôi bị sốc khi biết GitHub CLI lưu OAuth token dạng văn bản thuần trong thư mục HOME
Nếu kẻ tấn công truy cập được, chúng gần như có thể làm mọi thứ trên tài khoản của tôi
Trên macOS, nó được lưu an toàn trong keychain của hệ điều hành — thảo luận liên quan
Chrome dùng cơ chế bảo vệ của hệ điều hành, còn Firefox thì vẫn chưa
Cuối cùng kiểm soát truy cập dựa trên sandbox mới là giải pháp gốc rễ
Nhưng hiện không có giải pháp nhất quán giữa các nền tảng, và ngay cả trên MacOS cũng chưa có cách nào hoàn hảo
Một thư mục
~/.dev-envxuất hiện và laptop của tôi biến thành GitHub runnerCó lẽ hệ thống tệp chỉ đọc của Bluefin Linux đã giúp giảm bớt thiệt hại
Ai cũng chỉ đổ lỗi cho npm, nhưng GitHub cũng phải chịu trách nhiệm lớn
Họ không phát hiện đủ nhanh các kho lưu trữ độc hại, trong khi vấn đề repo chứa malware vốn đã rất nghiêm trọng
Nếu nó âm thầm bị gửi ra máy chủ bên ngoài thì mọi chuyện còn kinh khủng hơn nhiều
Cần có công cụ và thông lệ ở cấp cộng đồng
Nếu xuất hiện các ràng buộc thương mại hay giới hạn quy trình build thì có thể dẫn tới vấn đề rất lớn
Tôi từng thắc mắc vì sao chỉ NPM là mục tiêu tấn công
Python hay Java cũng rất phổ biến, nhưng gần đây lại khá yên ắng
văn hóa phụ thuộc theo dải phiên bản khiến việc lây lan diễn ra rất nhanh
Với Java, việc cố định một phiên bản cụ thể là chuyện phổ biến nên loại sự cố này hiếm hơn
Vì vậy một package có thể kéo theo hàng chục phụ thuộc con
lại có nhiều lập trình viên ít kinh nghiệm nên bảo mật yếu hơn
Các hệ sinh thái ngôn ngữ khác thường kiểm chứng rồi mới cập nhật, còn JS thì nâng cấp ngay lập tức
Nó từ lâu đã cho phép chạy script thoải mái khi cài đặt, còn JVM hay Python thì không như vậy
Thêm vào
.npmrccó thể giảm bớt vector tấn công
bài viết liên quan
và khi tắt script thì có rủi ro làm hỏng phụ thuộc hay không cũng là điều đáng hỏi
Điều đáng lo nhất trong đợt tấn công này là đánh cắp thông tin xác thực
Nếu bạn đã cài package bị nhiễm, biến môi trường hoặc token trong
.npmrccó thể đã bị rò rỉCần xoay vòng token và API key ngay lập tức
Việc xoay vòng định kỳ không phải là phản ứng sau xâm nhập mà là biện pháp phòng ngừa từ trước
Không nên lưu thông tin xác thực trong biến môi trường hay file; hãy dùng khóa bảo mật hoặc file mã hóa
Nó giống như cài giao dịch độc hại vào một sổ cái phân tán
Vấn đề là đến giờ vẫn còn nhiều dịch vụ mặc định lưu dạng văn bản thuần
Những cuộc tấn công kiểu này lặp đi lặp lại, nên tôi thắc mắc vì sao hệ thống phát hiện dựa trên AI vẫn không hoạt động
Microsoft quảng bá AI nhiều như vậy, nhưng có vẻ lại không dùng nó cho bảo mật GitHub
giống thời người ta gắn nhãn mọi thứ firewall chặn được là tấn công, khiến ý nghĩa dần nhạt đi
Ở bên trong có SonaType IQ Server hỗ trợ việc đó
Thực tế đã có trường hợp dự án curl bị spam báo cáo bảo mật do AI tạo ra
Tôi tự hỏi còn lý do gì để tiếp tục cho phép script postinstall nữa
Có lẽ nên hỏi người dùng xem có muốn chạy hay không sẽ tốt hơn
còn máy chủ CI thì cần cài đặt không tương tác, nên trên thực tế điều này khá khó khả thi
Bài viết rất sâu sắc, nhưng tôi thấy tiếc vì đoạn cuối lại kết thúc bằng quảng bá tính năng bảo mật của GitLab