Lỗ hổng Log4j tồn tại trong một thành phần không phải lúc nào cũng dễ phát hiện và được sử dụng rộng rãi trong hệ thống và mạng của nhiều tổ chức.
Các nhóm bảo mật đang nổ lực làm việc để giảm thiểu khả năng lây nhiễm của tổ chức họ với lỗ hổng Log4j có rất nhiều thách thức cần phải vượt qua. Bao gồm xác định phạm vi toàn bộ mức độ phơi nhiễm, tìm ra giải pháp thay thế cho các hệ thống không thể vá và đảm bảo các sản phẩm và dịch vụ của bên thứ ba đã được bảo mật.
Đối với nhiều người, nhiệm vụ sẽ phức tạp hơn nữa do cần phải liên tục theo dõi các dấu hiệu của những kẻ tấn công đang cố gắng khai thác lỗ hổng hoặc các dấu hiệu mà chúng có thể đã bị xâm phạm, các chuyên gia bảo mật cho biết trong tuần này.
Log4j là một công cụ ghi nhật ký có mặt trong hầu hết các ứng dụng Java. Một lỗ hổng thực thi mã từ xa quan trọng (CVE-2021-44228) tồn tại trong các phiên bản Log4j từ 2.0-beta9 đến 2.14.1 cho phép kẻ tấn công kiểm soát hoàn toàn các hệ thống dễ bị tấn công. Apache Foundation đã phát hành phiên bản cập nhật của công cụ (Apache Log4j 2.15.0) vào tuần trước, sau đó phát hành bản cập nhật thứ hai vào thứ Ba vì bản sửa lỗi ban đầu không bảo vệ hoàn toàn khỏi các cuộc tấn công từ chối dịch vụ (DoS) và đánh cắp dữ liệu.
Lỗ hổng được coi là một trong những lỗ hổng nguy hiểm nhất trong bộ nhớ gần đây vì nó rất dễ khai thác và hiện diện trên hầu hết mọi môi trường CNTT. Veracode, chẳng hạn, cho thấy 88% khách hàng của họ sử dụng một số phiên bản Log4j và 58% có phiên bản dễ bị tấn công trong môi trường của họ.
Những kẻ tấn công trên khắp thế giới đã cố gắng khai thác lỗ hổng này ngay từ khi nó được tiết lộ lần đầu tiên vào tuần trước. Nhiều nhà cung cấp đã quan sát thấy những nỗ lực phân phối các máy đào coin, ransomware, Trojan truy cập từ xa, Web shell và phần mềm độc hại botnet. Armis hôm thứ Tư báo cáo khoảng 35% khách hàng của họ đang bị tấn công thông qua lỗ hổng bảo mật và 31% có mối đe dọa liên quan đến Log4j trên các thiết bị không được quản lý. Nhà cung cấp bảo mật cho biết họ đã quan sát thấy 30.000 nỗ lực khai thác chống lại khách hàng của mình. Một số nhà cung cấp khác đã báo cáo hoạt động tương tự.
Armis nhận thấy các tài sản được nhắm mục tiêu nhiều nhất trong môi trường CNTT cho đến nay là máy chủ, máy ảo và thiết bị di động. Trong mạng OT, 49% thiết bị bị xâm nhập là máy ảo và 43% là máy chủ. Các thiết bị được nhắm mục tiêu khác trong mạng OT bao gồm camera IP, thiết bị giao diện người máy (HMI) và hệ thống SCADA.
Theo các chuyên gia bảo mật, một thách thức lớn mà các tổ chức phải đối mặt trong việc bảo vệ chống lại các cuộc tấn công nhắm vào Log4j là tìm ra khả năng phơi nhiễm của chúng với mối đe dọa. Lỗ hổng bảo mật có thể xuất hiện không chỉ trên các tài sản tiếp xúc với Internet của một tổ chức mà còn trên các hệ thống nội bộ và hệ thống back-end, thiết bị chuyển mạch mạng, SIEM và các hệ thống ghi nhật ký khác, các ứng dụng của bên thứ ba và được phát triển nội bộ, trong SaaS và các dịch vụ đám mây cũng như các môi trường mà chúng thậm chí có thể không biết về. Sự phụ thuộc lẫn nhau giữa các ứng dụng và thành phần khác nhau có nghĩa là ngay cả khi một thành phần không trực tiếp có lỗ hổng bảo mật, nó vẫn có thể bị ảnh hưởng bởi nó.
Noname Security cho biết cách đóng gói Java thường có thể khiến việc xác định các ứng dụng bị ảnh hưởng trở nên khó khăn. Ví dụ: tệp lưu trữ Java (JAR) có thể chứa tất cả các thành phần phụ thuộc – bao gồm cả thư viện Log4j – của một thành phần cụ thể. Nhưng tệp JAR đó có thể chứa một tệp JAR khác, đến lượt nó, có thể chứa thêm một tệp JAR khác – về cơ bản là chôn sâu lỗ hổng bảo mật nhiều lớp, nhà cung cấp bảo mật cho biết.
Gustavo Palazolo, kỹ sư nghiên cứu mối đe dọa tại Netskope cho biết: “Một trong những thách thức chính mà các tổ chức phải đối mặt trong việc giảm thiểu các lỗ hổng được tìm thấy trong Log4j là xác định tất cả các tài sản bị xâm phạm. Ông cho biết thêm, thư viện ghi nhật ký dựa trên Java Log4j Apache rất phổ biến và có thể được sử dụng bởi nhiều ứng dụng, cũng như các thiết bị IoT và hệ thống kế thừa được duy trì để tương thích ngược.
Ngay cả khi một ứng dụng được phát hiện là có lỗ hổng, việc cập nhật nó có thể khó khăn vì một tổ chức có thể không đủ khả năng dành thời gian ngừng hoạt động hoặc thiếu các biện pháp kiểm soát quản lý bản vá thích hợp.
“Do đó, thời gian giữa việc xác định tất cả các hệ thống bị xâm nhập và khắc phục sự cố có thể mất nhiều thời gian trong một số trường hợp”, Palazolo nói.
Ứng dụng không phải là vấn đề duy nhất. Lỗ hổng Log4j cũng có thể ảnh hưởng đến môi trường giao diện lập trình ứng dụng (API). Noname cho biết các máy chủ API chứa lỗ hổng bảo mật cung cấp một vectơ tấn công hấp dẫn bởi vì nhiều tổ chức có khả năng hiển thị hạn chế đối với kho API và hành vi của các API của họ. Một doanh nghiệp không sử dụng khuôn khổ ghi nhật ký Log4j có thể đang sử dụng các API của bên thứ ba đáng tin cậy có chứa lỗ hổng Log4j, do đó khiến nó gặp rủi ro.
Aner Morag, phó chủ tịch công nghệ của Noname Security cho biết: “Để một tổ chức giảm thiểu nguy cơ bị khai thác lỗ hổng Log4j thông qua API, cần phải thực hiện một số bước. Chúng bao gồm tham chiếu tất cả các máy chủ đang cung cấp API với bất kỳ dịch vụ Java nào, không cho phép bất kỳ đầu vào nào của người dùng tiếp cận thông báo nhật ký trên bất kỳ máy chủ API nào, sử dụng proxy hoặc cơ chế khác để kiểm soát máy chủ nào mà dịch vụ back-end có thể kết nối và đặt các API đằng sau cổng API hoặc bộ cân bằng tải, Morag nói.
Một thách thức khác mà các tổ chức phải đối mặt là đảm bảo tất cả các sản phẩm và dịch vụ của bên thứ ba mà họ sử dụng được vá đúng cách hoặc có các biện pháp giảm thiểu lỗ hổng.
Tom Gorup, phó chủ tịch hoạt động bảo mật của Alert Logic cho biết: “Rất nhiều sản phẩm của nhà cung cấp bị ảnh hưởng, danh sách các nhà cung cấp bị ảnh hưởng đang tăng lên hàng ngày. “Không phải tất cả các nhà cung cấp đều có thể có sẵn các bản vá lỗi.”
Gorup khuyến nghị các nhóm bảo mật nên kiểm tra trang web của nhà cung cấp hoặc liên hệ trực tiếp với họ để biết liệu có bất kỳ sản phẩm nào của họ bị ảnh hưởng hay không. Một nhà cung cấp có thể dễ bị tấn công nhưng đã đưa ra các bước giảm thiểu để bảo vệ khách hàng của mình.
Nguồn: darkreading.com
