Một lỗ hổng mới được công bố trong Apache Log4j2 có thể cho phép kẻ tấn công bỏ qua danh sách cho phép (allowlist) khi xử lý dữ liệu deserialization và thực thi mã từ xa (remote code execution) trong các trường hợp triển khai hạn chế.
Lỗ hổng Log4j2 #4255: Bỏ qua Deserialization Allowlist
Vấn đề này, được theo dõi là Log4j2 #4255, ảnh hưởng đến các ứng dụng chấp nhận các sự kiện Log4j đã được serialize thông qua một đường dẫn Java deserialization có thể truy cập qua mạng. Lỗ hổng này liên quan đến việc sử dụng FilteredObjectInputStream, một tiện ích trong Log4j được thiết kế để giới hạn các lớp Java có thể được tải khi đọc các sự kiện log đã được serialize.
Danh sách cho phép của tiện ích này bao gồm Java.rmi.MarshalledObject, một đối tượng chứa có thể lưu trữ một đối tượng serialize khác dưới dạng một mảng byte. Tuy nhiên, các nhà nghiên cứu đã phát hiện ra rằng đối tượng bên ngoài này có thể vượt qua danh sách cho phép của Log4j trong khi che giấu một đối tượng độc hại bên trong.
Khi Log4j sau đó gọi MarshalledObject.get(), Java sẽ giải serialize payload được nhúng bằng một ObjectInputStream mới, không được lọc. Điều này có nghĩa là danh sách cho phép ban đầu sẽ không kiểm tra đồ thị đối tượng ẩn giấu.
Luồng Lỗ hổng
Luồng dễ bị tổn thương này được liên kết với Log4jLogEvent$LogEventProxy, biểu diễn serialize của một sự kiện Log4j. Proxy đặt thông điệp sự kiện vào bên trong một MarshalledObject và truy xuất nó tự động trong quá trình deserialization.
Kẻ tấn công có thể tạo một sự kiện Log4j serialize độc hại, gửi nó đến một máy nhận dễ bị tấn công và kích hoạt một chuỗi gadget (gadget chain) có sẵn trên classpath của hệ thống mục tiêu để thực thi mã. Một báo cáo về Log4j2 #4255 trên GitHub cho thấy một phòng thí nghiệm tái hiện công khai đã chứng minh vấn đề này trong Log4j 2.26.1 chạy trên JDK 17. Trong môi trường thử nghiệm, một payload độc hại được nhúng trong một MarshalledObject đã kích hoạt thực thi mã khi được xử lý bởi một máy nhận TCP không xác thực sử dụng FilteredObjectInputStream.
Khai thác và Khác biệt với Log4Shell
Phòng thí nghiệm cũng chỉ ra rằng một chuỗi gadget Commons Collections 3.2.1 có thể thực thi mà không yêu cầu lớp do kẻ tấn công cung cấp trên hệ thống nạn nhân. Tuy nhiên, lỗ hổng này không thể so sánh với sự cố Log4Shell có mức độ lan rộng. Nó không thể bị kích hoạt đơn giản bằng cách đặt một chuỗi độc hại vào thông báo log của ứng dụng.
Việc khai thác yêu cầu một thiết lập cụ thể và không phổ biến: ứng dụng phải cung cấp một máy nhận chấp nhận các sự kiện Log4j serialize do kẻ tấn công kiểm soát, xử lý chúng bằng FilteredObjectInputStream và bao gồm một chuỗi các gadget Java deserialization có thể sử dụng. Đây không phải là một lỗ hổng CVE nghiêm trọng có thể dễ dàng khai thác.
Khuyến nghị Bảo mật từ Apache
Hướng dẫn bảo mật của Apache nhấn mạnh rằng mã sản xuất Log4j Core hiện tại thường không thực hiện deserialization dữ liệu nhận được từ các socket, hàng đợi hoặc các nguồn bên ngoài khác. Dự án mô tả FilteredObjectInputStream như một tiện ích phòng thủ theo chiều sâu (defense-in-depth) thay vì một ranh giới bảo mật hoàn chỉnh. Họ cảnh báo rằng các ứng dụng không nên deserialize các luồng sự kiện log không đáng tin cậy.
Các biện pháp giảm thiểu và Phòng ngừa Rủi ro Bảo mật
Các tổ chức nên xác định các máy nhận sự kiện Log4j serialize cũ, đặc biệt là các dịch vụ mạng không xác thực dựa trên các mẫu cầu nối socket cũ. Một biện pháp giảm thiểu tạm thời là cấu hình bộ lọc serialization của JVM để từ chối Java.rmi.MarshalledObject, mặc dù điều này có thể cũng chặn các sự kiện Log4j serialize hợp pháp.
Các biện pháp phòng vệ bền vững hơn bao gồm việc loại bỏ Java serialization khỏi quá trình truyền tải log, nâng cấp hoặc xóa các dependency gadget dễ bị tổn thương, sử dụng các điểm cuối được xác thực lẫn nhau và di chuyển sang logging JSON hoặc RFC 5424 qua TLS. Apache đặc biệt khuyến nghị các định dạng có cấu trúc và TLS thay vì truyền tải log qua Java-serialized.
Tại thời điểm báo cáo, vấn đề Log4j2 #4255 vẫn chưa được gán một CVE và vẫn đang mở. Lỗ hổng này được hiểu tốt nhất là một sự vượt qua deserialization nguy hiểm trong các máy nhận sự kiện Log4j cũ hoặc tùy chỉnh, chứ không phải là một lỗ hổng thực thi mã từ xa phổ biến ảnh hưởng đến các triển khai Log4j thông thường.
Để ngăn chặn các sự cố do điều tra chậm trễ, việc tích hợp thông tin tình báo về mối đe dọa (threat intelligence) từ các trung tâm SOC có thể giúp nâng cao khả năng phát hiện và ứng phó.
Bạn có thể tìm hiểu thêm về phân tích lỗ hổng tại NVD.
