Lỗ hổng bảo mật Axios npm: Chuyện gì đã xảy ra, ai bị ảnh hưởng và cách ngăn chặn?

Vì sao cuộc tấn công Axios npm lại nguy hiểm

Thoạt nhìn, dường như không có gì sai. Yêu cầu được thực thi thành công, ứng dụng hoạt động như mong đợi và pipelineCác bài kiểm tra tiếp tục diễn ra mà không có lỗi.

Tuy nhiên, chi tiết quan trọng xảy ra trước khi yêu cầu được gửi đi. Trong khoảng thời gian thực thi đó, phần mềm phụ thuộc bị xâm phạm có thể âm thầm truy cập và thu thập dữ liệu nhạy cảm như tiêu đề ủy quyền, mã thông báo API, siêu dữ liệu yêu cầu và biến môi trường.

Vì đoạn mã logic này chạy bên trong một thư viện đáng tin cậy nằm trực tiếp trong đường dẫn yêu cầu HTTP, nên nó hoạt động với cùng các đặc quyền như chính ứng dụng. Do đó, nó có thể truy cập dữ liệu mà thông thường sẽ được bảo vệ khỏi các kẻ tấn công bên ngoài.

Điều khiến việc này đặc biệt nguy hiểm không chỉ là việc truy cập dữ liệu, mà còn là việc thiếu tác động rõ ràng. Không có sự gián đoạn chức năng, không có yêu cầu nào bị lỗi và không có tín hiệu ngay lập tức cho thấy có điều gì đó không ổn. Từ góc độ vận hành, mọi thứ vẫn hoạt động như mong đợi.

Trong khi đó, thông tin nhạy cảm có thể đã bị rò rỉ ra khỏi hệ thống thông qua các kết nối đi ra ngoài, lẫn vào lưu lượng truy cập ứng dụng thông thường.

Tại sao đây lại là một vấn đề của DevOps trước tiên?

Đối với các nhóm DevOps, loại tấn công này đặc biệt khó phát hiện vì nó tích hợp liền mạch vào các quy trình làm việc hiện có.

Các phần phụ thuộc được cài đặt tự động. pipelineCác tác vụ chạy bình thường và không xảy ra lỗi ngay lập tức.

Cùng một lúc, CI/CD Môi trường này thường làm lộ các thông tin đăng nhập có giá trị cao, bao gồm:

• Mã thông báo của nhà cung cấp đám mây
• Khóa triển khai
• CI/CD bí mật xác thực

Một thành phần phụ thuộc bị xâm phạm đang chạy trong ngữ cảnh này có thể truy cập trực tiếp vào các thông tin đăng nhập đó.

Điều này tạo ra tình huống mà mọi thứ dường như bình thường, trong khi dữ liệu nhạy cảm vẫn đang được truy cập ngầm.

Rủi ro thực sự: Bí mật bị lộ trên quy mô lớn

Lỗ hổng bảo mật axios npm cho thấy một sự thay đổi quan trọng trong các chiến lược tấn công hiện đại.

Mục tiêu không còn là khai thác lỗ hổng bảo mật, mà là truy cập thông tin đăng nhập hợp lệ.

Vì các hệ thống hiện đại dựa vào xác thực dựa trên môi trường, nên một thành phần phụ thuộc chạy trong thời gian thực có thể truy cập:

• Khóa API
• Mã thông báo dịch vụ
• Thông tin xác thực đám mây

Những thông tin xác thực này không cần phải bị phá vỡ.

Chúng chỉ cần được sử dụng thôi.

Điều này cho phép kẻ tấn công di chuyển ngang, truy cập các dịch vụ và trích xuất dữ liệu bằng cách sử dụng xác thực hợp lệ.

Do đó, mức độ ảnh hưởng phụ thuộc vào những bí mật nào bị lộ, chứ không phải cách thức tấn công được thực hiện.

Vì sao các công cụ bảo mật truyền thống lại bỏ sót điều này?

Các phương pháp truyền thống gặp khó khăn trong việc phát hiện các cuộc tấn công này vì chúng tập trung vào các lỗ hổng đã biết hoặc các chữ ký tĩnh. Tuy nhiên, như đã được nhấn mạnh trong Phân tích của OpenAI Về lỗ hổng bảo mật trong công cụ phát triển axios, rủi ro thực sự xuất hiện ở giai đoạn chạy chương trình, nơi các thành phần phụ thuộc đáng tin cậy tương tác với dữ liệu nhạy cảm.

Tuy nhiên, sự phụ thuộc bị tổn hại có thể không có bất kỳ dấu hiệu rõ ràng nào.

Có thể có:

• Không có CVE
• Không có chữ ký độc hại
• Không có cú pháp bất thường

Đồng thời, phân tích tĩnh không đánh giá hành vi khi thực thi. Nó không thể xác định cách một thành phần phụ thuộc tương tác với dữ liệu nhạy cảm sau khi được thực thi.

Điều này tạo ra một lỗ hổng khiến mã nguồn có vẻ an toàn trong quá trình phân tích nhưng lại trở nên rủi ro trong quá trình thực thi.

Cách phát hiện và ngăn chặn các cuộc tấn công tương tự Axios npm

Để ngăn chặn kiểu tấn công Axios npm này, cần phải chuyển từ kiểm tra tĩnh sang nhận thức trong quá trình thực thi.

Các nhóm cần nắm rõ cách thức hoạt động của các mối quan hệ phụ thuộc, chứ không chỉ nội dung của chúng.

Những chi phí này bao gồm:

• Giám sát quyền truy cập vào dữ liệu nhạy cảm trong quá trình hoạt động
• Phát hiện các bí mật trước khi chúng đến được kho lưu trữ.
• Quét (scanning) pipelinevà các hiện vật liên quan đến thông tin xác thực bị lộ.
• Theo dõi hoạt động mạng đi ra để phát hiện các bất thường.

Tuy nhiên, chỉ phát hiện thôi là chưa đủ.

Từ phát hiện đến phòng ngừa: Điều gì thực sự làm giảm rủi ro?

Sau một sự cố như thế này, các nhóm thường phải đối mặt với một số lượng lớn thông tin đăng nhập có nguy cơ bị lộ.

Thách thức không phải là tìm ra chúng, mà là xác định những cái nào thực sự quan trọng.

Câu hỏi then chốt là:

Những bí mật nào vẫn còn giá trị và có thể bị khai thác?

Nếu không có quá trình xác thực, các nhóm sẽ tốn thời gian vào các thông tin xác thực không hoạt động trong khi các rủi ro thực sự vẫn còn tồn tại.

Để có phản ứng hiệu quả cần:

• Phát hiện bí mật bị lộ
• Xác minh xem họ có còn cấp quyền truy cập hay không.
• Thu hồi hoặc thay đổi chúng nhanh chóng

Điều này giúp giảm thời gian tiếp xúc và thu hẹp khoảng thời gian tấn công của kẻ xâm nhập.

Xygeni giúp giảm thiểu rủi ro trong chuỗi cung ứng như thế nào?

Xygeni Giải quyết thách thức này bằng cách kết hợp việc phát hiện, xác minh và khắc phục sự cố vào một quy trình làm việc duy nhất.

Nó liên tục xác định các bí mật bị lộ trong toàn bộ mã nguồn. pipelinevà các hiện vật. Đồng thời, nó xác thực xem các thông tin xác thực đó có còn hoạt động trong môi trường hay không.

Điều này cho phép các nhóm tập trung vào những gì kẻ tấn công thực sự có thể sử dụng.

Khi các bí mật đang hoạt động được xác định, quy trình khắc phục tự động giúp giảm thời gian tiếp xúc thông qua việc thu hồi hoặc xoay vòng có kiểm soát.

Kết quả là, phản hồi trở nên nhanh hơn, chính xác hơn.cisvà ít gây xáo trộn hơn.