Log4j RCE (CVE-2021-44228, CVSSv3 10.0) – Lịch sử, cách hoạt động và cách phòng tránh

1. Lịch sử về Log4j RCE (CVE-2021-44228, CVSSv3 10.0) Vào ngày 9/12/2021 Chen Zhaojun – Thuộc Alibaba Cloud Security Team đã tiết lộ lỗ hổng nghiêm trọng của thư viện Log4J. Cho phép thực thi code từ xa (RCE – Remote Code Execute) mà không cần xác thực (Authenticate). Log4j là thư viện để ghi

1. Lịch sử về Log4j RCE (CVE-2021-44228, CVSSv3 10.0)

Vào ngày 9/12/2021 Chen Zhaojun – Thuộc Alibaba Cloud Security Team đã tiết lộ lỗ hổng nghiêm trọng của thư viện Log4J. Cho phép thực thi code từ xa (RCE – Remote Code Execute) mà không cần xác thực (Authenticate).

Log4j là thư viện để ghi log (logging) rất nổi tiếng thuộc sở hữu của Apache, được sử dụng rộng rãi trong các ứng dụng doanh nghiệp và điện toán đám mây. Một số công ty, tập đoàn tiêu biểu đang sử dụng thư viện này có thể kể đến Apple, Amazon, Tesla, Cloudflare, Twitter, Steam,…

Các phiên bản Log4j bị ảnh hưởng: 2.0 ~ 2.14.1

Lỗ hổng cho phép kẻ tấn công thực thi mã lệnh từ xa và có thể chiếm toàn quyền kiểm soát hệ thống nên được đặt với cái tên thân thương là “Log4Shell”.

2. Cách hoạt động

Từ bản Log4J 2.0, tính năng lookups được thêm vào nhằm bổ sung thêm các cách lấy các giá trị giúp cho việc logging thuận tiện hơn, trong đó bao gồm cả JNDI lookup.

JNDI cho phép kết nối ứng dụng java tới các dịch vụ thư mục bên ngoài (external directory service) ví dụ như một server LDAP để có thể tìm và nhận một Java object chứa giá trị cần cho việc ghi log. Nhưng do server LDAP không cần nằm trên cùng một máy với server chạy ứng dụng nên nó có thể nằm bất kỳ nơi nào trên mạng internet, chính sự nới lỏng này dẫn đến rủi ro kẻ tấn công có thể khiến ứng dụng load một object độc hại từ một server LDAP dưới quyền kiểm soát chúng.

Sau đây là tóm tắt các bước mà kẻ tấn công thực hiện để khai thác lỗ hổng này:

(1): Kẻ tấn công gắn (bind) payload (có thể hiểu đơn giản là đoạn mã độc) vào server LDAP của chúng.

(2): Kẻ tấn công có gắng tìm một số value/parameter mà có thể được log bởi Log4j (ví dụ như: User-Agent của HttpHeader, username,…) và truyền một chuỗi là câu lệnh query tới server LDAP của chúng.

(3): Tại server nạn nhân, Log4j nhận thấy chuỗi query tới server LDAP của kẻ tấn công trong nội dung cần ghi log, tính năng JNDI lookup được kích hoạt và cố gắng query tới server LDAP của kẻ tấn công.

(4): Server nạn nhận response chứa payload độc hại từ server LDAP của kẻ tấn công.

(5): Server nạn nhân cố gắng decode response và kích hoạt (trigger) payload độc hại, thực hiện (execute) đoạn mã độc (có thể là đoạn mã đánh cắp thông tin, kiểm soát hệ thống, khai thác tiền mã hoá,…)

3. Cách phòng tránh

  1. Upgrade Log4j lên phiên bản tối thiểu là 2.15.0 (phiên bản mới nhất tại thời điểm viết bài).

  2. Nếu bạn sử dụng phiên bản từ 2.10 trở lên và không thể upgrade hãy:

    Set thuộc tính:

     log4j2.formatMsgNoLookups=true
    

    Hoặc set biến môi trường:

     LOG4J_FORMAT_MSG_NO_LOOKUPS=true
    

    Ngoài ra, bạn có thể xoá luôn class chứa logic JNDILookup của Log4j theo câu lệnh sau:

    zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
    

Lời kết

Cảm ơn bạn đã theo dõi, mong bài viết bên trên giúp bạn hiểu hơn về lỗ hổng bảo mật “Log4Shell” cũng như có cánh phòng tránh được những sự cố liên quan.

Nguồn: viblo.asia

Bài viết liên quan

WebP là gì? Hướng dẫn cách để chuyển hình ảnh jpg, png qua webp

WebP là gì? WebP là một định dạng ảnh hiện đại, được phát triển bởi Google

Điểm khác biệt giữa IPv4 và IPv6 là gì?

IPv4 và IPv6 là hai phiên bản của hệ thống địa chỉ Giao thức Internet (IP). IP l

Check nameservers của tên miền xem website trỏ đúng chưa

Tìm hiểu cách check nameservers của tên miền để xác định tên miền đó đang dùn

Mình đang dùng Google Domains để check tên miền hàng ngày

Từ khi thông báo dịch vụ Google Domains bỏ mác Beta, mình mới để ý và bắt đầ