Nghe trộm hacker để phát hiện mối đe dọa

Trong hằng hà sa số lỗ hổng nổi cộm, hầu như không thể biết được vấn đề bảo mật nào cần phải giải quyết trước. Khuyến cáo của nhà cung cấp là nguồn tin cậy để cập nhật thông tin về các kiểu tấn công đã phát hiện. Tuy nhiên có một lựa chọn thích hợp hơn: nghe trộm chính những kẻ tấn công.

Hầu hết qui trình quản lý “yếu huyệt” của các tổ chức đều lệ thuộc vào thông báo của nhà cung cấp. Nhưng những rò rỉ ban đầu về các lỗ hổng bảo mật không phải lúc nào cũng xuất phát từ nhà cung cấp, việc chờ đợi thông báo chính thức có thể mất vài ngày, hoặc thậm chí vài tuần. Trong khi đó biết được một lỗ hổng thì chỉ trong vòng vài giờ là tin tặc đã lập tức thảo luận và chia sẻ hướng dẫn cách thức tấn công.

"Trao đổi trên mạng thường bắt đầu trong vòng 24 - 48 giờ sau tiết lộ ban đầu", theo Levi Gundert, phó chủ tịch của Recorded Future, phụ trách phân tích các mối đe dọa, trích phân tích của công ty về các thảo luận trên các diễn đàn dùng ngôn ngữ ngoài tiếng Anh.

Các khuyến cáo của nhà cung cấp, bài đăng blog, email, cảnh báo của đơn vị ứng phó bảo mật khẩn cấp (CERT) – không chỉ các nhà bảo mật đọc. Biết được mối quan tâm của những kẻ tấn công và việc lập kế hoạch khai thác lỗ hỗng của hacker trước khi nhà cung cấp đưa ra phản ứng là một cách tuyệt vời để chuẩn bị đối phó.

Hacker đàm đạo

Lỗ hổng Java object serialization năm rồi là một ví dụ hoàn hảo. Đầu tiên được tiết lộ tại một cuộc hội thảo hồi tháng 1 năm 2015, lỗ hổng này không được sự chú ý cho đến tận ngày 6 tháng 11, khi các nhà nghiên cứu tại FoxGlove Security phát hiện nó ảnh hưởng đến nhiều ứng dụng doanh nghiệp lõi, chẳng hạn như WebSphere và JBoss. Oracle phải mất thêm 12 ngày còn Jenkins mất 19 ngày để đưa ra thông báo chính thức xác nhận lỗ hổng trong WebLogic Server và Jenkins.

Tuy nhiên, chỉ vài giờ sau cộng đồng hacker đã bắt đầu thảo luận về bài đăng trên trang blog FoxGlove Security, và 6 ngày sau xuất hiện đoạn code khai thác lỗ hổng. Trước khi Oracle công bố 5 ngày, ngày 13 tháng 11 trên các diễn đàn đã có hướng dẫn mô tả chi tiết cách thức thực hiện tấn công. Đến tuần đầu tháng 12, tên của các tổ chức dễ tổn thương và các liên kết cụ thể để kích hoạt lỗ hổng của các mục tiêu đó đã được mua bán trên mạng.

"Rõ ràng thời gian từ lúc thừa nhận lỗ hổng đến khi có bản vá của nhà cung cấp hoặc có cách giải quyết là quí giá đối với những kẻ tấn công, và là hiểm hoạ đối với doanh nghiệp, nhất là khi có hướng dẫn khai thác chi tiết bằng nhiều ngôn ngữ", Gundert nói.

Lỗ hổng OPcache Binary Webshell trong PHP 7 là một ví dụ khác trong việc những kẻ tấn công đi trước cuộc chơi. Hãng bảo mật GoSecure mô tả lỗ hổng mới này trên trang blog của mình vào ngày 27 tháng 4, và Recorded Future phát hiện tài liệu hướng dẫn sử dụng đoạn mã khai thác lỗ hổng này vào ngày 30 tháng 4. Theo GoSecure, lỗ hổng này nói chung không ảnh hưởng đến các ứng dụng PHP. Nhưng với tài liệu hướng dẫn trên, tin tặc có thể dễ dàng tìm các máy chủ có cấu hình dễ bị khai thác lỗ hổng tải lên tập tin.

"Ngay cả các trang blog bí mật cũng bị đào xới", Gundert nói.

Hầu hết mọi người không để ý đến bài đăng trên trang blog của GoSecure. Do có quá nhiều báo cáo, nếu một bài blog không được chú ý nhiều trong giới bảo mật, thì những thảo luận về cách thức tấn công dễ bị ngó lơ. Trong khi đó ở phía bên kia chiến tuyến những kẻ tấn công lại đang thảo luận về lỗ hổng, chia sẻ thông tin và công cụ khai thác nó.

Chờ đợi nhà cung cấp khiến bạn dễ tổn thương hơn

Một nguyên do mà tin tặc đi trước như vậy so nhà cung cấp và chuyên gia bảo mật đó là vì chính qui trình thông báo lỗ hổng.

Nhà cung cấp thường phải đợi đến khi lỗ hổng bảo mật có mã CVE (Common Vulnerability and Exposures) mới công bố. Hệ thống CVE hoạt động phi lợi nhuận dưới sự điều hành của MITRE Corp, cung cấp thông tin về các lỗ hổng bảo mật đã được công bố. Khi ai đó tìm thấy một lỗ hổng bảo mật - cho dù đó là chủ sở hữu ứng dụng, nhà nghiên cứu, hay một bên thứ ba hoạt động như nhà môi giới - MITRE đều tiếp nhận yêu cầu để cấp mã CVE mới.

Khi MITRE gán mã nhận diện (giống như số chứng minh thư cho lỗ hổng), giới bảo mật, nhà cung cấp và doanh nghiệp có được cách thức để nhận diện, thảo luận và chia sẻ chi tiết về lỗ hổng này để tìm cách khắc phục. Trong trường hợp việc tiết lộ ban đầu không xuất phát từ nhà cung cấp, chẳng hạn như lỗ hổng Java object serialization, những kẻ tấn công sẽ có được khởi đầu sớm hơn trong khi các nhà bảo mật vẫn còn chờ đợi mã CVE được cấp.

Khác biệt thời gian này là rất quan trọng. Tất nhiên, khi có quá nhiều lỗ hổng để nghiên cứu, đánh giá và khắc phục, mà chỉ có nguồn lực bảo mật hữu hạn để chống lại, việc sàng lọc các báo cáo lỗ hổng dựa vào việc đã có mã CVE hay chưa là "thái độ thận trọng hợp lý" của các tổ chức, theo Nicko van someren, CTO của Linux Foundation. Hàm ý là một khi lỗi có mã CVE thì nó mới là vấn đề thực sự và cần được quan tâm.

Nhưng gần đây, bản thân hệ thống CVE đã trở thành một nút thắt cổ chai. Nhiều chuyên gia bảo mật phàn nàn không được MITRE cấp mã CVE cho các lỗ hổng một cách kịp thời. Sự chậm trễ này gây khó khăn cho việc phối hợp sửa lỗi giữa các hãng phần mềm với các đối tác và các nhà nghiên cứu khác, vì không có một hệ thống đảm bảo tất cả mọi người đề cập đến cùng một vấn đề. Một phần của vấn đề hiện nay đó quy mô của ngành công nghiệp phần mềm lớn hơn so với thập kỷ trước, và các lỗ hổng được tìm thấy cũng nhiều hơn. Như phân tích của Recorded Future cho thấy, sự chậm trễ trong việc cấp mã CVE cho tin tặc thời gian để phát triển và tinh chỉnh các công cụ và kỹ thuật tấn công.

"Có rất nhiều người nghĩ rằng nếu không có mã CVE thì đó không phải là vấn đề thực sự, và đây chính là vấn đề lớn", Jake Kouns, Giám đốc bảo mật của hãng Risk Based Security nói.

Một vấn đề khác đó là không phải tất cả lỗ hổng đều được cấp mã CVE, chẳng hạn như các ứng dụng web được cập nhật tại máy chủ và không cần có sự tương tác của người dùng. Thật không may, các lỗ hổng ứng dụng di động đòi hỏi có sự tương tác của người dùng để cài đặt bản cập nhật cũng không được cấp mã CVE. Có 14.185 lỗ hổng được báo cáo trong năm 2015, nhiều hơn 6.000 so với số lỗ hổng trong cơ sở dữ liệu lỗ hổng CVE, theo báo cáo 2015 VulnDB của Risk Based Security.

"Giá trị thực sự của hệ thống CVE đối với người dùng và các chuyên gia bảo mật không thực sự ở việc đánh giá tác động rủi ro và bảo mật, mà ở việc phân loại tất cả các nguy cơ đã biết đối với một hệ thống bất kể mức độ nghiêm trọng", theo Kymberlee Price, Giám đốc cấp cao bộ phận nghiên cứu tại BugCrowd.

Đến lúc cần lắng nghe

Vì CVE không bao quát hết mọi lỗ hổng, nên bạn cần xem xét thêm các nguồn khác để có bức tranh hoàn chỉnh về các mối đe doạ sắp đến. Điều này có nghĩa hoạt động quản lý lỗ hổng của bạn không nên chỉ lệ thuộc các thông báo của nhà cung cấp mà nên khai thác thêm các nguồn khác để cập nhật thông tin về những lỗ hổng mới nhất. Đội ngũ bảo mật sẽ hiệu quả hơn nếu biết dò tìm các thảo luận liên quan trên web và các dấu hiệu của hoạt động khai thác trong môi trường của mình.

Có rất nhiều thông tin lỗ hổng được công bố ngoài các thông báo chính thức của nhà cung cấp, nhiều đến nỗi các nhà bảo mật không mong gì cập nhật được hết tất cả các bài đăng trên blog tiết lộ đủ loại lỗ hổng, các thảo luận qua email giữa các nhà nghiên cứu về một lỗ hổng bảo mật cụ thể, và các thông báo công khai khác. Thay vì cố gắng đăng ký mọi danh sách gửi thư và các nguồn RSS, đội ngũ quản lý lỗ hổng có thể trực tiếp vào các diễn đàn và nghe xem những kẻ tấn công tiềm năng đang nói gì. Đó là dạng cảnh báo trước tốt nhất.

"Nếu chịu trách nhiệm quản lý lỗ hổng trong tổ chức, tôi sẽ chú ý đến các cuộc trao đổi trên diễn đàn, tìm kiếm luồng đề cập đáng kể đến các lỗ hổng cụ thể", Gundert nói. "Bạn sẽ không chặn được lỗ hổng ngày zero (zero-day), nhưng sẽ phát hiện các lỗi mà nếu không bạn sẽ phải chờ vài tuần để nhận được hướng dẫn từ nhà cung cấp".

Là công ty phân tích các mối đe dọa, Recorded Future muốn doanh nghiệp sử dụng nền tảng của mình để lắng nghe các diễn đàn trao đổi về mối đe dọa với đủ thứ tiếng, nhưng cũng có những lựa chọn khác. Doanh nghiệp có thể chọn lọc một số diễn đàn, các kênh ‘chat’, và các nguồn trực tuyến khác để giám sát các cuộc thảo luận. Ví dụ, theo dõi những gì được chia sẻ trên GitHub cũng có thể sớm phát hiện kế hoạch tấn công. Thực ra, các nhà phân tích của Recorded Future nhận thấy người dùng luôn chia sẻ bài viết của các cá nhân có vẻ như được công nhận là nguồn thông tin tin cậy. Đơn giản chỉ cần theo dõi những gì các "chuyên gia" đó nói cũng có thể phát hiện các lỗ hổng mới nhất chủ đề của các cuộc thảo luận'.

Phân tích mối đe dọa giúp giảm tỷ lệ nhiễu và phát hiện thông tin hữu ích, nhưng đó không phải là lý do duy nhất để săn lùng các cuộc thảo luận.

Các nhà bảo mật cần giám sát hoạt động dò quét gia tăng đối với hệ thống mạng của mình. Sự gia tăng cho thấy khả năng có những cuộc thảo luận về cách thức kích hoạt lỗ hổng. Ví dụ, Recorded Future nhận thấy việc dò quét tấn công hệ thống thực thi mã lệnh kịch bản Groovy trong Elasticsearch bắt đầu "gần như ngay lập tức" sau khi lỗ hổng thực thi mã lệnh từ xa được tiết lộ. Các diễn đàn liên tục thảo luận về các cách tấn công.

Các lỗ hổng thực thi mã lệnh từ xa thường kích hoạt thảo luận trên mạng gần như ngay lập tức. Các lỗ hổng tại chỗ thường đòi hỏi kẻ tấn công bằng cách nào đó phải có được một chỗ đứng vững chắc trên thiết bị trước, dường như ít được thảo luận. 

Theo PCWorldVN