Cách đây vài tuần, thông tin về các vấn đề bảo mật của Log4j đã khiến nhiều người dùng mạng đảo lộn và cho rằng đây là một trong những lỗ hổng được khai thác nhiều nhất và được nhiều chuyên gia đánh giá là «nguy hiểm nhất trong một lâu rồi », trong số các lỗ hổng bảo mật đã được biết đến trong mạng, chúng tôi nói về một số lỗ hổng trong số đó đây trên blog và lần này chúng tôi đã tìm thấy tin tức của một người khác.
Và đó là một vài ngày trước tin tức đã được phát hành rằng một lỗ hổng bảo mật khác đã được xác định trong thư viện Log4j 2 (đã được liệt kê theo CVE-2021-45105) và, không giống như hai vấn đề trước, được phân loại là nguy hiểm, nhưng không nghiêm trọng.
Vấn đề mới cho phép từ chối dịch vụ và thể hiện dưới dạng các vòng lặp và kết thúc bất thường khi xử lý dòng nào đó.
Lỗ hổng ảnh hưởng đến các hệ thống sử dụng tìm kiếm ngữ cảnh, chẳng hạn như $ {ctx: var}, để xác định định dạng đầu ra nhật ký.
các Log4j phiên bản 2.0-alpha1 đến 2.16.0 thiếu khả năng bảo vệ khỏi đệ quy không kiểm soát, gì cho phép kẻ tấn công thao túng giá trị được sử dụng để thay thế để gây ra một vòng lặp vô tận sẽ hết dung lượng trên ngăn xếp và gây ra hiện tượng treo quá trình. Đặc biệt, sự cố đã xảy ra khi thay thế các giá trị như "$ {$ {:: - $ {:: - $$ {:: - j}}}}".
Bên cạnh đó, Có thể lưu ý rằng các nhà nghiên cứu Blumira đã đề xuất một cuộc tấn công vào các ứng dụng Java dễ bị tấn công không chấp nhận yêu cầu từ các mạng bên ngoài, ví dụ, hệ thống của các nhà phát triển hoặc người dùng các ứng dụng Java có thể bị tấn công theo cách này.
Bản chất của phương pháp là nếu có các quy trình Java dễ bị tấn công trên hệ thống của người dùng chỉ chấp nhận các kết nối mạng từ máy chủ cục bộ (localhost) hoặc xử lý các yêu cầu RMI (Gọi phương pháp từ xa, cổng 1099), cuộc tấn công có thể được thực hiện bằng mã JavaScript được thực thi khi người dùng mở một trang độc hại trong trình duyệt. Để thiết lập kết nối với cổng mạng của ứng dụng Java trong một cuộc tấn công như vậy, API WebSocket được sử dụng, không giống như các yêu cầu HTTP, không có giới hạn về nguồn gốc giống nhau được áp dụng (WebSocket cũng có thể được sử dụng để quét các cổng mạng trên cục bộ máy chủ để xác định trình điều khiển mạng khả dụng).
Kết quả đánh giá lỗ hổng của các thư viện liên quan đến phụ thuộc với Log4j do Google công bố cũng rất được quan tâm. Theo Google, sự cố ảnh hưởng đến 8% tất cả các gói trong kho Maven Central.
Đặc biệt, 35863 gói Java liên quan đến Log4j với sự phụ thuộc trực tiếp và gián tiếp đã bị lộ lỗ hổng bảo mật. Ngược lại, Log4j được sử dụng như một phần phụ thuộc trực tiếp của cấp độ đầu tiên chỉ trong 17% trường hợp và trong 83% các gói được bao phủ bởi lỗ hổng bảo mật, việc ràng buộc được thực hiện thông qua các gói trung gian phụ thuộc vào Log4j, nghĩa là. phụ thuộc của cấp độ thứ hai và cao nhất (21% - cấp độ thứ hai, 12% - cấp độ thứ ba, 14% - cấp độ thứ tư, 26% - cấp độ thứ năm, 6% - cấp độ thứ sáu).
Tốc độ sửa chữa lỗ hổng vẫn còn nhiều điều mong muốn, một tuần sau khi lỗ hổng được xác định, trong số 35863 gói được xác định, vấn đề đã được khắc phục cho đến nay chỉ trong 4620, tức là ở mức 13%.
Thay đổi gói là cần thiết để cập nhật các yêu cầu phụ thuộc và thay thế các ràng buộc phiên bản cũ bằng các phiên bản cố định của Log4j 2 (các gói Java thực hành liên kết với một phiên bản cụ thể, chứ không phải một phạm vi mở cho phép cài đặt phiên bản mới nhất).
Việc loại bỏ lỗ hổng trong các ứng dụng Java bị cản trở bởi thực tế là các chương trình thường bao gồm bản sao của các thư viện trong quá trình phân phối và việc cập nhật phiên bản Log4j 2 trong gói hệ thống là không đủ.
Trong khi đó, Cơ quan Bảo vệ Cơ sở hạ tầng và An ninh mạng Hoa Kỳ đã ban hành chỉ thị khẩn cấp yêu cầu các cơ quan liên bang xác định các hệ thống thông tin bị ảnh hưởng bởi lỗ hổng Log4j và cài đặt các bản cập nhật chặn sự cố trước ngày 23/XNUMX.
Mặt khác, một hướng dẫn đã được đưa ra cho đến ngày 28 tháng 23, trong đó các tổ chức có nghĩa vụ báo cáo về công việc đã thực hiện. Để đơn giản hóa việc xác định các hệ thống có vấn đề, một danh sách các sản phẩm có biểu hiện của lỗ hổng bảo mật đã được xác nhận đã được chuẩn bị (có hơn XNUMX nghìn ứng dụng trong danh sách).
Cuối cùng, Điều đáng nói là lỗ hổng đã được sửa trong Log4j 2.17 được xuất bản cách đây vài ngày và người dùng đã vô hiệu hóa các bản cập nhật được khuyến nghị nên thực hiện cập nhật tương ứng, ngoài ra, nguy cơ của lỗ hổng bảo mật được giảm thiểu do sự cố chỉ biểu hiện trên các hệ thống có Java 8.
Fuente: https://logging.apache.org/