Dùng thử miễn phí 7 ngày cho mọi gói · Yêu cầu email công ty · Không tính phí trong 7 ngàyBắt đầu dùng thử →
Tất cả bài viết
SecOps15 tháng 8, 2025 6 phút đọc

Kịch bản "Kill Switch" thầm lặng trong chuỗi cung ứng: Khủng hoảng đánh cắp thông tin xác thực của npm

Một làn sóng tấn công chuỗi cung ứng gần đây nhắm vào các gói npm được sử dụng rộng rãi đã phơi bày một lỗ hổng nghiêm trọng trong phát triển phần mềm hiện đại. Kẻ tấn công đang tiêm mã đánh cắp thông tin xác thực vào các bản vá phát hành tưởng chừng vô hại, vượt qua các kiểm soát bảo mật truyền thống và xâm phạm các ứng dụng hạ nguồn ở quy mô đáng báo động. Các CISO và kỹ sư bảo mật phải hiểu rõ cơ chế và ý nghĩa của mối đe dọa đang phát triển này.

Chia sẻXLinkedIn
Kịch bản "Kill Switch" thầm lặng trong chuỗi cung ứng: Khủng hoảng đánh cắp thông tin xác thực của npm

Điều gì đã xảy ra

Trong một loạt sự cố trong năm qua, một số gói npm nổi tiếng, không thể thiếu đối với hàng ngàn ứng dụng trên nhiều ngành công nghiệp, đã bị xâm phạm. Kẻ tấn công đã giành quyền truy cập trái phép vào tài khoản người duy trì, sau đó chèn mã độc một cách tinh vi vào các bản vá phát hành nhỏ. Mã này, được thiết kế để đánh cắp các biến môi trường, khóa API và các thông tin xác thực nhạy cảm khác, đã lan truyền nhanh chóng thông qua các bản cập nhật phụ thuộc tự động.

Tác động là ngay lập tức và trên diện rộng. Một QSR lớn, dựa vào một gói bị xâm phạm như vậy cho ứng dụng di động hướng tới khách hàng của mình, đã bị lấy trộm các token API nội bộ. Tương tự, một nhà bán lẻ Fortune 500 đã trải qua việc truy cập trái phép vào môi trường thử nghiệm của mình do thông tin xác thực CI/CD bị xâm phạm bị lộ thông qua một bản cập nhật phụ thuộc.

Những cuộc tấn công này không phải là các lỗ hổng zero-day khai thác các lỗ hổng mới trong Node.js hoặc chính npm. Thay vào đó, chúng đã lợi dụng kỹ thuật xã hội, xác thực yếu hoặc các mối đe dọa nội bộ đối với những người duy trì gói. Mã độc thường bị làm rối, khiến việc phát hiện khó khăn nếu không có phân tích mã chuyên sâu hoặc giám sát hành vi trong thời gian chạy.

Tại sao mô hình này cứ lặp lại

Phát triển phần mềm hiện đại phụ thuộc rất nhiều vào các thành phần mã nguồn mở, tạo ra một chuỗi cung ứng rộng lớn và kết nối. Ứng dụng trung bình kéo theo hàng trăm, nếu không phải hàng ngàn, phụ thuộc trực tiếp và gián tiếp. Mỗi phụ thuộc này đại diện cho một vectơ tấn công tiềm năng, một điểm lỗi duy nhất có thể bị khai thác.

Tốc độ phát triển và áp lực phải cung cấp các tính năng thường ưu tiên chức năng hơn là kiểm tra bảo mật kỹ lưỡng mọi bản cập nhật phụ thuộc. Các nhà phát triển thường chạy npm update hoặc yarn upgrade mà không xem xét kỹ lưỡng từng dòng mã trong bản vá phát hành, cho rằng các bản cập nhật phiên bản nhỏ là an toàn. Mô hình tin cậy này vốn dĩ có thể bị khai thác.

Hơn nữa, các công cụ quản lý gói, mặc dù mạnh mẽ để phát triển, thường thiếu phân tích bảo mật tích hợp, thời gian thực cho các bất thường về hành vi hoặc thay đổi mã đáng ngờ trong một bản phát hành. Các công cụ phân tích tĩnh có thể phát hiện một số phần mềm độc hại rõ ràng, nhưng logic đánh cắp thông tin xác thực tinh vi thường tránh được phát hiện dựa trên chữ ký.

Kế hoạch tấn công từng bước của kẻ tấn công

Bước 1: Xác định mục tiêu và trinh sát

Kẻ tấn công trước tiên xác định các gói npm phổ biến được sử dụng rộng rãi, đặc biệt là những gói quan trọng đối với các ứng dụng doanh nghiệp. Chúng ưu tiên các gói có một người duy trì hoặc một nhóm nhỏ, làm cho kỹ thuật xã hội hoặc xâm phạm tài khoản dễ dàng hơn. Chúng cũng tìm kiếm các gói có quyền truy cập trực tiếp vào các môi trường nhạy cảm (ví dụ: công cụ xây dựng, tập lệnh triển khai).

Bước 2: Thỏa hiệp tài khoản người duy trì

Đây là điểm mấu chốt. Kẻ tấn công sử dụng lừa đảo, nhồi nhét thông tin xác thực hoặc khai thác mật khẩu yếu để giành quyền kiểm soát tài khoản npm của người duy trì gói. Trong một số trường hợp, chúng có thể lợi dụng cookie phiên bị đánh cắp hoặc thậm chí là truy cập nội bộ nếu người duy trì không hài lòng hoặc bị mua chuộc. Các kỹ thuật bỏ qua MFA cũng ngày càng phổ biến.

Bước 3: Tiêm mã độc

Khi đã kiểm soát, kẻ tấn công sẽ tiêm mã bị làm rối vào gói. Mã này thường được thiết kế để trông vô hại, có thể là một hàm tiện ích nhỏ hoặc một câu lệnh ghi nhật ký. Mục đích chính của nó là thu thập các biến môi trường (ví dụ: process.env), khóa API, thông tin xác thực đám mây hoặc các bí mật khác có thể truy cập được đối với ứng dụng đang chạy.

Bước 4: Phát hành bản vá và lan truyền

Kẻ tấn công sau đó phát hành một phiên bản vá mới (ví dụ: 1.0.0 đến 1.0.1). Việc tăng phiên bản nhỏ này rất quan trọng; nó báo hiệu cho các hệ thống cập nhật tự động và các nhà phát triển rằng thay đổi này có rủi ro thấp. Các ứng dụng hạ nguồn, thường được cấu hình để cập nhật bản vá tự động, vô tình kéo mã độc vào. Sự lan truyền là nhanh chóng và trên diện rộng.

Bước 5: Đánh cắp và khai thác

Mã được tiêm sẽ thực thi khi gói bị xâm phạm được sử dụng. Nó thu thập dữ liệu nhạy cảm và đánh cắp nó đến một điểm cuối do kẻ tấn công kiểm soát, thường được ngụy trang thành lưu lượng truy cập hợp pháp (ví dụ: một điểm cuối phân tích giả mạo). Với các thông tin xác thực bị đánh cắp này, kẻ tấn công có quyền truy cập vào các môi trường đám mây, API nội bộ, cơ sở dữ liệu hoặc đường ống CI/CD, dẫn đến các vi phạm hoặc đánh cắp dữ liệu tiếp theo.

Những gì các nhà phòng thủ đã bỏ lỡ

Nhiều tổ chức dựa vào bảo mật chu vi truyền thống và phát hiện điểm cuối, vốn không hiệu quả đối với loại tấn công chuỗi cung ứng này. Mã độc được ký bởi một người duy trì hợp pháp, được phân phối qua các kênh chính thức và thực thi trong môi trường đáng tin cậy của chính ứng dụng. Đó là một công việc nội bộ, theo quan điểm của ứng dụng.

"Sự tin tưởng mù quáng mà chúng ta đặt vào các phụ thuộc của bên thứ ba là rủi ro lớn nhất chưa được giải quyết trong phát triển phần mềm hiện đại. Chúng ta đang nhập mã không xác định ở quy mô lớn, thường không có sự giám sát đầy đủ."

Hơn nữa, các công cụ kiểm tra bảo mật ứng dụng tĩnh (SAST) thường gặp khó khăn trong việc xác định ý đồ độc hại trong mã bị làm rối hoặc các thay đổi logic tinh vi. Kiểm tra bảo mật ứng dụng động (DAST) có thể phát hiện lưu lượng mạng bất thường trong thời gian chạy, nhưng thường là quá muộn, sau khi việc đánh cắp ban đầu đã xảy ra. Các công cụ Phân tích Thành phần Phần mềm (SCA) rất tuyệt vời để xác định các lỗ hổng đã biết, nhưng ít hiệu quả hơn đối với mã độc mới được tiêm, chưa được biết đến trước đây.

Danh sách kiểm tra phòng thủ thực tế

  • Thực hiện ghim phụ thuộc nghiêm ngặt: Tránh các phạm vi phiên bản rộng (^, ~) trong package.json. Ghim các phiên bản chính xác hoặc sử dụng các tệp khóa (package-lock.json, yarn.lock) một cách chặt chẽ và cam kết chúng vào kiểm soát nguồn. Thường xuyên kiểm tra và cập nhật các phụ thuộc thông qua một quy trình được kiểm soát.
  • Bắt buộc xác thực đa yếu tố (MFA) cho người duy trì: Yêu cầu MFA mạnh mẽ cho tất cả các tài khoản npm, GitHub và các nền tảng phát triển khác được sử dụng bởi người duy trì gói. Đây là tuyến phòng thủ đầu tiên chống lại việc xâm phạm tài khoản.
  • Tự động xem xét phụ thuộc: Tích hợp các công cụ thực hiện phân tích mã chuyên sâu về các bản cập nhật phụ thuộc, gắn cờ các thay đổi giới thiệu các cuộc gọi mạng mới, quyền truy cập hệ thống tệp hoặc mã bị làm rối. Tìm kiếm các thay đổi hành vi, không chỉ các chữ ký đã biết.
  • Tự bảo vệ ứng dụng thời gian chạy (RASP): Triển khai các giải pháp RASP giám sát hành vi ứng dụng trong thời gian thực và chặn các hành động đáng ngờ, chẳng hạn như cố gắng truy cập các biến môi trường hoặc đánh cắp dữ liệu đến các điểm cuối không xác định.
  • Quyền hạn tối thiểu cho môi trường xây dựng: Đảm bảo các đường ống CI/CD và tác nhân xây dựng hoạt động với các quyền tối thiểu tuyệt đối cần thiết. Các môi trường xây dựng bị xâm phạm không nên có quyền truy cập rộng rãi vào thông tin xác thực sản xuất.
  • Công cụ bảo mật chuỗi cung ứng: Tận dụng các nền tảng bảo mật chuỗi cung ứng chuyên biệt theo dõi nguồn gốc, xác minh tính toàn vẹn và thực hiện giám sát liên tục các thành phần mã nguồn mở để tìm hoạt động đáng ngờ hoặc thay đổi người duy trì.
  • Kiểm toán định kỳ các phụ thuộc quan trọng: Đối với các phụ thuộc quan trọng nhất của bạn, hãy tiến hành xem xét mã thủ công định kỳ hoặc thuê các nhà nghiên cứu bảo mật bên thứ ba để kiểm tra kỹ lưỡng cơ sở mã của chúng để tìm cửa hậu hoặc lỗ hổng.

Cách kiểm thử tấn công hiện đại đã có thể phát hiện ra điều này

Kiểm thử tấn công hiện đại vượt xa việc quét lỗ hổng. Nó liên tục thăm dò bề mặt tấn công của một tổ chức, bao gồm cả chuỗi cung ứng phần mềm của nó, để tìm kiếm các điểm yếu có thể khai thác. Đối với mô hình sự cố này, một nền tảng kiểm thử tấn công mạnh mẽ sẽ được tích hợp với đường ống CI/CD, phân tích mọi bản cập nhật phụ thuộc để tìm các bất thường về hành vi và khả năng đánh cắp thông tin xác thực.

Khi phát hiện một bản vá phát hành đáng ngờ, một nền tảng như vậy sẽ tự động tạo ra một Bằng chứng Khái niệm (PoC) có thể thực thi, chứng minh cách mã độc có thể đánh cắp các biến môi trường cụ thể hoặc khóa API từ thời gian chạy của ứng dụng. Thông tin chi tiết tức thì, có thể hành động này, hoàn chỉnh với các bước tái tạo, sẽ cảnh báo các nhóm bảo mật trước khi mã dễ bị tổn thương đến được sản xuất, biến một vi phạm tiềm năng thành một sự cố được ngăn chặn một cách hiệu quả.

Điều gì cần theo dõi tiếp theo

Sự tinh vi của các cuộc tấn công chuỗi cung ứng sẽ tiếp tục leo thang. Mong đợi sẽ thấy nhiều cuộc tấn công có mục tiêu hơn vào các gói cơ sở hạ tầng chuyên biệt, nhưng quan trọng. Việc chuyển sang WebAssembly (Wasm) và các môi trường thực thi được sandbox khác có thể cung cấp một số biện pháp giảm thiểu, nhưng kẻ tấn công sẽ thích nghi, tìm cách mới để thoát ra hoặc khai thác chính sandbox đó.

Hơn nữa, trọng tâm sẽ chuyển sang không chỉ mã. Các tệp cấu hình, hình ảnh Docker và thậm chí các mô hình học máy đang trở thành mục tiêu mới để tiêm và xâm phạm. Các tổ chức phải có cái nhìn toàn diện về chuỗi cung ứng phần mềm của mình, coi mọi thành phần từ phát triển đến triển khai là một vectơ tấn công tiềm năng. Trận chiến giành niềm tin vào hệ sinh thái phần mềm còn lâu mới kết thúc.

Chia sẻXLinkedIn

Bài đọc liên quan