- Điều gì đã xảy ra trong vụ tấn công Axios npm?
- Làm thế nào một dòng duy nhất trong file package.json lại trở thành điểm yếu tấn công?
- Vì sao quy trình kiểm tra mã nguồn truyền thống không phát hiện ra cuộc tấn công Axios?
- Vì sao bán kính vụ nổ lại ảnh hưởng đến mọi thứ mà gói hàng tiếp xúc?
- Những biện pháp kiểm soát an ninh nào có thể đã thay đổi kết quả?
- Tìm hiểu thêm về Software Supply Chain Bảo vệ
- Những câu hỏi thường gặp
Tấn công chiếm đoạt gói Npm là một hình thức tấn công chuỗi cung ứng phần mềm, biến niềm tin vào gói phần mềm thành con đường tấn công. Kẻ tấn công không cần phải sửa đổi mã nguồn của kho lưu trữ nếu chúng có thể kiểm soát tài khoản phát hành gói đó.
Đó là lý do tại sao các gói npm đáng tin cậy lại trở thành mục tiêu tấn công mạnh mẽ. Khi tài khoản người bảo trì bị xâm phạm, mọi dự án cài đặt gói bị ảnh hưởng đều có thể bị lộ thông qua một bản cập nhật phụ thuộc thông thường. Sự cố Axios tháng 3 năm 2026 cho thấy một tài khoản npm bị xâm phạm có thể gây nguy hiểm cho hơn 100 triệu lượt tải xuống hàng tuần mà không cần thay đổi mã nguồn axios theo bất kỳ cách nào có thể nhìn thấy được.
Hiểu cách thức tấn công chiếm quyền điều khiển gói npm hoạt động giúp các nhóm bảo mật xây dựng các biện pháp kiểm soát nhằm giải quyết con đường tấn công thực sự, thay vì chỉ tập trung vào các tệp nguồn mà hầu hết các nhóm thường xem xét.
Điều gì đã xảy ra trong vụ tấn công Axios npm?
Vụ tấn công Axios npm là một vụ chiếm đoạt tài khoản người bảo trì, biến một gói phần mềm đáng tin cậy thành cơ chế phát tán phần mềm độc hại. Kẻ tấn công đã xâm nhập tài khoản npm của người bảo trì chính của axios, thay đổi địa chỉ email đã đăng ký thành địa chỉ do kẻ tấn công kiểm soát và khóa quyền truy cập của người bảo trì hợp pháp.
Chiến dịch này được dàn dựng và có chủ đích. Một gói tin giả mạo đã được phát hành khoảng 18 giờ trước khi phần mềm độc hại được kích hoạt, tạo ra lịch sử phát hành mà không gây ra nghi ngờ ngay lập tức. Sau đó, trong khoảng 39 phút, kẻ tấn công đã phát tán hai phiên bản độc hại: axios 1.14.1 cho nhánh phát hành hiện đại và axios 0.30.4 cho nhánh cũ.
Cả hai dòng phát hành đều được nhắm mục tiêu cùng một lúc để tối đa hóa khả năng tiếp xúc. Lựa chọn đó làm tăng khả năng cả môi trường hiện tại và môi trường cũ đều sẽ tải xuống gói phần mềm độc hại thông qua hành vi cập nhật tiêu chuẩn.
Làm thế nào một dòng duy nhất trong file package.json lại trở thành điểm yếu tấn công?
Một thay đổi nhỏ về phụ thuộc trong file package.json có thể trở thành toàn bộ lộ trình tấn công trong một cuộc tấn công chuỗi cung ứng npm. Trong sự cố Axios, không cần phải thay đổi bất kỳ file mã nguồn nào của axios vì hành vi độc hại được đưa vào thông qua một phụ thuộc mới.
Sự phụ thuộc đó được thực thi thông qua một hook postinstall của npm. Ngay khi máy trạm của nhà phát triển, đường dẫn CI/CD hoặc hệ thống xây dựng chạy lệnh npm install, gói phần mềm độc hại có thể liên hệ với máy chủ do kẻ tấn công kiểm soát, lấy tải trọng dành riêng cho hệ điều hành và bắt đầu thực thi.
Các phần mềm độc hại được chuẩn bị cho macOS, Windows và Linux. Cuộc tấn công được thiết kế để hoạt động trên nhiều nền tảng. Sau khi chạy, phần mềm phát tán mã độc đã xóa dấu vết của chính nó và thay thế tệp package.json thật bằng một phiên bản giả mạo, khiến việc điều tra điều tra số sau này trở nên khó khăn hơn nhiều.
Vì sao quy trình kiểm tra mã nguồn truyền thống không phát hiện ra cuộc tấn công Axios?
Phương pháp kiểm tra mã truyền thống được xây dựng để kiểm tra các thay đổi mã nguồn bên trong kho lưu trữ, nhưng đường dẫn tấn công này không nằm trong mã nguồn của Axios. Cuộc tấn công Axios không dựa vào các thay đổi kho lưu trữ có thể nhìn thấy được vì logic độc hại nằm trong một thư viện phụ thuộc riêng biệt chứ không phải trong mã nguồn của Axios.
Sự khác biệt đó rất quan trọng. Người kiểm duyệt khi xem xét bản cập nhật gói sẽ chỉ thấy một dòng phụ thuộc mới trong package.json. Hành vi độc hại thực sự chỉ xuất hiện khi phần phụ thuộc được giải quyết và cài đặt.
Đây là lý do tại sao các cuộc tấn công vào gói tin đáng tin cậy rất khó phát hiện chỉ bằng phương pháp xem xét dựa trên sự khác biệt. Đường dẫn tấn công nằm ngoài các tệp nguồn mà hầu hết các nhóm kiểm tra, mặc dù gói tin đó vẫn có vẻ hợp lệ và có thể vượt qua các quy trình phát triển thông thường.
Vì sao bán kính vụ nổ lại ảnh hưởng đến mọi thứ mà gói hàng tiếp xúc?
Ảnh hưởng của một gói npm bị xâm phạm không chỉ giới hạn trong chính gói đó. Ảnh hưởng này bao trùm mọi thứ mà gói đó tiếp xúc.
Đối với hầu hết các tổ chức, điều đó bao gồm các quy trình CI/CD với quyền hạn cao, các điểm cuối dành cho nhà phát triển với khóa SSH và mã thông báo đám mây, máy chủ xây dựng có quyền ghi vào kho lưu trữ hiện vật và các công cụ triển khai được kết nối với hệ thống sản xuất. Một gói phần mềm độc hại không cần phải nằm trong cây phụ thuộc để gây ra thiệt hại. Nó chỉ cần một điểm thực thi đáng tin cậy.
Đó là lý do tại sao sự cố Axios lại quan trọng hơn cả việc quản lý gói JavaScript. Một lỗ hổng bảo mật sau khi cài đặt có thể biến một sự kiện cài đặt thông thường thành hành vi đánh cắp thông tin đăng nhập, di chuyển ngang hoặc truy cập vào cơ sở hạ tầng phía sau.
Những điểm yếu về cấu trúc mà cuộc tấn công Axios đã phơi bày.
Sự cố Axios đã phơi bày những điểm yếu về cấu trúc thường gặp trong môi trường phát triển phần mềm hiện đại. Đây không phải là những trường hợp hiếm gặp, mà là những giả định bình thường trong nhiều tổ chức.
Tin tưởng vào danh tính của người duy trì gói phần mềm.
Độ tin cậy của gói npm thường được gắn với tài khoản người duy trì đã xuất bản gói đó. Nếu tài khoản đó bị đánh cắp hoặc bị lừa đảo, kẻ tấn công sẽ kế thừa quyền xuất bản tương tự như người duy trì hợp pháp.
Phiên bản phụ thuộc nổi
Các phiên bản được thiết lập không cố định hoặc được liên kết lỏng lẻo làm tăng nguy cơ bị phát tán các bản quyền độc hại. Một phiên bản bị xâm phạm mới được phát hành có thể tự động xâm nhập vào môi trường mà không cần bước phê duyệt cụ thể.
Các tập lệnh sau cài đặt không được giám sát
Các tập lệnh postinstall của npm có thể thực thi mã tùy ý với quyền hạn của tiến trình cài đặt. Nhiều tổ chức không kiểm tra hoặc hạn chế các tập lệnh vòng đời trước khi chúng chạy.
Các quy trình CI/CD với khả năng hiển thị thời gian thực hạn chế
Các quy trình CI/CD thường có quyền truy cập rộng rãi vào các hệ thống nội bộ, cơ sở hạ tầng xây dựng và môi trường đám mây. Những quy trình này thường được tin tưởng theo mặc định và hiếm khi được giám sát về hành vi gói phần mềm độc hại trong quá trình cài đặt.
Các điểm cuối của nhà phát triển nằm ngoài phạm vi bảo mật toàn diện
Máy tính của nhà phát triển lưu trữ các tài sản có giá trị cao, bao gồm khóa SSH, thông tin đăng nhập đám mây và mã thông báo doanh nghiệp. Các thiết bị đầu cuối của nhà phát triển cũng là mục tiêu thực thi phổ biến vì chúng có thể có khả năng giám sát và kiểm soát thời gian chạy thấp hơn so với các hệ thống sản xuất.
Kho lưu trữ thông tin xác thực không có cơ chế kích hoạt xoay vòng nhanh
Tấn công chuỗi cung ứng phần mềm thường dẫn đến việc lộ thông tin đăng nhập. Nhiều nhóm vẫn chưa có quy trình làm việc đáng tin cậy để xác định các bí mật có nguy cơ bị lộ và thay thế chúng ngay lập tức.
Những biện pháp kiểm soát an ninh nào có thể đã thay đổi kết quả?
Ba loại biện pháp kiểm soát an ninh có thể đã giảm thiểu đáng kể tác động của cuộc tấn công Axios. Mỗi biện pháp kiểm soát giải quyết một điểm khác nhau trong chuỗi tấn công: thực thi gói, lộ thông tin đăng nhập và khả năng hiển thị các phụ thuộc.
1. Quét phần mềm độc hại ở cấp độ gói trước khi cài đặt
Quét phần mềm độc hại ở cấp độ gói giúp ngăn chặn các phụ thuộc độc hại trước khi chúng được thực thi. Điều này rất quan trọng trong các cuộc tấn công npm vì các hook postinstall chạy trong quá trình cài đặt, khiến cho việc xem xét thủ công sau khi gói được tải xuống có rất ít thời gian.
Việc quét các gói, các thành phần phụ thuộc và các tập lệnh vòng đời trước khi cài đặt có thể xác định các phần mềm độc hại đã biết, các hành vi đáng ngờ, các lỗ hổng và các thông tin bí mật được mã hóa cứng trước khi gói phần mềm đến được thiết bị đầu cuối của nhà phát triển hoặc môi trường CI/CD.
Supply Chain Software MetaDefender là OPSWAT Giải pháp bảo mật chuỗi cung ứng phần mềm của [tên công ty] dùng để xác thực các thành phần phần mềm, nhà cung cấp và quy trình xây dựng. Nó sử dụng khả năng phát hiện mối đe dọa đa công cụ, bao gồm quét đa lớp Metascan trên hơn 30 công cụ chống virus, để kiểm tra các gói phần mềm xem có phần mềm độc hại, lỗ hổng bảo mật và các bí mật được mã hóa cứng hay không trước khi chúng được đưa vào vòng đời phát triển.
2. Quản lý bí mật chủ động với các trình kích hoạt xoay vòng
Quản lý bí mật chủ động giúp giảm thiểu giá trị của một vụ xâm nhập thành công. Khi phát hiện một gói tin đáng ngờ, các nhóm cần có một quy trình phản hồi xử lý thông tin đăng nhập cục bộ, khóa SSH, mã thông báo và bí mật đường dẫn xử lý dữ liệu như những thứ có nguy cơ bị lộ và nhanh chóng thay đổi chúng.
Việc phát hiện bí mật được mã hóa cứng cũng hỗ trợ mục tiêu tương tự. Một gói phần mềm độc hại có thể đánh cắp bí mật từ bộ nhớ hoặc ổ đĩa, nhưng những bí mật bị lộ đã có sẵn trong mã hoặc các thư viện phụ thuộc sẽ tạo thêm một lớp rủi ro có thể phòng ngừa được.
3. Supply Chain Giám sát khả năng hiển thị và sự phụ thuộc
Khả năng hiển thị chuỗi cung ứng giúp các nhóm phát hiện những thay đổi bất ngờ trong gói phần mềm trước khi những thay đổi đó trở thành sự cố ở các khâu tiếp theo. Các nhóm bảo mật cần biết những gói phần mềm nào đã được cài đặt, phiên bản nào được cố định, những phụ thuộc mới nào đã xuất hiện và các thành phần đó đang chạy ở đâu.
Nếu thiếu khả năng giám sát và theo dõi các phụ thuộc, dấu hiệu đầu tiên của sự xâm phạm có thể là việc lạm dụng thông tin đăng nhập hoặc sử dụng sai mục đích cơ sở hạ tầng sau khi sự kiện cài đặt ban đầu đã diễn ra từ lâu.
Tìm hiểu thêm về Software Supply Chain Bảo vệ
Software Bảo mật chuỗi cung ứng phụ thuộc vào việc kiểm tra các gói hàng trước khi thực thi, giám sát các phụ thuộc mới và giảm thiểu rủi ro lộ thông tin xác thực sau khi gói hàng bị xâm phạm.
Xem lại hội thảo trực tuyến theo yêu cầu: Bí mật Supply Chain Software — Những mắt xích yếu mà kẻ tấn công khai thác
Những câu hỏi thường gặp
Tấn công chuỗi cung ứng npm là gì?
Tấn công chuỗi cung ứng npm là việc phát tán mã độc thông qua hệ sinh thái npm trong quá trình phát triển phần mềm thông thường. Kẻ tấn công thường thực hiện điều này bằng cách chiếm đoạt tài khoản người bảo trì, phát hành gói phần mềm giả mạo hoặc chèn hành vi độc hại vào các thư viện phụ thuộc mà nhà phát triển và hệ thống CI/CD tự động cài đặt.
Kẻ tấn công đã xâm nhập gói npm Axios bằng cách nào?
Kẻ tấn công đã chiếm đoạt tài khoản npm của người bảo trì chính của axios và sử dụng quyền truy cập xuất bản đó để phát hành các phiên bản độc hại trên cả hai nhánh phát hành 1.x và 0.x. Kẻ tấn công cũng đã thay đổi địa chỉ email của tài khoản thành một địa chỉ do chúng kiểm soát, điều này giúp chúng duy trì quyền kiểm soát gói phần mềm.
Phần mềm độc hại trong vụ tấn công Axios đã gây ra những hậu quả gì?
Phần mềm độc hại trong vụ tấn công Axios đã sử dụng một hook postinstall để thực thi trong quá trình cài đặt npm. Hook này liên hệ với máy chủ do kẻ tấn công kiểm soát, tải xuống một trojan truy cập từ xa dành cho macOS, Windows hoặc Linux, khởi chạy nó, và sau đó cố gắng xóa dấu vết bằng cách thay thế siêu dữ liệu gói bằng nội dung giả mạo.
Tại sao quá trình rà soát mã nguồn lại không phát hiện ra cuộc tấn công chuỗi cung ứng Axios?
Quá trình rà soát mã nguồn không phát hiện ra cuộc tấn công Axios vì logic độc hại không được đưa vào mã nguồn của Axios. Thay đổi có thể nhìn thấy ở cấp độ kho lưu trữ là một mục phụ thuộc trong package.json, trong khi phần mềm độc hại thực sự được phân phối thông qua một gói bên ngoài nằm ngoài phạm vi rà soát mã nguồn thông thường.
Các tổ chức có thể phát hiện các gói npm độc hại trước khi cài đặt bằng cách nào?
Các tổ chức có thể phát hiện các gói npm độc hại trước khi cài đặt bằng cách quét nội dung gói, cây phụ thuộc và các tập lệnh vòng đời trước khi thực thi. Các biện pháp kiểm soát hiệu quả kết hợp quét phần mềm độc hại, phân tích phụ thuộc, thực thi chính sách và tích hợp CI/CD để các gói đáng ngờ có thể bị chặn trước khi đến môi trường phát triển hoặc xây dựng.
Việc ghim phiên bản có ngăn chặn được các cuộc tấn công vào chuỗi cung ứng npm không?
Việc ghim phiên bản giúp giảm nguy cơ tiếp xúc với các phiên bản độc hại mới được phát hành vì nó hạn chế việc nâng cấp tự động. Tuy nhiên, ghim phiên bản không loại bỏ rủi ro chuỗi cung ứng vì phiên bản được ghim có thể đã bị xâm phạm hoặc vẫn còn tồn tại các lỗi bảo mật khác. Ghim phiên bản hoạt động hiệu quả nhất khi được kết hợp với xác minh tính toàn vẹn, kiểm tra gói phần mềm và kiểm soát thời gian chạy.
