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

Thay đổi Package Name của Android Studio dể dàng với plugin APR

Nếu bạn đang gặp khó khăn hoặc bế tắc trong việc thay đổi package name trong And

Lỗi không Update Meta_Value Khi thay thế hình ảnh cũ bằng hình ảnh mới trong WordPress

Mã dưới đây hoạt động tốt có 1 lỗi không update được postmeta ” meta_key=

Bài 1 – React Native DevOps các khái niệm và các cài đặt căn bản

Hướng dẫn setup jenkins agent để bắt đầu build mobile bằng jenkins cho devloper an t

Chuyển đổi từ monolith sang microservices qua ví dụ

1. Why microservices? Microservices là kiến trúc hệ thống phần mềm hướng dịch vụ,