35K mã độc hại được chèn vào GitHub: Nỗ lực tấn công hay thưởng lỗi? Thông tin dữ liệu PlatoBlockchain. Tìm kiếm dọc. Ái.

35K Chèn mã độc hại trong GitHub: Nỗ lực tấn công hay Bug-Bounty?

Các chuyên gia phần mềm cho biết hôm nay, một hacker có biệt danh “Pl0xP” đã sao chép một số lượng lớn kho lưu trữ GitHub và thay đổi một chút tên kho lưu trữ được sao chép, nhằm cố gắng đánh máy nhằm mạo danh các dự án hợp pháp – do đó có khả năng lây nhiễm sang bất kỳ phần mềm nào đã nhập mã.

Kỹ sư phần mềm Stephen Lacy cho biết trong một bài đăng trên Twitter vào sáng sớm. Cuộc tấn công, một biến thể của nhầm lẫn phụ thuộcÔng nói, có thể gây ra sự cố cho các nhà phát triển khi sử dụng kho GitHub giả mạo mà không xác minh đầy đủ về nguồn phần mềm.

Theo Lacy, nếu được nhập vào, mã độc sẽ thực thi mã trên hệ thống. “Cuộc tấn công này sẽ gửi TOÀN BỘ ENV của tập lệnh, ứng dụng, máy tính xách tay (ứng dụng điện tử) đến máy chủ của kẻ tấn công! ENV bao gồm: Khóa bảo mật; Khóa truy cập AWS; Khóa tiền điện tử… nhiều hơn nữa.” 

“ENV” là các biến môi trường, được sử dụng để lưu trữ thông tin mà các nhà phát triển muốn tham khảo trong quy trình làm việc của họ.

Lacy cho biết kỹ sư phần mềm đã phát hiện ra chức năng độc hại khi kiểm tra thư viện phần mềm mà anh ta cân nhắc đưa vào dự án của riêng mình.

“Tôi phát hiện ra lỗ hổng này khi đang xem xét một dự án mà tôi tìm thấy qua tìm kiếm trên Google,” anh ấy tweet. “Đây là lý do tại sao chúng tôi không cài đặt các gói ngẫu nhiên trên internet!”

Nhân bản — hay “phân nhánh” — không phải là một kỹ thuật độc hại mới nhưng là một kỹ thuật phức tạp.

Mor Weinberg, kỹ sư phần mềm Aqua Security cho biết: “Trước đây, những kẻ xấu đã nổi tiếng với việc tạo ra các kho lưu trữ phổ biến nhân bản/phân nhánh bằng mã độc”. “Điều này có thể trở nên khá khó phát hiện, vì các kho lưu trữ nhân bản có thể giữ lại các cam kết mã với tên người dùng và địa chỉ email của tác giả ban đầu, tạo ra ấn tượng sai lầm rằng các cam kết mới hơn cũng được thực hiện bởi các tác giả dự án ban đầu. Các cam kết mã nguồn mở được ký bằng khóa GPG của các tác giả dự án đích thực là một cách để xác minh tính xác thực của mã.”

Mark Lambert, phó chủ tịch sản phẩm tại ArmorCode cho biết thêm: “Điều này… giống như việc ai đó lập một trang web 'giả mạo' hoặc gửi email lừa đảo. “Điều này sẽ thu hút những người không chú ý.”

Một cuộc tấn công hay nghiên cứu hợp pháp?

Việc phân tách hàng loạt trong GitHub này có thể không phải là một cuộc tấn công thực sự. Một người tuyên bố có kiến ​​​​thức về vấn đề này đã coi lỗi đánh máy phổ biến là một nỗ lực nghiên cứu hợp pháp.

“Đây chỉ là một nỗ lực trao thưởng lỗi. không có hại gì cả. Báo cáo sẽ được công bố,” một Người dùng Twitter có tên “pl0x_plox_chiken_p0x” đã tweet vào ngày 3 tháng XNUMX.

Trong khi một dự án nghiên cứu thiếu sáng suốt có thể giải thích cho cuộc tấn công, thì việc tạo ra hàng nghìn thay đổi mã cho nghiên cứu dường như lại có rủi ro phi lý. Hơn nữa, người dùng Twitter chỉ mới đăng ký tài khoản trong ba ngày trước đó - thời gian tồn tại của tài khoản ngắn thường là đặc điểm của các cá nhân lừa đảo trực tuyến.

Jossef Harush, người đứng đầu bộ phận kỹ thuật bảo mật chuỗi cung ứng tại công ty bảo mật phần mềm Checkmarx, nói với Dark rằng tuyên bố rằng cuộc tấn công là một phần của chương trình thưởng lỗi “đang chờ được chứng minh, vì hoạt động này có đặc điểm của một cuộc tấn công có mục đích xấu”. Đọc.

Trong mọi trường hợp, Michael Skelton, giám đốc cấp cao về hoạt động bảo mật tại nền tảng thưởng lỗi Bugcrowd, lưu ý rằng ít nhất các kho lưu trữ mã gốc vẫn không bị ảnh hưởng.

“Mặc dù không rõ bản chất của việc phát hiện tiền thưởng lỗi của Pl0xP là gì (vì kỹ thuật xã hội nằm ngoài phạm vi của hầu hết các chương trình tiền thưởng lỗi), nhưng có vẻ như họ đã sao chép một số kho lưu trữ và thực hiện các thay đổi trong các bản sao đó. duy nhất - không có trường hợp nào thay đổi này đi vào kho lưu trữ ban đầu đã được sao chép,” ông nói. “Sao chép kho lưu trữ là một hành động tiêu chuẩn không ảnh hưởng đến kho lưu trữ ban đầu trừ khi chủ sở hữu hợp nhất lại một thay đổi (được yêu cầu thông qua yêu cầu kéo), điều này chưa được thực hiện ở đây.”

Có rất nhiều phụ thuộc phần mềm độc hại

GitHub dường như đã dọn sạch các cam kết mã độc và tính đến chiều ngày 3 tháng XNUMX, việc tìm kiếm URL xấu được nhúng không mang lại kết quả nào. Tuy nhiên, cuộc tấn công này hầu như không phải là lần đầu tiên các dự án nguồn mở phải đối phó với những kẻ tấn công. Số vụ tấn công vào chuỗi cung ứng phần mềm tăng 650% vào năm 2021, chủ yếu được thúc đẩy bởi các cuộc tấn công gây nhầm lẫn phụ thuộc, trong đó kẻ tấn công sử dụng phiên bản có tên gần như giống hệt của khối mã nguồn mở với hy vọng các nhà phát triển gõ nhầm tên của thư viện hoặc thành phần mong muốn hoặc không nhận thấy sự khác biệt nhỏ trong danh pháp. 

Việc gieo mầm các kho lưu trữ có chứa các dự án độc hại, bị đặt tên sai yêu cầu kẻ tấn công phải thực hiện một số bước cơ bản. Vào tháng 7, công ty bảo mật phần mềm Checkmarx đã tiết lộ cách tạo tài khoản nhà phát triển giả trên GitHub, hoàn thành với lịch sử hoạt động của các cam kết mã để tăng độ tin cậy của họ. Kỹ thuật này, cùng với cuộc tấn công mới nhất, nhấn mạnh rằng những người bảo trì cần thực hiện các bước để chỉ chấp nhận các cam kết mã đã ký, Harush nói. Các nhà phát triển cần “đề phòng các yêu cầu kéo và đóng góp có các cam kết đáng ngờ chưa được xác minh, [và cần] xem xét… nội dung của các đóng góp so với tuyên bố từ chối trách nhiệm trong thông báo cam kết và các đóng góp bổ sung hoặc sửa đổi các phần phụ thuộc hiện có cho các phần phụ thuộc có tên tương tự như một phần của đóng góp,” ông nói thêm.

Đừng tin tưởng, hãy xác minh

Để tránh dự án của họ bị đầu độc, người bảo trì và nhà phát triển chỉ nên tin tưởng những người đóng góp mà họ biết và có lịch sử cam kết sâu rộng và có thể kiểm chứng được. Họ cũng nên sử dụng các công cụ có sẵn - chẳng hạn như chữ ký số và xác thực đa yếu tố - để bảo mật tài khoản của mình, Harush nói.

Ông nói: “Vì bạn không nên tin vào kẹo từ người lạ - đừng tin vào mã từ người lạ. “Người dùng có thể bị lừa khi đánh giá dự án ứng viên và nghĩ rằng chúng hợp pháp, [vì vậy] họ sử dụng nó trong các máy tính phát triển cục bộ, môi trường xây dựng, môi trường sản xuất và thậm chí xây dựng phần mềm, [cho đến khi cuối cùng thực thi điều gì đó độc hại] trên [ hệ thống].”

Trong lời khuyên tháng 7 của Checkmarx về việc giả mạo thông tin nhận dạng và cam kết thông tin trong git tiện ích dòng lệnh, công ty đã nhấn mạnh những rủi ro đối với các dự án phần mềm khi những kẻ phạm tội độc hại cải trang thành những người đóng góp đã biết. Điều này “làm cho dự án trông đáng tin cậy,” công ty đã tuyên bố. “Điều khiến việc giả mạo cam kết này trở nên đáng báo động hơn nữa là thực tế là người dùng bị giả mạo không được thông báo và sẽ không biết rằng tên của họ đang được sử dụng.”

GitHub đã thêm chữ ký điện tử cho các cam kết mã để xác minh danh tính của người đóng góp, nhưng những người duy trì dự án nên kích hoạt “chế độ cảnh giác”, một tính năng của GitHub hiển thị chi tiết về trạng thái xác minh của mọi cam kết và người đóng góp của họ, Checkmarx cho biết.

Ít nhất, các nhà phát triển và người bảo trì dự án thỉnh thoảng nên xem lại nhật ký cam kết của họ và yêu cầu những người bảo trì khác của họ kích hoạt các cam kết có chữ ký GPG, Harush nói. “Việc làm quen với việc có nhật ký cam kết đã ký sẽ có lợi cho bạn khi chú ý đến những đóng góp chưa được xác minh.”

GitHub không thể đưa ra bình luận ngay lập tức.

Dấu thời gian:

Thêm từ Đọc tối