Phát hiện tấn công web thành công, không chỉ là lần thử

Cơn lũ "lần thử"

Web application firewall hay hệ thống phát hiện xâm nhập được xây để nhận ra mẫu tấn công trong request: payload injection trong tham số, đường dẫn leo ra khỏi thư mục web, file upload có đuôi script. Chúng làm việc đó rất tốt. Vấn đề là nhận ra mẫu trong request chỉ cho biết ý định của bên gửi, chứ không cho biết kết quả trên máy chủ.

Dịch vụ hướng Internet luôn nhận một nền quét tự động liên tục. Scanner lỗ hổng, botnet, nhà nghiên cứu và đơn vị kiểm thử được phép đều gửi những request trông như tấn công. Mỗi request có thể sinh một alert. Một SOC coi từng alert đó là sự cố tiềm năng sẽ nhanh chóng quen bỏ qua cả nhóm alert này, và chính thói quen ấy là thứ kẻ xâm nhập thật được lợi.

Nhiều đội phản ứng bằng cách nâng ngưỡng: chỉ báo khi tốc độ request cao, chỉ với vài signature, chỉ trên một mức nghiêm trọng. Cách đó giảm số lượng, nhưng cũng khiến phát hiện nghiêng về kẻ tấn công ồn ào và nhanh. Kẻ tấn công kiên nhẫn rải vài request cẩn thận trong nhiều giờ, hoặc thành công ngay lần đầu, sẽ lọt qua rule theo tốc độ mà không bao giờ chạm ngưỡng.

Đổi câu hỏi: nó có hiệu quả không?

Bước chuyển hữu ích là thôi hỏi "đây có phải tấn công không?" và bắt đầu hỏi "có bằng chứng nào cho thấy cuộc tấn công này đã đạt được gì không?". Một lần thử rẻ với kẻ tấn công và thường vô hại. Một lần thành công, dù chỉ một, mới là nơi sự cố thật bắt đầu: web shell trả lời lệnh, file cấu hình chứa thông tin đăng nhập thật sự bị trả về, câu truy vấn làm lộ dữ liệu.

Trả lời câu hỏi đó cần dữ liệu khác với thứ alert WAF mang theo. Cần biết máy chủ đã phản hồi ra sao, cùng nguồn đó làm gì tiếp theo, và chuyện gì xảy ra trên host phía sau ứng dụng. Các dữ kiện này thường nằm ở nơi khác: access log của web server, log ứng dụng, telemetry endpoint và bản ghi mạng. Gom chúng lại quanh một request, một client và một máy chủ là phần lớn công việc.

Một HTTP 200 đơn thuần không chứng minh thành công. Nhiều ứng dụng trả 200 kèm trang lỗi cho mọi request. Ngược lại, một request bị chặn chưa chắc là hết chuyện, vì cùng kẻ tấn công có thể đã chạm tới origin bằng đường khác. Thành công là một nhận định dựng từ nhiều dữ kiện, và không bao giờ nên khẳng định vượt quá điều bằng chứng cho thấy.

Bằng chứng thành công thường nằm ở đâu

Không đi vào rule cụ thể, đây là các nhóm bằng chứng mà người phòng thủ và đội ứng cứu sự cố vẫn dựa vào:

• Phản hồi: câu trả lời cho đường dẫn được yêu cầu trông như nội dung thật thay vì trang lỗi quen thuộc, khi so với cách đường dẫn đó vẫn phản hồi.
• Hành động tiếp theo: cùng client đó, hoặc một client mới, quay lại dùng thứ mà request trước có vẻ đã tạo ra hoặc làm lộ.
• Host: tiến trình web server bắt đầu làm những việc web server không hay làm, như khởi chạy trình thông dịch lệnh hay công cụ dò quét.
• Mạng: tầng web bắt đầu kết nối tới những nơi trước đây chưa từng tới, bên trong hay bên ngoài tổ chức.
• Định danh: thông tin đăng nhập có thể đã bị lộ đột nhiên được dùng từ nơi bất thường.
• Dòng thời gian: một chuỗi lần thử chậm rãi qua nhiều giờ, nhiều ngày kết thúc bằng một thay đổi hành vi, điều rất dễ bỏ sót nếu nhìn từng khung thời gian riêng lẻ.

Những cái bẫy thường gặp

Vài khoảng trống phổ biến khiến thành công khó thấy ngay cả khi dữ liệu có sẵn. Rule phát hiện thường đọc log của thiết bị bảo mật thay vì access log của chính web server, nên kích thước phản hồi và status, thứ có thể để lộ thành công, không bao giờ được xem tới. Query string đôi khi bị cắt khỏi đường dẫn được ghi log, nên rule không nhìn thấy payload. So khớp phân biệt chữ hoa chữ thường, hoặc chỉ theo một kiểu mã hoá, sẽ bỏ sót các biến thể mà máy chủ vẫn vui vẻ chấp nhận.

Đằng sau reverse proxy hay CDN, địa chỉ ứng dụng thấy có thể là proxy chứ không phải client. Đổ lỗi hay chặn proxy sẽ gây gián đoạn dịch vụ trong khi nguồn thật vẫn thong dong. Chỉ nên dùng địa chỉ client được chuyển tiếp khi proxy là nguồn tin cậy, và cần nói rõ khi chưa xác định được tác nhân.

Quét được cho phép cần xử lý cẩn thận. Scanner đã biết giải thích được các lần thử, và việc giảm nhiễu chúng tạo ra là hợp lý. Nhưng chúng không bao giờ giải thích được một lần thành công. Nếu request từ địa chỉ quét cho ra kết quả thật, đó vẫn là điểm phơi nhiễm tổ chức cần khắc phục.

Lạm dụng logic nghiệp vụ là một nhóm riêng. Mở khoá tài khoản hàng loạt, yêu cầu OTP lặp lại hay API quản trị bị gọi từ Internet đều có thể trả mã thành công trong khi thiệt hại nghiệp vụ vô hình với signature. Nhóm này cần ngữ cảnh về cách dùng bình thường, và nên được báo là khả năng lạm dụng thay vì khẳng định đã chứng minh.

Kiểm chứng trên bản ghi gốc

Bất cứ thứ gì kết luận một cuộc tấn công đã thành công đều nên trình bày được cách nó đi đến kết luận. Một phát hiện tốt mang theo chính các truy vấn mà analyst có thể chạy lại trên log gốc, có giới hạn thời gian, để người xác nhận trong vài phút thay vì tin mù quáng. Điều này cũng chặn kiểu lỗi âm thầm: truy vấn lỗi hoặc hết thời gian, và việc không có kết quả bị hiểu nhầm thành không có tấn công.

Cuối cùng, những cuộc tấn công thành công được phát hiện muộn là bài học quý. Mỗi case đã xác nhận cho thấy bằng chứng nào xuất hiện đầu tiên và có thể thấy nó sớm đến đâu. Đưa bài học đó ngược vào phát hiện, dưới dạng cải tiến chung chứ không phải rule viết riêng để bắt một case đã biết, là cách một đội kéo alert đầu tiên lại gần thời điểm bị xâm nhập.

ApexAI tiếp cận thế nào

ApexAI Breach Proof, hiện ở bản preview, được thiết kế quanh câu hỏi về kết quả. Nó gom bằng chứng web, host và mạng cho cùng một client và máy chủ, xếp mỗi phát hiện vào mức lần thử, khả năng cao hoặc đã chứng minh, và kèm truy vấn chỉ đọc để analyst kiểm tra kết luận trên chính log của bạn. Scanner được phép đã biết chỉ được dùng để giải thích lần thử. Phát hiện đi vào ApexAI Autonomous SOC, nơi chúng nhập vào câu chuyện của thực thể bị ảnh hưởng thay vì thành thêm một alert rời rạc.

Câu hỏi thường gặp