Người thực hiện: Sonvh (Pentester)
Mở đầu
Tháng 10/2024, trong quá trình kiểm thử bảo mật cho một khách hàng, tôi bắt gặp một tính năng tưởng như rất bình thường: tải lên tệp PDF. Ban đầu, đây chỉ là một chức năng cho phép người dùng upload tài liệu. Tuy nhiên, sau khi phân tích cách hệ thống xử lý các tệp này, tôi nhận ra nó có thể trở thành điểm khởi đầu cho một cuộc tấn công nghiêm trọng. Điều thú vị là hệ thống đã được bảo vệ bởi nhiều lớp phòng thủ, bao gồm cả Cloudflare WAF. Vì vậy, thử thách không chỉ là tìm ra lỗ hổng mà còn phải tìm cách vượt qua cơ chế bảo vệ đó.
Hệ thống được bảo vệ như thế nào?
Khách hàng đã triển khai khá đầy đủ các giải pháp bảo mật:
- Cloudflare WAF để lọc các yêu cầu độc hại.
- Hệ thống phát hiện bot trên cả môi trường thử nghiệm (staging) và môi trường thực tế (production).
- DNS được cấu hình chặt chẽ.
- Một số khu vực còn được bảo vệ bằng Basic Authentication.
Nhìn tổng thể, đây là một hệ thống không hề dễ khai thác. Tuy nhiên, tính năng upload PDF vẫn khiến tôi chú ý. Dù chỉ người dùng thông thường mới có thể sử dụng, đây vẫn là một điểm cảnh báo mà chúng ta cần kiểm tra.
Điều gì xảy ra sau khi upload PDF?
Tôi bắt đầu theo dõi quá trình xử lý của tệp sau khi được tải lên. Kết quả cho thấy hệ thống không hiển thị PDF trực tiếp mà sử dụng Google Docs Viewer (gview) để render nội dung. Trong một số trường hợp, nếu tệp PDF không được kiểm tra và làm sạch đúng cách trước khi hiển thị, kẻ tấn công có thể chèn các đoạn mã độc vào tệp. Khi người khác mở tài liệu, đoạn mã này có thể được thực thi ngay trên trình duyệt của họ. Nói cách khác, một tệp PDF tưởng như vô hại vẫn có thể trở thành phương tiện thực hiện tấn công XSS.
Thử nghiệm đầu tiên
Để kiểm chứng giả thuyết, tôi tạo một tệp PDF bình thường rồi chỉnh sửa nội dung bên trong để chèn payload kiểm thử. Trên môi trường staging, kết quả diễn ra đúng như mong đợi. Payload vẫn hoạt động bình thường. Điều này càng khiến tôi chắc chắn một điều rằng giả thuyết của tôi là chính xác: hệ thống thực sự có thể bị khai thác thông qua tệp PDF.
Tuy nhiên, khi thực hiện lại trên môi trường production, mọi chuyện lại khác. Tệp vừa upload lập tức biến mất và không có thông báo lỗi, không có phản hồi nào từ hệ thống. Điều này cho thấy Cloudflare WAF đã phát hiện và chặn payload trước khi nó đến được ứng dụng.
Cuộc chiến với Cloudflare WAF
Lúc này, vấn đề không còn là tìm lỗ hổng nữa. Làm thế nào để payload có thể đi qua Cloudflare mới là thử thách thực sự. Thông thường, WAF sẽ nhận diện những mẫu payload phổ biến và chặn ngay khi phát hiện dấu hiệu tấn công. Vì vậy, thay vì sử dụng các payload quen thuộc, tôi bắt đầu tạo ra nhiều biến thể khác nhau. Sau mỗi lần thử, tôi đều ghi lại phản hồi của hệ thống:
- Payload nào bị chặn?
- Payload nào được phép đi qua?
- Độ dài của payload có ảnh hưởng gì không?
- Có ký tự hoặc mẫu dữ liệu nào khiến WAF phản ứng mạnh hơn?
Vậy nếu lỗ hổng không được khắc phục thì sao? Khi đã có thể thực thi JavaScript trên trình duyệt của người dùng, kẻ tấn công có thể tiếp tục thực hiện nhiều hành vi nguy hiểm hơn như:
- Đánh cắp cookie hoặc phiên đăng nhập.
- Giả mạo thao tác của người dùng.
- Truy cập các chức năng hoặc API mà người dùng có quyền sử dụng.
- Kết hợp với các lỗ hổng khác để mở rộng phạm vi tấn công.
May mắn là lỗ hổng đã được báo cáo ngay sau khi được xác nhận. Từ đó tôi phối hợp cùng khách hàng gửi thông tin tới Cloudflare để hỗ trợ quá trình điều tra và khắc phục.
Bài học rút ra
Nhiều người cho rằng chỉ cần triển khai WAF là hệ thống đã an toàn. Thực tế không hoàn toàn như vậy. WAF là một lớp bảo vệ rất hiệu quả, nhưng nó không thể thay thế việc xây dựng ứng dụng an toàn ngay từ đầu. Nếu ứng dụng vẫn còn tồn tại các điểm yếu trong cách xử lý dữ liệu đầu vào, kẻ tấn công vẫn có thể tìm ra những phương pháp mới để vượt qua các lớp phòng thủ. Bảo mật không đến từ một công cụ duy nhất, mà là sự kết hợp giữa thiết kế hệ thống an toàn, quy trình phát triển bảo mật và việc kiểm thử thường xuyên. Và đôi khi, một tệp PDF tưởng như vô hại lại chính là nơi bắt đầu của cả một chuỗi khai thác phức tạp.
