Lỗ hổng Java phổ biến là gì?

Question

Các lỗ hổng Java phổ biến có thể khai thác để đạt được một số loại quyền truy cập vào một hệ thống là gì? Tôi đã suy nghĩ về nó gần đây, và havent đã có thể đến với nhiều bất cứ điều gì - tràn số nguyên - có lẽ? điều kiện chủng tộc - nó mang lại cho bạn điều gì?

Tôi không tìm kiếm những thứ như "phun sql trong ứng dụng web". Tôi đang tìm một mối quan hệ tương tự như tràn bộ đệm - c/C++.

Bất kỳ chuyên gia bảo mật nào ở đó có thể trợ giúp? Cảm ơn.

Answer 1

Sau khi đọc hầu hết các câu trả lời, tôi nghĩ câu hỏi của bạn đã được trả lời một cách gián tiếp. Tôi chỉ muốn nói điều này trực tiếp. Java không bị các vấn đề tương tự như bạn thấy trong C/C++ vì nó bảo vệ nhà phát triển khỏi các kiểu tấn công bộ nhớ này (tràn bộ nhớ đệm, tràn tràn, vv). Những điều đó không thể xảy ra.Bởi vì có bảo vệ cơ bản này trong các lỗ hổng bảo mật ngôn ngữ đã di chuyển lên ngăn xếp.

Hiện chúng đang diễn ra ở cấp độ cao hơn. SQL injection, XSS, DOS, vv Bạn có thể tìm ra cách để tải Java từ xa mã độc hại, nhưng để làm điều đó có nghĩa là bạn cần khai thác một số lỗ hổng khác ở lớp dịch vụ để đẩy mã từ xa vào một thư mục sau đó kích hoạt Java để tải thông qua trình nạp lớp. Các cuộc tấn công từ xa về mặt lý thuyết là có thể, nhưng với Java thì việc khai thác phức tạp hơn. Và thường nếu bạn có thể khai thác một số lỗ hổng khác thì tại sao không chỉ đi sau và cắt java ra khỏi vòng lặp. Các thư mục có thể ghi trên thế giới nơi mã java được tải từ có thể được sử dụng để chống lại bạn. Nhưng tại thời điểm này là nó thực sự Java đó là vấn đề hoặc quản trị sys của bạn hoặc nhà cung cấp của một số dịch vụ khác có thể khai thác?

Lỗ hổng duy nhất tạo ra tiềm năng mã từ xa mà tôi đã thấy trong Java qua nhiều năm là từ mã gốc mà VM tải. Lỗ hổng libzip, phân tích cú pháp tệp gif, v.v ... Và đó chỉ là một số vấn đề. Có thể cứ 2-3 năm một lần. Và một lần nữa, thô tục là mã nguồn gốc được JVM nạp không phải trong mã Java.

Là một ngôn ngữ Java rất an toàn. Ngay cả những vấn đề này tôi đã thảo luận có thể bị tấn công về mặt lý thuyết có móc trong nền tảng để ngăn chặn chúng. Việc ký mã sẽ ngăn chặn hầu hết điều này. Tuy nhiên, rất ít chương trình Java chạy với một Trình quản lý bảo mật được cài đặt. Chủ yếu là do hiệu suất, khả năng sử dụng, nhưng chủ yếu là vì những vulns là rất hạn chế trong phạm vi tốt nhất. Tải mã từ xa trong Java đã không tăng lên đến mức dịch mà tràn bộ đệm đã làm trong cuối những năm 90/2000 cho C/C++.

Java không phải là bằng chứng đạn làm nền tảng, nhưng khó khai thác hơn trái cây khác trên cây. Và tin tặc là cơ hội và đi cho quả treo thấp đó.

Answer 2

Tôi không phải là chuyên gia bảo mật, nhưng có một số mô-đun trong công ty của chúng tôi rằng chúng tôi không thể viết mã bằng java bởi vì quá dễ dàng để giải mã bytecode java. Chúng tôi nhìn vào obfuscation nhưng nếu bạn muốn obfuscation thực nó chỉ đi kèm với rất nhiều vấn đề (hiệu suất hit/mất thông tin gỡ lỗi).
Người ta có thể ăn cắp lôgic của chúng tôi, thay thế mô-đun bằng phiên bản sửa đổi sẽ trả lại kết quả không chính xác, v.v.

So với C/C++, tôi đoán đây là một "lỗ hổng" nổi bật.

Chúng tôi cũng có cơ chế cấp phép phần mềm được tích hợp sẵn trong các mô-đun java của chúng tôi, nhưng điều này cũng có thể dễ dàng bị tấn công bằng cách bỏ biên dịch và sửa đổi mã.

Answer 3

Bao gồm các tệp lớp của bên thứ ba và gọi chúng về cơ bản có nghĩa là bạn đang chạy mã không an toàn. Mã đó có thể làm bất cứ điều gì nó muốn nếu bạn không có bảo mật bật.

Answer 4

Tiêm mã độc. Bởi vì Java (hoặc bất kỳ ngôn ngữ nào sử dụng thông dịch viên khi chạy), thực hiện liên kết trong thời gian chạy, có thể thay thế các JAR được mong đợi (tương đương với các tệp DLL và SO) với các tệp độc hại trong thời gian chạy.

Đây là lỗ hổng bảo mật, được kết hợp từ bản phát hành đầu tiên của Java, sử dụng các cơ chế khác nhau.

• Có sự bảo vệ ở những nơi trong trình tải lớp để đảm bảo rằng các lớp java. * Không thể tải từ bên ngoài rt.jar (jar thời gian chạy).
• Ngoài ra, các chính sách bảo mật có thể được đưa ra để đảm bảo rằng các lớp được tải từ nhiều nguồn khác nhau bị hạn chế chỉ thực hiện một số hành động nhất định - ví dụ rõ ràng nhất là các applet. Các applet bị ràng buộc bởi mô hình chính sách bảo mật Java từ việc đọc hoặc viết hệ thống tệp, v.v. các applet đã ký có thể yêu cầu các quyền nhất định.
• JAR cũng có thể được ký và các chữ ký này có thể được xác minh khi chạy khi chúng được tải.
• Các gói cũng có thể được niêm phong để đảm bảo rằng chúng đến từ cùng nguồn mã. Điều này ngăn cản kẻ tấn công đặt các lớp vào gói của bạn, nhưng có khả năng thực hiện các hoạt động 'độc hại'.

Nếu bạn muốn biết tại sao tất cả điều này là quan trọng, hãy tưởng tượng một trình điều khiển JDBC được tiêm vào đường dẫn lớp có khả năng truyền tất cả các câu lệnh SQL và kết quả của chúng đến một bên thứ ba từ xa. Vâng, tôi giả sử bạn có được hình ảnh ngay bây giờ.