Threat Intelligence, xu hướng mới?
Chẳng là đợt gần đây mới tham dự hội thảo online với chủ đề “Nâng cao năng lực đảm bảo an toàn thông tin qua hợp tác, chia sẻ tri thức tấn công mạng” thôi thì cũng ngứa nghề ( là một người cũng đã từng dấn thân vào các hoạt động “tình báo” này ) nên ngồi tản mạn một chút về việc này, giới mộ điệu hay gọi là Threat Intelligence.
À thì bài viết cũng seeder một tí nên đọc vui vẻ thôi nhé 👉👈
Trước tiên là Threat Intelligence là gì? Với góc nhìn đơn giản của tôi thì gói gọn trong việc phân tích, chia sẻ, cảnh báo và phối hợp xử lý các nguy cơ ảnh hưởng đến ATTT của tổ chức ( Confidentiality, Integrity, Availability ). Sâu hơn một chút là lộ lọt thông tin, lỗ hổng bị khai thác, tấn công có tổ chức vào mạng lưới, chiếm đoạt tài sản qua hình thức online,… Đối với nhiều người việc này giống “đọc báo” hằng ngày, subscriber một số kênh telegram, xem dăm ba blog là có thông tin. Nhưng điểm khác biệt nằm ở khả năng phân tích, chắt lọc nắm bắt kịp thời và đúng đắn luồng thông tin cũng như từ đó mở rộng điều tra, hạn chế nhiễu loạn, nếu đã dễ dàng người ta đã không có khái niệm gọi là “tình báo thông tin”. Vậy tại sao đến giờ Threat Intelligence mới nhen nhóm được quan tâm và rất ít tổ chức đáp ứng được dịch vụ? Đầu tiên hãy đi vào vài case thực tế mà VNPT CTIP (VNPT Cyber Threat Intelligence Platform) mới tiếp xúc gần đây.
- Lỗ hổng thực thi mã từ xa không cần xác thực trên sản phẩm F5 BIG-IP: CVE-2022-1388
- 1.1. Thông tin cơ bản về lỗ hổng
Cơ bản đây là một lỗ hổng mà tin tặc không cần xác thực có thể gửi request độc hại tới hệ thống BIG-IP ( miễn là hệ thống BIG-IP đó tin tặc có thể tiếp cận đến ) để bỏ qua xác thực iControl REST, từ đó thực thi mã từ xa, chiếm quyền điều khiển hệ thống. Đây là một lỗ hổng rất nghiêm trọng do sản phẩm này được sử dụng rất rộng rãi trên thế giới nói chung và đặc biệt ở Việt Nam nói riêng.
Lỗ hổng nằm ở cơ chế xác thực BIG-IP khi tương tác giữa 2 máy chủ Apache và Jetty đứng sau nó để hoàn thành cơ chế này.
Lỗ hổng ảnh hướng tới các hệ thống BIG-IP sử dụng các phiên bản sau: 16.1.0 -> 16.1.2, 15.1.0 -> 15.1.5, 14.1.0 -> 14.1.4, 14.1.0 -> 14.1.4, 12.1.0 -> 12.1.6, 11.6.1 -> 11.6.5
- 1.2. Chuyện gì xảy ra với CVE này
Đối với những người làm bảo mật hay các quản trị viên của doanh nghiệp thường sẽ là đọc bài hoặc tìm kiếm các thông tin liên quan về lỗ hổng sau đó sẽ áp dụng bản vá hay khắc phục tạm thời – đó là mô tuýp trên lý thuyết. Còn với thực tế việc triển khai bản vá hay khắc phục hệ thống tạm thời này bị ảnh hưởng bởi rất nhiều yếu tố như tầm ảnh hưởng tới dịch vụ nếu tạm thời dừng để update, khi áp dụng bản vá liệu hệ thống có làm sao không, quy trình test-backup trước khi áp dụng,… chưa kể nếu lỗ hổng ở thời điểm đó là dạng Advisory mà chẳng có thông tin gì hơn về nó cả thì việc update, fix lỗi hay đề phòng sẽ càng bị buông lỏng.
Ngày 5/5 mới chỉ có cách detect F5 Icontros RestAPI có tổn tại hay không chứ chưa có poc hay ghi nhận tấn công
Biểu đồ ghi nhận trend trên twitter cũng thể hiện tương tự với sự quan tâm của người dùng.
Biểu đồ ghi nhận trend trên twitter (source trust ) cũng thể hiện tương tự với sự quan tâm của người dùng.
Thêm vào đó với nhiều tổ chức việc có đội ngũ luôn sát sao theo dõi các lỗ hổng nghiêm trọng đó để đánh giá, phân tích nghiên cứu kỹ lưỡng là điều cực kỳ khó khăn. Trong khi cộng đồng hacker thì nhiều còn hơn sao trên trời luôn nhăm nhe “xiên thử” hệ thống mà họ scan hằng ngày.
Theo ghi nhận từ hệ thống giám sát và một số nguồn tin thì nhiều hệ thống máy chủ đã bị tấn công và khai thác thành công từ ngày 07-08/05/2022.
Trong khi đến ngày 08-09/05 mới có PoC công khai trên không gian mạng và đến ngày 14 mới kịp phản ứng sau khi điều tra và phát hiện tồn tại webshell.
Ngày 7/5 mới nhen nhóm xuất hiện PoC
Rất nhiều event scan ngay khi PoC được public đã được hệ thống giám sát ghi nhận sau khi tiếp nhận thông tin từ CTIP từ cùng một IP. Kèm theo đó CTIP cũng khuyến nghị nếu hệ thống có sử dụng BIG-IP F5 có thể kiểm tra một số nguồn log trên máy chủ theo đường dẫn:
-
- /var/log/audit
- /var/log/restjavad-audit.0.log
( Điều này cho thấy việc theo dõi liên tục, cảnh báo sớm là cực kỳ cần thiết. Hệ thống CTIP đã cảnh báo và đưa ra workaround chi tiết khi có hiện tượng rà quét hệ thống vào ngày 06/05 và cập nhật thông tin ngay khi có sự xuất hiện của PoC )
- Lỗ hổng nghiêm trọng thực thi mã từ xa không cần xác thực CVE-2022-29464 trên WSO2
2.1. Các thông tin cơ bản về lỗ hổng
Nguy cơ dẫn tới thực thi mã từ xa là việc kết hợp lỗi xác thực và lỗi Path Traversal. Do hệ thống core của WSO2 không có xác thực và thiếu các điều kiện kiểm tra đầu vào triệt để được định nghĩa ở một số lớp và thư viện.
Đây là lỗ hổng thực thi mã từ xa không cần xác thực có thể tấn công các hệ thống sử dụng các sản phẩm:
-
- WSO2 API Manager >= 2.2.0
- WSO2 Identity Server >= 5.2.0
- WSO2 Identity Server Analytics 5.4.0,5.4.1, 5.5.0, 5.6.0
- WSO2 Identity Server as Key Manager >= 5.3
- WSO2 Enterprise Integrator >= 6.2.0
Đây là dòng sản phẩm được dùng rất nhiều ở khối GOV
- 2.2 UseCase thực tế
Ngay sau khi tiếp nhận thông tin CTIP đã ngay lập tức phân tích bản vá của WSO2 trong advisory được hãng công bố từ đó dựng lại lab, pentest, tạo rule và cảnh báo khách hàng.
Đến ngày 20 khi đã xác nhận được PoC và test thành công sau khi phối hợp xử lý cùng các chuyên gia bảo mật khác trong mạng lưới.
Ngay lập tức CTIP đã ghi nhận nhiều request tới khách hàng với mục đích khai thác lỗ hổng.
Theo thông tin nhận được từ nhiều nguồn khối GOV ở một số tỉnh thành cũng đã bị tấn công trong ngày và ngay lập tức phải dừng hoạt động nhằm sửa lỗi và rà soát webshell.
Đặc biệt trong bối cảnh rất nhiều website GOV bị khai thác từ trước đến nay nhằm các mục đích xấu.
- Lột lọt thông tin
Đây là một vấn đề không mới và đặc biệt nhiều người còn rất ít quan tâm hay để ý với suy nghĩ “ôi nick t có gì đâu, cho n lấy cũng được”… Chính vì vậy mà gần đây có một tổ chức an toàn thông tin ở nước ngoài đã có một bài viết rất chuyên sâu về việc tình cờ phát hiện ra cơ số traffic ddos website khách hàng của họ lại đến từ các account FB Việt Nam ( thông tin tại đây https://www.qurium.org/alerts/the-tip-of-the-iceberg/ ).
Đó là trên mạng xã hội còn ở khía cạnh doanh nghiệp thì việc account liên quan tới công việc bị lộ lọt gây ảnh hưởng rất lớn đến chính công việc và cuộc sống của mình.
Những account này bị lộ lọt do có thể máy tính đã chứa mã độc đánh cắp thông tin ( tiêu biểu là dòng RedLine ), lộ lọt trong khi upload sourcecode,…. Vấn đề là làm sao để các tổ chức có thể tiếp cận những nguồn thông tin này một cách nhanh nhất hiệu quả nhất và có phương án xử lý đúng đắn kịp thời để giảm thiểu thiệt hại, rủi ro tối đa.
Chính những Threat Hunter, sử dụng nghiệp vụ Threat Hunting để tìm kiếm rủi ro và cảnh báo điều đó
Kết
Bài viết đã dài và lại còn non-tech nên việc “kể chuyện” thêm nhiều Usecase nữa cũng không còn thú vị. Tổng kết lại việc xuất hiện giải pháp Threat Intelligence trong mỗi tổ chức là việc cần thiết nhưng khá khó để hình thành, cũng như để hoàn thiện giải pháp này cần rất nhiều yếu tố, trước tiên yếu tố nguồn lực và sự chuyên nghiệp.
Không phải cứ có CVE rồi lên github tìm là ra PoC…
Tiếp đó là độ phủ và nhanh nhạy thật sự của thông tin trong hằng hà sa số nguồn dữ liệu “vàng thì ít mà rác thì nhiều” ( các tổ chức cạnh tranh nắm nhiều luồng dữ liệu cũng không nhiều như các dịch vụ khác và hiện tại tiêu biểu nhất là Viettel Threat Intelligence, VCI-Cyber Threat Intelligence Platform hay GroupIB Threat Intelligence ). Cuối cùng vẫn là bài toán hợp tác, chia sẻ luồng thông tin tại Việt Nam khá khó khăn với tư duy “giấu bài” vẫn còn. Ngay cả trong nhiều tổ chức sự liên kết với các phòng ban khác còn vẫn đang “việc ông ông làm việc tôi tôi làm” chứ không nói tới giữa các công ty tổ chức lớn với nhau ( of course khi mà chính trong giới còn thi thoảng còn có những màn cà khịa rất chi sôi nổi mà ¯\_(ツ)_/¯ ).