Một cuộc tấn công vào kho lưu trữ góiNuGetcho thấy các cuộc tấn công chuỗi cung ứng phần mềm mã nguồn mở đã trở nên tinh vi đến mức nào.
Nó cho thấy cách kẻ tấn công lợi dụng sự tin tưởng của nhà phát triển và các lỗ hổng trong quy tắc đăng ký để tiêm mã độc đánh cắp dữ liệu trực tiếp vào quy trình xây dựng doanh nghiệp.
Các nhà nghiên cứu bảo mật từSocketgần đây đã phát hiện một cuộc tấn công giả mạo homoglyph đang hoạt động trên NuGet, sao chép dự án Nethereum.
Dự án này bị nhắm mục tiêu có lý do.
Nethereum là thư viện .NET tiêu chuẩn cho Ethereum, biến nó thành mục tiêu hàng đầu của những kẻ tấn công muốn đánh cắp tiền mã hóa hoặc xâm phạm các ứng dụng blockchain.
Tác động của một vi phạm như vậy đối với doanh nghiệp có thể nghiêm trọng.
Mã độc được tạo ra để gửi dữ liệu nhạy cảm qua một yêu cầu POST HTTPS, có thể chứa các cụm từ ghi nhớ, khóa riêng tư, JSON kho khóa hoặc dữ liệu giao dịch đã ký.
Đối với bất kỳ doanh nghiệp nào trong lĩnh vực FinTech, danh tính kỹ thuật số hoặc Web3, việc mất dữ liệu này sẽ là một thảm họa lớn, dẫn đến tổn thất tài chính và làm suy yếu niềm tin của khách hàng.
Cuộc tấn công được thực hiện bằng một chiến lược nhiều lớp, được thiết kế để vượt qua cả các kiểm tra bảo mật thủ công và tự động.
Thách thức 1:
Đánh lừa bằng homoglyphs
Kẻ tấn công đã phát hành một gói có tênNetherеum.All.
Thoạt nhìn, gói này trông giống hệt dự án thật.
Thủ thuật đơn giản nhưng hiệu quả:
nó thay thế chữ ‘e’ Cyrillic vào tên để qua mặt sự kiểm tra thông thường.
Cuộc tấn công này vào NuGet cho thấy một vấn đề then chốt với quản trị.
Không giống như nhiều kho lưu trữ khác, quy tắc định danh của NuGet không giới hạn tên ở ASCII, điều này tạo ra khoảng trống cho các ký tự Unicode trông tương tự.
Ngược lại, các kho lưu trữ như PyPI và npm có các quy tắc nghiêm ngặt hơn, có lẽ đã ngăn chặn được cuộc tấn công cụ thể này vào chuỗi cung ứng phần mềm mã nguồn mở.
Sự khác biệt này có nghĩa là kế hoạch phòng thủ không thể giống nhau cho tất cả mọi người;
chúng cần được xây dựng cho các rủi ro cụ thể của từng hệ thống.
Thách thức 2:
Giả mạo sự tin cậy
Chỉ thay đổi tên là chưa đủ.
Kẻ tấn công cần làm cho gói giả mạo có vẻ phổ biến.
Gói độc hại này đã bùng nổ chỉ trong vài ngày sau khi xuất bản, đạt hơn 11,6 triệu lượt tải xuống.
Điều này cho thấy mạnh mẽ sự gia tăng lượt tải xuống tự động.
Bằng cách lập trình tải xuống từ các máy chủ đám mây khác nhau và thay đổi địa chỉ IP, kẻ tấn công tạo ra cảm giác chứng cứ giả mạo khi các nhà phát triển nhìn vào các con số.
Điều này rất hiệu quả, vì các nhóm phát triển thường nhanh chóng kiểm tra số lượt tải xuống để xem một gói có đáng tin cậy hay không.
Thách thức 3:
Tải trọng ẩn
Phần khó khăn nhất cho việc phòng thủ là cách tải trọng được thiết kế.
Phần mềm độc hại không phải là một tập lệnh rõ ràng.
Thay vào đó, nó là một thói quen XOR nhỏ ẩn giấu một C2 được mã hóa cứng.
Khi một nhà phát triển cài đặt gói độc hại được sử dụng cho cuộc tấn công từ NuGet, nó cũng kéo theo các phụ thuộc thực nhưNethereum.HexvàNethereum.Signer.
Điều này đảm bảo ứng dụng sẽ được biên dịch và thực hiện các thao tác Ethereum như mong đợi.
Mã độc vẫn ẩn cho đến khi một phương thức cụ thể,Shuffle, được sử dụng.
Phương thức này sau đó sẽ giải mã XOR vật đánh lạc hướng trên đĩa…
thành một yêu cầu POST HTTPS để gửi các bí mật bị đánh cắp đến điểm cuối chỉ huy và kiểm soát (C2) của kẻ tấn công.
Bởi vì phần mềm độc hại nằm trong một dịch vụ giao dịch đáng tin cậy và thư viện xung quanh thực hiện công việc thực sự, một nhà phát triển có thể thấy ứng dụng hoạt động bình thường trong khi các chuỗi nhạy cảm lặng lẽ rời khỏi quy trình.
Các kiểm tra tiêu chuẩn cho các CVE đã biết có lẽ sẽ không phát hiện điều này.
Tuy nhiên, đây không phải là sự cố duy nhất.
Cùng một kẻ tấn công đã được liên kết với một cuộc tấn công giả mạo trước đó,NethereumNet, sử dụng cùng mã độc.
Mặc dù nhóm bảo mật của NuGet đã nhanh chóng xóa góiNetherеum.Allsau khi nó được báo cáo, cuộc tấn công đã có thời gian tồn tại bốn ngày giữa lúc xuất bản và gỡ bỏ.
Điều này là quá đủ để gây thiệt hại.
Quan trọng là, việc gỡ bỏ không làm sạch môi trường;
hãy coi các bí mật đã bị lộ là đã bị xâm phạm và xoay vòng chúng.
Dưới đây là danh sách kiểm tra các hành động thực tế để cải thiện khả năng phòng thủ chuỗi cung ứng phần mềm:
- Kiểm tra danh tính nhà xuất bản:Đừng chỉ nhìn vào số lượt tải xuống hoặc tên gói.
Hãy đảm bảo các nhóm phát triển xác minh danh tính nhà xuất bản trước khi sử dụng một phụ thuộc mới.
Nhà xuất bản có phải là tổ chức đã biết không?
Tài khoản có mới không?
Bước đơn giản này là một tuyến phòng thủ đầu tiên tốt.
- Quét để tìm hành vi, không chỉ chữ ký:Cuộc tấn công này sẽ không bị phát hiện bởi các công cụ chỉ tìm kiếm các điểm yếu đã biết.
Doanh nghiệp cần quét các thay đổi phụ thuộc trước khi hợp nhất và kiểm tra các hành vi đáng ngờ.
Các công cụ bảo mật cần có khả năng cảnh báo về homoglyphs, sự tăng đột biến lượt tải xuống đột ngột và các thói quen giải mã và rút trích nhỏ.
- Giám sát lưu lượng mạng đi ra:Tải trọng được thiết kế để đánh cắp dữ liệu.
Điều quan trọng là có các chính sách mạnh mẽ để giám sát lưu lượng mạng đi ra bất thường từ các trình chạy bản dựng và máy trạm của nhà phát triển.
Một công cụ xây dựng không bao giờ được giao tiếp với một miền không xác định.
- Sử dụng mô hình phụ thuộc không tin cậy mặc định (zero-trust):Hãy coi mỗi gói mới hoặc được cập nhật là không đáng tin cậy.
Bảo mật nên thắt chặt vệ sinh phụ thuộc theo mặc định, chặn các hành vi rủi ro như tập lệnh tại thời điểm cài đặt hoặc các cuộc gọi mạng bất ngờ trước khi chúng chạy trong môi trường CI/CD hoặc trên máy của nhà phát triển.
Khi các doanh nghiệp ngày càng phụ thuộc vào các nền tảng đám mây từ Microsoft, Google và AWS, các nhà phát triển phải thực hiện mọi biện pháp có thể đểbảo mật tất cả các thành phầncủa chuỗi cung ứng phần mềm mã nguồn mở — bao gồm cả những thành phần thu được từ các trình quản lý gói như NuGet — để bảo vệ chống lại các cuộc tấn công ngày càng phổ biến này.
Xem thêm:GitLab triển khai tác nhân AI để giải quyết tiếng ồn DevSecOps
