Những rủi ro và khả năng hoặc tình huống trong đó ai đó thiết lập giả mạo kho lưu trữ maven và/hoặc luồng ip để cung cấp bản sao thư viện giả mạo của bản gốc nhưng được tiêm mã nguy hiểm hoặc độc hại.Mức độ an toàn khi sử dụng Maven?
Các bước và thực tiễn để ngăn chặn những rủi ro và khả năng như vậy là gì?
Tôi cho rằng một kẻ tấn công chuyên dụng và tháo vát có thể thực hiện một cuộc tấn công MITM và chặn tất cả các yêu cầu đối với kho Maven công cộng, cẩn thận tiêm độc hại bytecode vào các tạo phẩm JAR, sau đó tính toán lại và cung cấp các băm SHA1.
Đối với khách hàng, nó sẽ xuất hiện như một tạo phẩm hợp pháp: JAR nhị phân và kết hợp SHA1 và sẽ giống nhau ngay cả khi họ kiểm tra các gương thay thế.
Tôi cho rằng giải pháp thực sự duy nhất là yêu cầu repos trung tâm hỗ trợ HTTPS (và tin tưởng rằng bản thân TLS chưa bị hỏng).
Ngoài ra, cách tiếp cận thực tế có thể là thiết lập proxy Maven (Artifactory hoặc Nexus) được phân phối qua HTTPS cho các khách hàng nội bộ. Điều này làm giảm bề mặt tấn công và có nghĩa là bạn sẽ phải bảo đảm các đường truyền thông từ máy chủ đó đến thế giới bên ngoài. Tôi định kỳ kiểm tra lại xem các JAR và băm trên proxy có khớp với những cái trên gương công cộng sử dụng một mạng lưới hoàn toàn độc lập, đáng tin cậy hay không.
Nếu bạn thực sự, thực sự muốn được đảm bảo bạn sẽ không được tin tưởng nhị phân-thay vào đó, bạn sẽ được tải về tất cả các mã nguồn và xem xét chúng bằng tay trước khi biên dịch chúng mình-nhưng mà giả sử bạn có đủ tài nguyên đủ điều kiện và thời gian để tiến hành đánh giá và tin tưởng toàn bộ chuỗi công cụ xây dựng của bạn để bắt đầu.
Vâng, bảo mật trong các lớp như họ luôn nói.
Hoặc bạn có thể sử dụng phương pháp tiếp cận danh sách trắng –
Chúng không cần chặn tất cả các yêu cầu, chỉ đủ để tiêm một JAR xấu. Và nếu bạn làm việc trên một máy tính xách tay bằng cách sử dụng wifi, nó không có một kẻ tấn công tháo vát, ngay cả với WPA. – aij
Tấn công MITM không hoạt động ở trung tâm maven vì nó sử dụng các chữ ký PGP cho các tạo phẩm. –
Nếu bạn sử dụng kho lưu trữ nổi tiếng (kho lưu trữ maven trung tâm, kho lưu trữ jboss), khả năng tiêm mã độc hại rất thấp. Vi-rút máy tính, ISP của bạn hoặc ISP của ISP của bạn phải làm như vậy, phải làm hỏng máy chủ DNS hoặc thay đổi đường dẫn định tuyến cho một số tập hợp đích. Tôi nghĩ rằng đó là khá khó - giống nhau không chỉ về repo maven nhưng cho tất cả các dịch vụ internet (email, http, voip và vv). Rủi ro tương tự là gì khi tải xuống các JAR trực tiếp từ các trang dự án.
Dù sao, nếu bạn muốn có một tổng kiểm soát bạn có thể thiết lập kho maven của riêng bạn (http://nexus.sonatype.org/)
Mỗi tập tin có sẵn trong kho nên có MD5 hoặc SHA checksum tạo - Bằng cách này bạn có thể xác thực nếu những gì bạn tải xuống thực sự là những gì bạn muốn. Nhưng - nếu kẻ tấn công (virus) đủ thông minh để ngăn chặn việc truyền dữ liệu của bạn và gây rối trong các tệp JAR, anh ta cũng đủ thông minh để chặn các tổng kiểm tra md5/sha. Việc bảo vệ chống lại nó là để cung cấp các chữ ký PGP cho cả tổng kiểm tra và tạo phẩm - các tạo phẩm phát hành được tải lên repo trung tâm buộc phải làm như vậy (.asc files)
Ý tưởng tốt là sử dụng Nexus Professional - bạn có thể định cấu hình bộ thu mua để kiểm tra chữ ký PGP đối với một máy chủ khóa công khai mỗi lần tạo tác được tải xuống. Thông tin thêm về chữ ký PGP với maven có thể được tìm thấy ở đây:
https://docs.sonatype.org/display/Repository/How+To+Generate+PGP+Signatures+With+Maven
Tôi có thể nghĩ đến một số trường hợp, mặc dù trường hợp đầu tiên không phải là Maven cụ thể.
DNS cache ngộ độc
Các dữ liệu DNS mà bạn sử dụng để có được kho tiêu chuẩn có thể bị nhiễm độc, gây Maven để tải về hiện vật từ một kho lưu trữ khác nhau. Xem the wikipedia article on DNS cache poisoning.
kho phi tiêu chuẩn
Bất kỳ kho bạn thêm vào cấu hình Maven của bạn có thể cung cấp hiện vật bao gồm mã độc. Ngăn chặn điều này bằng cách chỉ sử dụng các kho lưu trữ của bên thứ ba mà bạn tin cậy.
ngộ độc Repository
Dựa trên Guide to uploading artifacts to the Central Repository Maven, nó trông giống như kho Maven Trung ương xuất bản hiện vật từ máy chủ kho đã được phê duyệt, vì vậy an ninh của vật phụ thuộc vào máy chủ. Tôi không biết cụ thể về quá trình trở thành một máy chủ lưu trữ được phê duyệt, nhưng với rất ít được liệt kê nó có thể là nguy hiểm. Ngoài ra, repo trung tâm đòi hỏi phải có chữ ký PGP cho tất cả các triển khai, do đó, trừ khi một người dùng độc hại truy cập vào khóa riêng cho một dự án, tôi không nghĩ rằng điều này là có thể.
Artifact sửa đổi trong quá trình truyền (người ở giữa)
Maven không xác minh kiểm tra tự động cho tất cả các hiện vật, vì vậy kẻ tấn công sẽ phải sửa đổi artifact và tổng kiểm tra kèm theo để tiêm mã độc. Tôi không biết nếu bạn có thể ngăn chặn nó hoàn toàn, nhưng để đảm bảo rằng bạn đang chú ý đến kiểm tra, hãy chắc chắn rằng chính sách kiểm tra của bạn không được thiết lập để bỏ qua. Xem settings doc.
Như một cách khác để ngăn chặn mã độc xâm nhập vào triển khai sản xuất của bạn là chỉ sử dụng kho lưu trữ Maven bên trong để xây dựng bản phát hành sản phẩm. Bằng cách hạn chế quyền truy cập vào việc thêm các phụ thuộc vào kho lưu trữ đó, bạn có thể đảm bảo rằng tất cả chúng đều được xác minh ở bất kỳ cấp độ nào bạn chọn, ví dụ: checksum kiểm tra kép, quét nguồn.
Related: http://blog.ontoillogical.com/blog/2014/07/28/how-to-take-over-any-java-developer/ –
Tôi đã viết quy tắc plugin Enforcer mục đích chung để giải quyết vấn đề này: https://github.com/gary-rowe/BitcoinjEnforcerRules –
@GaryRowe Dường như plugin của bạn ngăn các lần tải xuống tiếp theo không khớp với tổng kiểm tra được ghi lại bởi nướng tổng kiểm tra vào bản dựng (làm giảm bề mặt tấn công, điều này tốt), nhưng điều này không xuất hiện để bảo vệ tại thời điểm xây dựng lần đầu tiên được tạo ra và danh sách kiểm tra được viết (hoặc được tạo ra). Về cơ bản bạn ngăn chặn việc xây dựng từ ngộ độc * người khác * phải không? Đó có phải là sự hiểu biết đúng đắn về plugin của bạn không? – Gus