Cùng với việc một lỗ hổng dễ bị khai thác và cực kỳ nguy hiểm trong thư viện ghi nhật ký Java - Apache Log4j đã được công bố rộng rãi trong thời gian qua, các nhà nghiên cứu hiện cũng đã tìm thấy một lỗ hổng mới trong bản vá của Apache được phát hành để giảm thiểu những hậu quả do Apache Log4j gây ra.
Ngày 9/12, các nhà nghiên cứu bảo mật đã bắt đầu cảnh báo, một lỗ hổng được theo dõi là CVE-2021-44228 trong Apache Log4j đang bị tấn công tích cực. Một loạt tin tặc đã ngay lập tức tấn công Log4Shell, ban đầu là để kích hoạt mã độc trên máy chủ hoặc máy khách chạy bản Java của Minecraft bằng cách thao tác các tin nhắn nhật ký, bao gồm cả tin nhắn văn bản. Sau đó, những kẻ tấn công bắt đầu phân nhánh, tạo ra 60 đột biến chỉ trong vòng một ngày.
Và Apache đã phải vội vàng phát hành một bản vá để sửa lỗi Log4Shell - phiên bản Log4j 2.15.0 vào ngày 10/12.
Bản vá để sửa lỗi Log4Shell có thể mở đường cho các cuộc tấn công từ chối dịch vụ (DoS).
Nhưng sau đó, các nhà nghiên cứu lại đã phát hiện ra rằng, trong một số trường hợp nhất định, bản sửa lỗi này "không hoàn chỉnh với một số cấu hình không phải mặc định" và mở đường cho các cuộc tấn công từ chối dịch vụ (DoS), theo lời khuyên từ Apache.org.
Theo Apache.org, lỗ hổng mới được phát hiện là CVE-2021-45046, có thể cho phép những kẻ tấn công có quyền kiểm soát dữ liệu đầu vào "Bản đồ ngữ cảnh luồng" (MDC), tạo ra dữ liệu đầu vào độc hại bằng cách sử dụng mẫu "Tra cứu giao diện thư mục và đặt tên Java" (JNDI) trong một số trường hợp nhất định, dẫn đến một cuộc tấn công DoS.
Việc thiết lập để khai thác là khi cấu hình ghi nhật ký sử dụng "Bố cục mẫu không mặc định" với "Tra cứu ngữ cảnh" - ví dụ: $$ {ctx: loginId} - hoặc mẫu "Bản đồ ngữ cảnh chuỗi" (% X,% mdc hoặc% MDC), theo Apache.org.
Vẫn theo Apache.org, "Log4j 2.15.0 hạn chế tra cứu JNDI LDAP (một giao thức phát triển trên chuẩn X500, dạng client-server sử dụng để truy cập một dịch vụ thư mục, cho phép người dùng xác định cấu trúc và đặc điểm của thông tin trong thư mục) đối với máy chủ cục bộ theo mặc định. Lưu ý rằng các biện pháp giảm nhẹ trước đây liên quan đến cấu hình, chẳng hạn như đặt thuộc tính hệ thống `log4j2.noFormatMsgLookup` thành `true` không làm giảm thiểu lỗ hổng cụ thể này."
Khắc phục sự cố
Theo lời khuyên từ Apache.org, bản phát hành mới của Log4j, phiên bản 2.16.0, khắc phục sự cố bằng cách xóa hỗ trợ cho các mẫu tra cứu thông báo và tắt chức năng JNDI. Apache.org khuyến cáo, để giảm thiểu lỗi trong các bản phát hành Log4j trước đó, các nhà phát triển có thể xóa lớp JndiLookup khỏi classpath.
Một chuyên gia bảo mật lưu ý, có thể Apache đã vội vàng phát hành bản vá cho Log4Shell sau khi có sự hoảng loạn ban đầu về việc phát hiện ra Log4Shell.
John Bambenek tại Netenrich, nhận xét: "Việc gấp rút đưa ra các bản vá để sửa lỗ hổng thường đồng nghĩa với việc sửa chữa đó có thể không hoàn hảo. Ông cho biết giải pháp cho vấn đề là "vô hiệu hóa hoàn toàn chức năng của JNDI."
Vì ít nhất một chục nhóm đã được biết đến là đang khai thác các lỗ hổng này, ông kêu gọi hành động ngay lập tức để vá, xóa JNDI khỏi Log4j hoặc đưa nó ra khỏi classpath - "tốt nhất là tất cả những điều trên," Bambenek nói.
Xử lý tình huống
Một chuyên gia bảo mật khác lưu ý, các nhà nghiên cứu và chuyên gia bảo mật vẫn đang quan tâm đến những tác động sâu rộng của Log4Shell cũng như khả năng còn tồn tại đối với các lỗi liên quan khác.
Casey Ellis, nhà sáng lập và là CTO (giám đốc công nghệ) tại Bugcrowd cho biết: "Khi một lỗ hổng được phát hiện và thu hút được sự quan tâm của mọi người như Log4Shell, nó luôn báo hiệu rằng có thêm lỗ hổng trong cùng một phần mềm hoặc các bản sửa lỗi cho phần mềm đó, và sẽ kích hoạt nghiên cứu, khám phá bổ sung".
Thật vậy, đã có một số nhầm lẫn về số lượng lỗ hổng bảo mật hiện đang tồn tại có liên quan đến Log4Shell và tất cả chúng tương quan với nhau như thế nào, làm tăng thêm lượng thông tin được công bố về lỗi này, các nhà nghiên cứu từ RiskBased Security đã viết trong một bài đăng trên blog.
Theo nhóm RiskBased Security, ở thời điểm hiện tại, có ba CVE đã xuất bản được liên kết với Log4Shell - CVE-2021-44228, zero-day ban đầu; CVE-2021-45046, "bản sửa lỗi không hoàn chỉnh"; và CVE-2021-4104, một lỗ hổng được tìm thấy trong một thành phần khác của Log4j, JMSAppender, dường như không đáng lo ngại,
Trong trường hợp của CVE-2021-44228, các nhà nghiên cứu cho rằng nó không phải là một vấn đề mới, "nhưng thực sự là cùng một lỗ hổng".
Các nhà nghiên cứu viết: "MITER và Cơ quan đánh số CVE (CNA) sẽ chỉ định ID CVE thứ hai trong trường hợp các bản sửa lỗi không hoàn toàn vá được một sự cố an toàn thông tin"
Và mặc dù có nhiều hơn một CVE nhưng "nhiều nơi đã coi chúng như một vấn đề duy nhất, song điều này chắc chắn không phải như vậy," theo RiskBased Security.
Tệ hơn trước khi trở nên tốt hơn
Một điều chắc chắn về "bộ phim kịch tính" xung quanh Log4Shell là phạm vi các cuộc tấn công vào lỗ hổng bảo mật này rất rộng lớn, nên có nhiều tiềm năng để khai thác sâu hơn, theo RiskBased Security.
Các nhà nghiên cứu đã viết: "Điều quan trọng phải nói rằng, Log4j là một khung ghi nhật ký phổ biến trong Java. Điều này có nghĩa là nó được sử dụng trong một số công việc đặc biệt".
Thật vậy, một danh sách dài các sản phẩm của các nhà cung cấp dễ bị tấn công bởi Log4Shell, bao gồm: Broadcom, Cisco, Elasticsearch, F-secure, Fedora, HP, IBM, Microsoft, National Security Agency (NSA), RedHat, SonicWall và VMWare.
Chỉ trong vòng vài giờ kể từ khi công khai lỗ hổng, những kẻ tấn công đã quét tìm các máy chủ dễ bị tấn công và tung ra các cuộc tấn công để đưa các công cụ khai thác tiền điện tử, phần mềm độc hại Cobalt Strike, ransomware Khonsari mới, trojan truy cập từ xa Orcus (RAT). đảo ngược bash shell cho các cuộc tấn công trong tương lai, Mirai và các botnet khác, và backdoor.
Bất cứ điều gì cũng có thể xảy ra trong tương lai, vì các biến thể từ nguyên mẫu được sử dụng cách khai thác ban đầu tiếp tục được tạo ra và những kẻ tấn công tiếp tục hoạt động, tình hình có thể trở nên tồi tệ hơn trước khi nó trở nên tốt hơn. Điều này có nghĩa là "bụi" trên Log4Shell có thể sẽ không "lắng xuống" trong một thời gian dài.
"Lỗ hổng Log4j mới này có thể sẽ ám ảnh chúng ta trong nhiều năm tới," theo RiskBased Security.
Và thật đáng buồn, theo Chris Goettl, Phó chủ tịch quản lý sản phẩm của Ivanti: "Các nỗ lực xác định, giảm thiểu hoặc khắc phục lỗ hổng Apache Log4j vẫn tiếp tục. Trong trường hợp này, rất nhiều đội đã thất vọng vì họ không biết chính xác mình cần phải làm gì. Apache Log4j là một thư viện phát triển, vì vậy bạn không thể chỉ vá một tệp JAR cụ thể. Việc xử lý sự cố này thuộc về nhóm phát triển hoặc các nhà cung cấp sản phẩm mà bạn đang sử dụng".
Tài liệu tham khảo:
[1]. https://threatpost.com/apache-patch-log4shell-log4j-dos-attacks/177064
[2]. https://logging.apache.org/log4j/2.x/security
[3]. https://www.infosecurity-magazine.com/news/log4j-looms-large-over-patch/
