Lỗ hổng bảo mật Log4Shell của Apache Log4j là một thảm họa mã khủng khiếp mọi thời đại. Theo số lượng Cơ sở dữ liệu lỗ hổng quốc gia (NVD), nó có điểm CVSSv3 là 10.0. Đó là trên thang điểm 0,1 đến 10.
Là người đứng đầu bộ phận nghiên cứu của công ty bảo mật Nextron Systems, Florian Roth đã tweet, “Lỗ hổng #Log4Shell không chỉ là một RCE [Remote Code Execution] Zero-day. Đó là một lỗ hổng gây ra hàng trăm và hàng nghìn zero-day trong tất cả các loại sản phẩm phần mềm. Đó là một quả bom chùm zero-day”.
Nó đã được vá nhiều tháng trước?. Đúng, đã có một trục trặc bảo mật với bản vá Log4j đầu tiên, nhưng nó đã nhanh chóng được khắc phục. Như vậy liệu bây giờ có thật sự ổn ko?
Không hề nha bros!
Khai thác vẫn tồn tại
Như Cơ quan An ninh Cơ sở hạ tầng và An ninh Mạng Hoa Kỳ (CISA) và Bộ Tư lệnh Mạng của Lực lượng Bảo vệ Bờ biển Hoa Kỳ (CGCYBER) gần đây đã báo cáo trong một thông báo Chung về Tư vấn An ninh mạng (CSA), tin tặc, bao gồm các tác nhân đe dọa dai dẳng nâng cao (APT) do nhà nước tài trợ, vẫn đang khai thác CVE-2021-44228 (Log4Shell) trong VMware Horizon và Unified Access Gateway (UAG).
Nhưng mà vẫn còn nữa!
Báo cáo của Hội đồng Đánh giá An toàn Mạng (CSRB) của Bộ An ninh Nội địa Hoa Kỳ (DHS) về Log4j, cho thấy “Sự kiện Log4j vẫn chưa kết thúc. Log4j vẫn được nhúng sâu vào các hệ thống và ngay cả trong khoảng thời gian ngắn có sẵn để chúng ta xem xét, các bên liên quan trong cộng đồng đã xác định được những thỏa hiệp, các tác nhân đe dọa và những bài học mới.
Các cuộc tấn công vẫn tiếp diễn và không dừng lại. Theo Chad Skipper, Nhà công nghệ bảo mật toàn cầu(Global Security Technologist) của VMware, cho biết, “Kể từ tháng 01 năm 2022, VMware NSX Network Detection and Response đã theo dõi hơn 25 triệu hoạt động khai thác Log4j.” Và có rất nhiều tổ chức ngoài kia không có bất kỳ hệ thống bảo mật nào bảo vệ và theo dõi các vấn đề của họ.
Log4j ở khắp mọi nơi
Tại sao Log4j lại là một lỗ hỏng dai dẳng? Trước tiên, Log4j là một module ghi nhật ký dựa trên mã nguồn mở Java nổi tiếng. Vì vậy, nó đã được nhúng vào hàng ngàn gói phần mềm khác nhau. Log4j có trong hàng ngàn chương trình. Như xát thêm muối vào trái tim, Log4j thường được nhúng sâu vào mã và giấu kĩ do chỉ được gọi vào bởi các thành phần phụ thuộc gián tiếp(indirect dependencies).
Vì vậy, CSRB tuyên bố rằng “Những nhà bảo mật phải đối mặt với một tình huống đặc biệt thách thức; lỗ hổng bảo mật đã ảnh hưởng đến hầu hết mọi tổ chức được nối mạng và mức độ nghiêm trọng của mối đe dọa đòi hỏi phải hành động nhanh chóng. Vấn đề còn tồi tệ hơn thế, theo CSRB, “Không có đối tượng nạn nhân cụ thể cho Log4j hoặc thậm chí là nó được tích hợp như một hệ thống con ở khắp nơi.”
Vì vậy, “Các doanh nghiệp đã nhanh chóng đào sâu nơi họ sử dụng Log4j. Tốc độ, áp lực và sự công khai làm gia tăng thách thức bảo mật: các nhà nghiên cứu bảo mật nhanh chóng tìm thấy các lỗ hổng bổ sung trong Log4j, việc này lại gây ra nhiều nhầm lẫn và ‘vá lỗi mỏi tay không hết’; những System Admin đã phải vật lộn để phân biệt các lỗ hổng của các nhà nghiên cứu phát hiện với các mối nguy hại và họ đã khó khăn trong việc tìm kiếm các nguồn thông tin chính xác về cách giải quyết các vấn đề. “CSRB cho biết.
Những người giỏi nhất từ cộng đồng open source đã cộng tác trong suốt thời gian này. Họ phần lớn đã thành công trong việc tìm kiếm và sửa chữa các lỗi. Tuy nhiên, CSRB tuyên bố rằng “rất ít tổ chức có thể phản ứng” một cách nhanh chóng hoặc hiệu quả khi cần thiết. Một phần của vấn đề là triển khai các bản vá lỗi là “cũng là một quyết định rủi ro, buộc phải đánh đổi giữa sự gián đoạn hoạt động có thể xảy ra và tính kịp thời, đầy đủ và bù đắp các biện pháp kiểm soát.”
Bạn có thể làm gì
Vậy, chúng ta có thể làm gì? CSRB có nhiều gợi ý tốt về cách bảo vệ bản thân. Hầu hết trong số này, bạn đã – hoặc ít nhất là bạn nên – biết.
Nhưng nếu bạn chưa làm – và nếu bạn lười chưa làm – thì đã đến lúc bạn phải làm thôi. Nói chung, như Hội đồng CSRB tuyên bố, Log4j là một “lỗ hổng đặc hữu” và “các trường hợp dễ bị tấn công của Log4j sẽ vẫn còn trong các hệ thống trong nhiều năm tới.”
Hiện tại, thông điệp đến từ Phó chủ tịch phụ trách cơ sở hạ tầng của Google, Eric Brewer. “Nếu bạn đang sử dụng Open Source, bạn không thể mong đợi người khác khắc phục các vấn đề bảo mật cho bạn.”Do vậy, trừ khi bạn ko sử dụng Open Source, bạn phải giúp duy trì và vá các lỗi của nó.
Dịch Kent Juno.
Nguồn.
