Lỗ hổng Log4j hoặc “Nhật ký4Shell,” được coi là một trong những lỗi phần mềm thảm khốc nhất từ ​​trước đến nay. Apache đã vá lỗ hổng này vào tháng 2021 năm XNUMX, tuy nhiên nó vẫn là mối lo ngại đối với các nhóm bảo mật. Trên thực tế, nó vẫn nằm trong số lỗ hổng bảo mật được khai thác nhiều nhất.

Log4Shell vẫn tồn tại vì gói phần mềm Apache Log4j 2 mà nó ảnh hưởng là một trong những thư viện ghi nhật ký được sử dụng rộng rãi nhất trên thế giới. Theo báo cáo, việc tìm kiếm và sửa chữa mọi phiên bản của Log4Shell dự kiến ​​sẽ mất một thập kỷ. Bộ An ninh Nội địa Hoa Kỳ.

Trong thời gian chờ đợi, các nhóm bảo mật có thể thực hiện một số bước để tăng tốc độ giảm thiểu và khắc phục Log4Shell trong mạng của họ. 

Hiểu các lỗ hổng Log4j  

Trước khi đi sâu vào cách phát hiện và vá Log4Shell, điều quan trọng là phải hiểu bản chất của lỗ hổng.

log4j là một trình ghi nhật ký nguồn mở (được duy trì bởi Quỹ phần mềm Apache) để ghi lại thông tin và sự kiện trong một chương trình. Log4j không phải là phần mềm độc lập mà là một gói mã mà các nhà phát triển có thể cắm vào ứng dụng Java của riêng họ. Khung Apache Log4j được sử dụng trong một số dịch vụ lớn nhất trên web, từ cơ sở hạ tầng mạng như Amazon Web Services (AWS) và các giải pháp của Cisco cho đến các ứng dụng phổ biến như Twitter và Minecraft.

Một số phiên bản của Log4j—cụ thể là Log4j 2.17.0 trở xuống—có lỗ hổng nghiêm trọng. Trong đó nguy hiểm nhất là Nhật ký4Shell (CVE-2021-44228; xếp hạng CVSS: 10), thực thi mã từ xa (RCE) lỗ hổng zero-day được tìm thấy trong Log4j phiên bản 2.14.1 trở về trước. 

Log4Shell là kết quả của cách các phiên bản dễ bị tấn công của Log4j xử lý Giao diện thư mục và đặt tên Java (JNDI), một API mà ứng dụng Java sử dụng để truy cập tài nguyên được lưu trữ trên máy chủ bên ngoài. Các tác nhân đe dọa có thể chiếm gần như toàn bộ quyền kiểm soát các hệ thống dễ bị tấn công bằng cách gửi các lệnh tra cứu JNDI độc hại thông qua Log4j. Các lệnh này lừa ứng dụng chạy mã tùy ý có thể thực hiện hầu hết mọi thứ: ăn cắp dữ liệu, cài đặt, dựng lên ransomware, loại bỏ thiết bị ngoại tuyến và hơn thế nữa.

Các cuộc tấn công Log4Shell

Một Log4Shell điển hình Tấn công mạng hoạt động như thế này: 

1. Tin tặc thiết lập máy chủ bằng giao thức phổ biến, như Giao thức truy cập thư mục hạng nhẹ (LDAP) hoặc Hệ thống tên miền (DNS). 
2. Tin tặc lưu trữ phần mềm độc hại hoặc một số tải trọng độc hại khác trên máy chủ.
3. Tin tặc gửi bản tra cứu JNDI tới một ứng dụng chạy Log4j, hướng ứng dụng đó đến máy chủ của tin tặc. 
4. Việc tra cứu JNDI khiến ứng dụng kết nối với máy chủ của hacker, tải xuống tải trọng độc hại và thực thi mã độc. 

Các lỗ hổng Log4j liên quan và cách chúng bị khai thác

Khi Apache vá lỗi Log4Shell, các nhà nghiên cứu bảo mật đã xác định được một số lỗ hổng liên quan trong một số phiên bản của Log4j. Bao gồm các: 

• CVE-2021-45046 cho phép tin tặc gửi bản tra cứu JNDI độc hại tới các hệ thống sử dụng một số cài đặt không mặc định nhất định, ngay cả khi các hệ thống đó đã sửa lỗi Log4Shell. Có mặt trong phiên bản Log4j 2.15 trở xuống.  
• CVE-2021-45105 cho phép tin tặc khởi chạy sự từ chối của dịch vụ tấn công bằng cách gửi tin nhắn độc hại tới Log4j. Có mặt trong Log4j phiên bản 2.16 trở xuống. 
• CVE-2021-44832 là một lỗ hổng thực thi mã từ xa. Lỗ hổng này ít nghiêm trọng hơn Log4Shell vì tin tặc cần có được quyền nâng cao trước khi có thể khai thác nó. Có mặt trong Log4j phiên bản 2.17 trở xuống.  

Cách phát hiện lỗ hổng Log4j   

Việc tìm kiếm mọi phiên bản dễ bị tấn công của Log4j trong mạng có thể khó khăn. Log4j xuất hiện theo ước tính hàng triệu ứng dụng, nghĩa là đội an ninh có rất nhiều tài sản cần kiểm tra. 

Hơn nữa, Log4j thường xuất hiện dưới dạng phụ thuộc gián tiếp. Điều đó có nghĩa là nó không được chứa trực tiếp trong mã nguồn của nội dung mà xuất hiện dưới dạng phần phụ thuộc của gói phần mềm hoặc sự tích hợp mà nội dung đó dựa vào. báo cáo của Google rằng hầu hết các phiên bản Log4j dễ bị tổn thương đều nằm sâu hơn một cấp trong chuỗi phụ thuộc và một số có chiều sâu tới chín cấp.

Điều đó có nghĩa là các nhóm bảo mật có thể phát hiện các lỗ hổng Log4j bằng các chiến thuật và công cụ phù hợp.  

Bạn cần tìm gì

Mọi phiên bản Log4j 2 từ 2.0-beta9 đến 2.17 đều dễ bị tấn công bởi Log4Shell hoặc một lỗ hổng liên quan. Nói cách khác, các nhóm bảo mật phải tìm và xử lý bất kỳ phiên bản nào của Log4j trước 2.17.1.

Log4Shell và các lỗ hổng liên quan của nó chỉ xuất hiện trong các tệp “Log4j-core”, cung cấp chức năng cốt lõi của Log4j. Các lỗ hổng không xuất hiện trong các tệp “Log4j-api”, tệp này kiểm soát giao diện giữa các ứng dụng và trình ghi nhật ký Log4j.

Log4j có thể xuất hiện trong tài sản mà công ty kiểm soát, tài sản của bên thứ ba mà công ty sử dụng (ví dụ: dịch vụ đám mây) và tài sản được sử dụng bởi các nhà cung cấp dịch vụ có quyền truy cập vào mạng công ty. Mặc dù Log4j có nhiều khả năng xuất hiện nhất trong các ứng dụng dựa trên Java nhưng nó cũng có thể xuất hiện trong các ứng dụng không phải Java thông qua các phần phụ thuộc và tích hợp.

Trong các ứng dụng Java, các thư viện như Log4j thường được đóng gói trong các tệp Lưu trữ Java hoặc “tệp JAR”. Các tệp JAR có thể chứa các tệp JAR khác, do đó các tệp JAR này có thể chứa các tệp JAR của riêng chúng, v.v. Để tìm tất cả các phiên bản dễ bị tấn công của Log4j, nhóm bảo mật phải kiểm tra tất cả các cấp độ của tệp JAR, không chỉ các tệp cấp cao nhất.

Làm thế nào để tìm thấy nó 

Các chuyên gia khuyên bạn nên sử dụng kết hợp các kỹ thuật để tìm lỗ hổng Log4j.

Tìm kiếm thủ công. Các nhóm bảo mật có thể tìm kiếm lỗ hổng Log4j theo cách thủ công. Họ có thể sử dụng các công cụ phát triển như Apache Maven để tạo cây phụ thuộc ánh xạ tất cả các phần phụ thuộc trong một ứng dụng hoặc họ có thể sử dụng các công cụ bên ngoài mối đe dọa tình báo để xác định tài sản bị ảnh hưởng. Ví dụ: Cơ quan An ninh mạng và Cơ sở hạ tầng (CISA) đã biên soạn một danh sách các phần mềm được biết là bị ảnh hưởng bởi Log4Shell. Danh sách có sẵn trên GitHub.

Trên các hệ điều hành Linux, Microsoft Windows và macOS, nhóm bảo mật có thể tìm kiếm các thư mục tệp để tìm phiên bản của Log4j bằng giao diện dòng lệnh.

Công cụ quét lỗ hổng. Sau phát hiện của Log4Shell, một số tổ chức đã phát hành các công cụ miễn phí được thiết kế để tìm ra lỗ hổng Log4j. Những ví dụ bao gồm Công cụ đánh hơi Log4j của Palantir và máy quét của Trung tâm Điều phối CERT, trong số nhiều người khác.

Trong khi các máy quét chuyên dụng vẫn có sẵn, nhiều giải pháp bảo mật tiêu chuẩn như máy quét lỗ hổng, quản lý bề mặt tấn công nền tảng (ASM) và phát hiện điểm cuối và phản hồi (EDR) hiện có thể phát hiện các lỗ hổng Log4j.

Vì Log4Shell có thể ẩn sâu trong chuỗi phụ thuộc nên các nhóm bảo mật có thể bổ sung quá trình quét tự động bằng nhiều phương pháp thực hành hơn, như kiểm tra thâm nhập.

Săn lùng mối đe dọa. Theo CISA, những kẻ tấn công đã được biết là sử dụng Log4Shell để đột nhập vào mạng và sau đó vá tài sản mà chúng đã xâm phạm để che dấu vết. Vì lý do đó, các nhóm bảo mật nên cho rằng hành vi vi phạm đã xảy ra và tích cực săn lùng để biết các dấu hiệu khai thác Log4Shell.

Các công cụ an ninh mạng như thông tin bảo mật và quản lý sự kiệngiải pháp t (SIEM) và phát hiện và phản hồi mở rộng Nền tảng (XDR) có thể giúp phát hiện hoạt động bất thường liên quan đến Log4Shell, như các mục nhật ký lạ hoặc mẫu lưu lượng truy cập đáng ngờ. Đội an ninh nên khởi động đầy đủ ứng phó sự cố và các quy trình điều tra để tìm bất kỳ dấu hiệu nào có thể có của Log4Shell, tùy theo mức độ nghiêm trọng của hậu quả của một cuộc tấn công.

Cách khắc phục lỗ hổng Log4j

Các nhóm bảo mật có một số tùy chọn khi giải quyết các lỗ hổng Log4j.

Trường hợp tốt nhất: vá các hệ thống dễ bị tổn thương  

Để khắc phục hoàn toàn Log4Shell và các lỗi liên quan, các tổ chức phải cập nhật tất cả các phiên bản của Log4j trong mạng của họ lên phiên bản mới nhất (hoặc ít nhất là phiên bản 2.17.1). Các phiên bản mới nhất của Log4j loại bỏ các chức năng mà kẻ tấn công có thể khai thác và loại bỏ hỗ trợ cho các giao thức thường bị lạm dụng như LDAP.

Không có bản vá duy nhất cho toàn hệ thống và việc cập nhật Java không giải quyết được vấn đề. Các nhóm bảo mật phải cập nhật mọi phiên bản của Log4j trong mọi tài sản bị ảnh hưởng. 

Các biện pháp giảm thiểu khác

Các nhà nghiên cứu bảo mật đồng ý rằng vá là giải pháp lý tưởng. Nếu việc vá lỗi không khả thi, các tổ chức có thể sử dụng các bước giảm thiểu khác để giảm thiểu nguy cơ bị tấn công.

Không cho phép tra cứu tin nhắn trong các ứng dụng dễ bị tấn công. Những kẻ tấn công sử dụng một tính năng của Log4j có tên là “thay thế tra cứu tin nhắn” để gửi các lệnh độc hại đến các ứng dụng dễ bị tấn công. Các nhóm bảo mật có thể không cho phép chức năng này theo cách thủ công bằng cách thay đổi thuộc tính hệ thống “Log4j2.formatMsgNoLookups” thành “true” hoặc đặt giá trị của biến môi trường “LOG4J_FORMAT_MSG_NO_LOOKUPS” thành “true”.  

Mặc dù việc loại bỏ chức năng thay thế tra cứu tin nhắn khiến kẻ tấn công khó tấn công hơn nhưng đó không phải là biện pháp hoàn hảo. Kẻ độc hại vẫn có thể sử dụng CVE-2021-45046 để gửi bản tra cứu JNDI độc hại tới các ứng dụng có cài đặt không mặc định.

Xóa lớp JNDIlookup khỏi các ứng dụng dễ bị tấn công. Trong Log4j, lớp JNDIlookup quản lý cách trình ghi nhật ký xử lý việc tra cứu JNDI. Nếu lớp này bị xóa khỏi thư mục các lớp của Log4j thì việc tra cứu JNDI sẽ không thể được thực hiện nữa.

Apache lưu ý lệnh sau có thể được sử dụng để xóa lớp JNDIlookup khỏi các ứng dụng dễ bị tấn công:   

zip -q -d Log4j-core-*.jar org/apache/logging/Log4j/core/lookup/JndiLookup.class

Mặc dù phương pháp này hiệu quả hơn việc không cho phép tra cứu tin nhắn nhưng nó không ngăn được kẻ tấn công thực hiện các nỗ lực khai thác khác, như kích hoạt các cuộc tấn công từ chối dịch vụ thông qua tra cứu đệ quy.

Chặn lưu lượng tấn công Log4Shell tiềm ẩn. Đội an ninh có thể sử dụng tường lửa ứng dụng web (WAF), Hệ thống phát hiện và ngăn chặn xâm nhập (IDPS), EDR và ​​​​các công cụ an ninh mạng khác để chặn lưu lượng truy cập đến và đi từ các máy chủ do kẻ tấn công kiểm soát bằng cách chặn các giao thức thường được sử dụng như LDAP hoặc RMI. Đội bảo mật cũng có thể chặn Địa chỉ IP liên quan đến các cuộc tấn công hoặc các chuỗi mà kẻ tấn công thường sử dụng trong các yêu cầu độc hại, chẳng hạn như “jndi”, “ldap” và “rmi”.

Tuy nhiên, kẻ tấn công có thể vượt qua các biện pháp phòng vệ này bằng cách sử dụng các giao thức và địa chỉ IP mới hoặc làm xáo trộn các chuỗi độc hại.

Cách ly tài sản bị ảnh hưởng. Nếu vẫn thất bại, nhóm bảo mật có thể cách ly các tài sản bị ảnh hưởng trong khi chờ bản vá. Một cách để thực hiện điều này là đặt các tài sản dễ bị tấn công vào một phân đoạn mạng biệt lập không thể truy cập trực tiếp từ internet. Một WAF có thể được đặt xung quanh phân đoạn mạng này để tăng cường bảo vệ.

Giữ Log4Shell luôn hoạt động

Một trong những điều khó khăn khi khắc phục Log4Shell là nó không phải lúc nào cũng được vá. Vào tháng 2022 năm XNUMX, Đã báo cáo có thể thuê được rằng 29% tài sản vẫn dễ bị Log4Shell tấn công là “tái phát”, nghĩa là chúng đã được vá, nhưng lỗ hổng lại xuất hiện. Sự cố tái diễn xảy ra khi nhà phát triển vô tình sử dụng thư viện phần mềm chứa các phiên bản Log4j chưa được vá để xây dựng hoặc cập nhật ứng dụng.

Mặc dù các nhà phát triển có thể xem xét kỹ lưỡng các khung mà họ sử dụng chặt chẽ hơn nhưng rất dễ bỏ lỡ các phiên bản dễ bị tấn công của Log4j khi chúng ở sâu một số cấp độ trong tệp JAR.

Thực hiện chính thức quản lý lỗ hổng và quản lý bản vá các chương trình có thể cung cấp cho nhóm bảo mật một cách hiệu quả hơn để giám sát tài sản nhằm phát hiện lỗ hổng Log4j. Quét lỗ hổng bảo mật và kiểm tra thâm nhập thường xuyên có thể giúp nhanh chóng phát hiện các lỗ hổng mới, Log4Shell hoặc các lỗ hổng khác. Quản lý bản vá đảm bảo các lỗ hổng mới được đóng ngay khi nhà cung cấp phát hành bản sửa lỗi.   

Trợ giúp thêm về việc chống lại Log4Shell và các lỗ hổng zero-day khác

Ngày càng có nhiều tin tặc sử dụng các công cụ tự động để khai thác các lỗ hổng zero-day như Log4Shell một cách dễ dàng—và khởi động một loạt các cuộc tấn công bằng ransomware cũng như các mối đe dọa mạng khác. Các nhóm bảo mật làm việc với các phương pháp bảo mật điểm cuối truyền thống phải đối mặt với sự mệt mỏi do cảnh báo, công cụ phức tạp và các cuộc điều tra kéo dài—và phải vật lộn để theo kịp.

IBM Security® QRadar® EDR, trước đây là ReaQta, khắc phục các mối đe dọa điểm cuối đã biết và chưa biết trong thời gian gần bằng tính năng tự động hóa thông minh dễ sử dụng, yêu cầu ít hoặc không cần sự tương tác của con người. Với QRadar EDR, các nhà phân tích có thể đưa ra quyết định nhanh chóng, sáng suốt và sử dụng tính năng quản lý cảnh báo tự động để tập trung vào các mối đe dọa quan trọng nhất. Khả năng AI học tập liên tục nâng cao và giao diện thân thiện với người dùng giúp nhân viên bảo mật lấy lại quyền kiểm soát và giúp bảo vệ tính liên tục của hoạt động kinh doanh.

Khám phá IBM Security QRadar EDR