Một cuộc tấn công chuỗi cung ứng gần đây nhắm vào gói phổ biến @ctrl/tinycolor đã gây ra cuộc tranh luận sôi nổi về tính bảo mật của các quy trình xuất bản tự động trong hệ sinh thái JavaScript . Sự cố này đã ảnh hưởng đến 20 gói bao gồm một gói được tải xuống 2 triệu lần mỗi tuần, đã phơi bày những điểm yếu cơ bản trong cách các nhà phát triển quản lý thông tin xác thực xuất bản trên các kho lưu trữ được chia sẻ.
Dòng thời gian tấn công và tác động
- Ngày: 15 tháng 9, 2024
- Các gói bị ảnh hưởng: Tổng cộng 20 gói
- Gói có tác động lớn:
@ctrl/tinycolor(2 triệu lượt tải xuống hàng tuần) - Phương thức tấn công: Quy trình làm việc GitHub Actions độc hại trong kho lưu trữ được chia sẻ
- Thời gian phản hồi: Phát hiện và loại bỏ trong cùng ngày bởi các nhóm bảo mật GitHub/NPM
Mối Nguy Hiểm Ẩn Giấu Của Token Kho Lưu Trữ Được Chia Sẻ
Cuộc tấn công không nhắm trực tiếp vào kho lưu trữ gói chính. Thay vào đó, nó khai thác một token NPM bị lãng quên được lưu trữ trong kho lưu trữ GitHub được chia sẻ có tên angulartics2, nơi nhiều nhà phát triển có quyền truy cập quản trị. Một quy trình độc hại đã được đẩy vào kho lưu trữ này, ngay lập tức đánh cắp token và sử dụng nó để xuất bản các phiên bản bị xâm phạm của các gói không liên quan. Điều này làm nổi bật một sự giám sát quan trọng trong cách các nhà phát triển quản lý thông tin xác thực trên các dự án cộng tác.
Phản ứng của cộng đồng đã nhanh chóng nhưng chia rẽ về các giải pháp. Nhiều nhà phát triển đang đặt câu hỏi liệu sự tiện lợi của xuất bản tự động có đáng với những rủi ro bảo mật mà nó mang lại hay không.
Cuộc Tranh Luận Lớn Về Tự Động Hóa
Sự cố đã làm bùng phát lại các cuộc thảo luận về việc liệu xuất bản tự động có nên là phương pháp mặc định cho quản lý gói hay không. Một số thành viên cộng đồng cho rằng xuất bản thủ công với xác thực hai yếu tố có thể đã ngăn chặn hoàn toàn cuộc tấn công này. Lý do rất đơn giản: hầu hết các gói NPM không cập nhật đủ thường xuyên để biện minh cho những rủi ro bảo mật của các quy trình tự động.
Tuy nhiên, những người khác chỉ ra những lợi ích thực tế của tự động hóa, bao gồm các bản build nhất quán và giảm lỗi con người. Thách thức nằm ở việc tìm ra một giải pháp trung gian duy trì tính bảo mật mà không hy sinh độ tin cậy mà các hệ thống tự động cung cấp.
 |
|---|
| Cuộc tranh luận đang diễn ra xung quanh việc xuất bản tự động so với các quy trình thủ công cho quản lý gói phần mềm đặt ra những câu hỏi quan trọng về bảo mật |
Các Cải Tiến Bảo Mật Được Đề Xuất
Một số giải pháp kỹ thuật đã xuất hiện từ các cuộc thảo luận của cộng đồng. Giải pháp hứa hẹn nhất liên quan đến việc tách biệt việc tải lên gói khỏi việc xuất bản - cho phép các hệ thống tự động xây dựng và tải lên các gói trong khi yêu cầu sự chấp thuận của con người cho việc xuất bản cuối cùng. Phương pháp hai giai đoạn này sẽ duy trì các lợi ích tự động hóa trong khi thêm một điểm kiểm tra quan trọng của con người.
Việc xuất bản các gói đã tải lên nên yêu cầu một người đăng nhập vào trang web npmjs & xuất bản gói thủ công và thực hiện MFA .
Một cải tiến khác được đề xuất liên quan đến việc thực hiện độ trễ thời gian hoặc yêu cầu nhiều người phê duyệt cho các hoạt động nhạy cảm, tương tự như các thực hành bảo mật được sử dụng trong các hệ thống cơ sở hạ tầng quan trọng.
Các Cải Tiến Bảo Mật Được Đề Xuất
- Xuất Bản Hai Giai Đoạn: Tách biệt việc tải lên tự động khỏi phê duyệt xuất bản thủ công
- Phê Duyệt Đa Người: Yêu cầu nhiều người bảo trì phê duyệt các bản phát hành
- Độ Trễ Khóa Thời Gian: Triển khai thời gian chờ giữa việc xây dựng và xuất bản
- Tích Hợp MFA Nâng Cao: Tích hợp tốt hơn xác thực 2 yếu tố với quy trình CI/CD
- Cảnh Báo Script Postinstall: Các chỉ báo rõ ràng hơn cho các gói có script postinstall
Vấn Đề Token và Các Giải Pháp OIDC
Cuộc tấn công đã làm nổi bật những vấn đề cơ bản với các token xác thực có thời hạn dài. Những token này về cơ bản hoạt động như mật khẩu vĩnh viễn có thể bị đánh cắp và lạm dụng. Cộng đồng đang thúc đẩy việc áp dụng rộng rãi hơn Trusted Publishing sử dụng OpenID Connect ( OIDC ), tạo ra các token có thời hạn ngắn chỉ có hiệu lực trong 15 phút.
Mặc dù hỗ trợ OIDC tồn tại cho NPM , việc tích hợp với các công cụ phổ biến như semantic-release vẫn chưa hoàn chỉnh. Khoảng cách này giữa các thực hành bảo mật tốt nhất và công cụ thực tế tiếp tục khiến các nhà phát triển dễ bị tổn thương trước các cuộc tấn công tương tự.
Các Công Nghệ Bảo Mật Được Thảo Luận
- Trusted Publishing ( OIDC ): Tạo ra các token tạm thời trong 15 phút thay vì sử dụng thông tin xác thực tồn tại lâu dài
- NPM Provenance: Cung cấp các chứng thực về cách thức các gói được xây dựng
- Xác Thực Hai Yếu Tố: Xác minh thủ công cho các hoạt động xuất bản
- GitHub Environments: Bảo vệ quy trình làm việc (yêu cầu đăng ký Pro )
- Semantic-release: Công cụ tự động hóa phổ biến với tính năng tích hợp OIDC đang chờ triển khai
Bài Học Cho Toàn Bộ Hệ Sinh Thái
Sự cố này đóng vai trò như một hồi chuông cảnh báo cho toàn bộ hệ sinh thái JavaScript . Cuộc tấn công thành công không phải thông qua việc hack tinh vi, mà bằng cách khai thác những sơ suất bảo mật cơ bản - các token bị lãng quên trong kho lưu trữ được chia sẻ và kiểm soát truy cập quá khoan dung. Nó chứng minh cách các quyết định cộng tác trong quá khứ có thể tạo ra những vector tấn công bất ngờ nhiều năm sau đó.
Phản ứng nhanh chóng từ các đội bảo mật GitHub và NPM , những người đã nhanh chóng xác định và loại bỏ các gói độc hại, cho thấy rằng các hệ thống phát hiện và phản ứng đang được cải thiện. Tuy nhiên, thách thức cơ bản vẫn còn: ngăn chặn những cuộc tấn công này thành công ngay từ đầu.
Sự cố nhấn mạnh nhu cầu về các mặc định bảo mật tốt hơn trong các hệ thống quản lý gói, hướng dẫn rõ ràng hơn về quản lý thông tin xác thực, và các công cụ làm cho các thực hành bảo mật trở nên thuận tiện như những thực hành không an toàn hiện tại. Cho đến khi những cải tiến này được thực hiện, các cuộc tấn công tương tự có khả năng sẽ tiếp tục gây khó khăn cho hệ sinh thái JavaScript .