OpenJS và OpenSSF phát hành cảnh báo về rủi ro tấn công Social Engineering đối với các dự án mã nguồn mở
- Nỗ lực chèn backdoor của XZ Utils gần đây (CVE-2024-3094) có thể không phải là một sự kiện đơn lẻ
- Có thể đây không phải là sự việc đơn lẻ, vì OpenJS Foundation dường như đã chặn được một nỗ lực chiếm quyền tương tự có vẻ hợp pháp
- OpenSSF và OpenJS Foundation kêu gọi tất cả người quản lý dự án mã nguồn mở cảnh giác trước các nỗ lực chiếm quyền bằng kỹ thuật Social Engineering, nhận diện sớm các mẫu tấn công ban đầu, và thực hiện các biện pháp nhằm bảo vệ dự án mã nguồn mở
Nỗ lực chiếm quyền thất bại
- Cross Project Council của OpenJS Foundation đã nhận được một loạt email khả nghi với nội dung tương tự
- Tác giả email đã kêu gọi OpenJS hành động để cập nhật một trong những dự án JavaScript nổi tiếng nhằm "giải quyết các lỗ hổng nghiêm trọng", nhưng không nêu cụ thể vấn đề
- Người gửi email mong muốn được chỉ định làm quản trị viên mới cho dự án, mặc dù trước đó gần như chưa tham gia vào mã
- Cách tiếp cận này rất giống cách "Jia Tan" định vị bản thân trong vụ backdoor XZ/liblzma
- Các cá nhân này không được cấp quyền truy cập vào dự án do OpenJS lưu trữ
- Dự án có chính sách bảo mật được thiết lập, bao gồm các biện pháp cơ bản được nhóm vận hành bảo mật của quỹ mô tả
- Đội ngũ OpenJS đã nhận thấy các mẫu đáng ngờ tương tự tại hai dự án JavaScript phổ biến khác không thuộc phạm vi lưu trữ của quỹ và đã ngay lập tức thông báo vấn đề tiềm ẩn cho từng lãnh đạo OpenJS và CISA của Bộ An ninh Nội địa Hoa Kỳ (DHS)
Các mẫu đáng ngờ của cuộc chiếm quyền bằng Social Engineering
- Các mẫu:
- Một thành viên cộng đồng tương đối không nổi tiếng liên tục nhưng thân thiện, tấn công bằng cách yêu cầu cho phép truy cập
- Yêu cầu thăng chức một người mới hoặc người không rõ danh tính lên vị trí quản trị viên
- Được hỗ trợ bởi các thành viên cộng đồng khác có thể sử dụng danh tính giả (hay gọi là "sock puppets")
- PR chứa Blob như một artifact
- Mã nguồn cố ý làm rối hoặc khó hiểu
- Các vấn đề bảo mật ngày càng nghiêm trọng dần
- Đưa payload độc hại bên ngoài vào Blob, Zip hoặc các artifact nhị phân khác ngoài các thực hành build, compile và phát hành thông thường của dự án
- Đặc biệt khi việc kiểm tra được làm hời hợt hoặc bỏ qua kiểm soát bởi vì quản trị viên bị tác động do áp lực về thời gian
- Các cuộc tấn công Social Engineering này thao túng nhà quản trị bằng cách lợi dụng tinh thần trách nhiệm của họ với dự án và cộng đồng
- Hãy chú ý cảm giác mà các tương tác tạo ra.
- Cảm giác nghi ngờ bản thân, không phù hợp, hay thấy mình chưa đóng góp đủ cho dự án có thể là một phần của cuộc tấn công Social Engineering
- Xét về bản chất, tấn công Social Engineering giống như đã thấy tại XZ/liblzma đã được cộng đồng OpenJS ngăn chặn thành công
- Loại tấn công này rất khó phát hiện hoặc phòng thủ bằng cách lập trình tự động vì nó dựa trên việc lạm dụng vi phạm lòng tin qua Social Engineering
- Trong ngắn hạn, việc chia sẻ rõ ràng và minh bạch các hoạt động khả nghi như đã nêu ở trên có thể giúp cộng đồng khác duy trì cảnh giác
- Việc hỗ trợ tốt cho người bảo trì là biện pháp răn đe quan trọng đối với các cuộc tấn công Social Engineering này
Các bước cho bảo mật dự án mã nguồn mở
- Cân nhắc việc áp dụng các best practices bảo mật ngành, như OpenSSF Guide
- Sử dụng xác thực mạnh: 2FA, trình quản lý mật khẩu, lưu mã khôi phục ở nơi an toàn, không tái sử dụng mật khẩu/thông tin đăng nhập giữa các dịch vụ
- Thiết lập chính sách bảo mật, bao gồm quy trình Coordinated disclosure
- Áp dụng best practices khi hợp nhất mã mới
- Kích hoạt bảo vệ nhánh và commit có chữ ký
- Nếu có thể, yêu cầu một nhà phát triển thứ hai review code trước khi merge, kể cả khi PR đến từ một quản trị viên
- Áp dụng yêu cầu về tính dễ đọc để PR mới không bị làm rối, và tối thiểu hóa việc sử dụng binary không minh bạch
- Giới hạn người có quyền publish lên npm
- Xác định committer và maintainer để xem xét thường xuyên. Ví dụ: đã từng gặp họ trong cuộc họp nhóm làm việc hay sự kiện nào chưa?
- Nếu bạn vận hành repository gói mã nguồn mở, hãy cân nhắc áp dụng các nguyên tắc cho Package Repository Security
- Xem xét hướng dẫn của CISA về "Avoiding Social Engineering and Phishing Attacks" và/hoặc ENISA về "What is social engineering"
Các biện pháp của ngành và chính phủ để bảo vệ cơ sở hạ tầng mã nguồn mở quan trọng
- Áp lực duy trì dự án mã nguồn mở ổn định và an toàn đang tạo áp lực cho quản trị viên
- Cần hợp tác quốc tế công–tư quy mô lớn để có được nguồn lực đủ lớn
- Nhiều tổ chức như Open Source Foundations, Sovereign Tech Fund... đang tiến hành những công việc rất tốt
- Cần nỗ lực của các tổ chức tương tự như các quỹ thuộc hệ sinh thái Linux Foundation Family để làm nền tảng an toàn cho các dự án mã nguồn mở
- Việc Chính phủ Đức đầu tư vào cơ sở hạ tầng mã nguồn mở quan trọng thông qua sáng kiến Sovereign Tech Fund là điểm tích cực
- Cần ủng hộ mở rộng đầu tư công toàn cầu cho các sáng kiến giống như Sovereign Tech Fund của Đức hơn nữa
Ý kiến GN⁺
- Kẻ tấn công đang khéo léo lợi dụng tinh thần trách nhiệm của quản trị viên để làm xáo trộn nhà phát triển. Vì vậy, cần chú ý đến những thay đổi cảm xúc của quản trị viên khi họ làm việc với dự án.
- Đồng ý rằng cần tăng đầu tư cho bảo mật, nhưng về cốt lõi thì văn hóa phát triển vẫn cần thay đổi theo hướng ưu tiên bảo mật hơn. Bảo mật cần thấm tự nhiên vào toàn bộ quy trình phát triển.
- Vì kẻ tấn công tận dụng lòng tin cộng đồng, các dự án mã nguồn mở cũng cần nỗ lực liên tục để xây dựng và củng cố lòng tin giữa các thành viên. Việc giao tiếp trực tiếp với nhau có thể là khởi đầu.
- Cần có thêm nhiều dự án như Alpha-Omega tập trung đầu tư vào cải thiện lỗ hổng thực tế. Chỉ khi đó mức độ bảo mật của dự án mã nguồn mở mới thực sự được nâng cao.
1 bình luận
Ý kiến Hacker News
Tóm tắt: