NỘI DUNG
Kết thúc nội dung Penetration Testing Step 3 – Blind SSRF attack với hàng độc out-of-band techniques, tôi xin gác lại câu chuyện về SSRF. Kỳ này tôi sẽ chuyển hướng sang một đối tượng thú vị khác là XML External Entity Injection.
Lưu ý:
- Như mọi khi, tôi cũng sẽ tận dụng các bài Lab dựng sẵn của ông PortSwigger để tiết kiệm thời gian dàn cảnh;
- Thông tin liên quan đến SSRF bạn có thể xem trong nội dung Penetration Testing Step 3 – Nhập môn Server-side request forgery – SSRF;
- Thông tin liên quan đến Burp Suite bạn có thể xem trong nội dung Penetration Testing Step 3 – 6 điều bạn nên biết trước khi xài tool khủng Burp Suite;
- Chi tiết việc sử dụng Burp Suite Repeater bạn có thể xem trong nội dung Penetration Testing Step 3 – Thủ thuật chọc ngoáy HTTP/WebSockets message với Burp Suite Repeater;
#1. XML External Entity Injection có gì hot?
XML External Entity Injection – XXE là dạng lỗ hổng bảo mật của ứng dụng web cho phép attacker can thiệp vào quá trình ứng dụng xử lý XML data (thường sẽ cho phép xem các file của server filesystem và tương tác với các hệ thống backend hoặc external mà ứng dụng có thể truy cập).
Khi giao lưu phối hợp với Server-side Request Forgery – SSRF, XXE attack cũng có thể leo thang để xâm hại cả hạ tầng bên dưới (bao gồm chính server và các hệ thống liên kết).
Để có thể tiêu hóa cái ý tưởng nói trên, tôi sẽ lần lượt demo minh họa làm rõ. Tuy nhiên, trước mắt, tôi cần tóm lược một số ý liên quan bao gồm:
- XML format thường được ứng dụng sử dụng (thông qua library/API) để vận chuyển data qua lại giữa browser và server. Và khi XML specifications tồn tại các tính năng tiềm ẩn nguy cơ bảo mật nhưng cái parser (tạm hiểu là đối tượng tiếp nhận và xử lý thông tin cho các bước tiếp theo) vẫn hỗ trợ, lỗ hổng XXE sẽ xuất hiệnl
- Về cơ bản, XML external entities là một dạng XML entity cho phép tùy chỉnh với các giá trị được xác định bên ngoài Document Type Definition – DTDl
- XML document type definition – DTD bao gồm các declarations (tạm dịch là khai báo) định nghĩa cấu trúc của XML document, loại giá trị dữ liệu có thể chứa,…DTD được khai báo với DOCTYPE element (cái này là tùy chọn chứ không bắt buộc) ở phần đầu của XML document và có thể ở dạng:
- Internal DTD: Tất cả gói gọn trong cái document;
- External DTD: Nhận thông tin từ đám ất ở nào bên ngoài;
- Kết hợp nửa nạc nửa mỡ của 2 loại trên.
Ví dụ đơn giản về việc sử dụng XXE để truy cập dữ liệu nhạy cảm từ hệ thống được minh họa như sau.

Nguồn: portswigger.net
Quay trở lại vấn đề chính, với XXE attack, tôi sẽ có thể gặp các dạng phổ biến sau:
- Khai thác XXE để trích xuất file: Định nghĩa external entity chứa nội dung của 1 file và trả về trong response;
- Khai thác XXE để thực thi SSRF attacks: Định nghĩa external entity dựa vào URL đến back-end system;
- Khai thác blind XXE để hốt dữ liệu theo kiểu out-of-band: Truyền tải dữ liệu nhạy cảm từ server đến hệ thống mà attacker có thể kiểm soát;
- Khai thác blind XXE để trích xuất dữ liệu thông qua thông báo lỗi: Làm phát sinh parsing error message chứa thông tin nhạy cảm.
Lưu ý: Các chiêu nói trên còn có thêm các biến thể nên tôi sẽ cần tách ra minh họa trong nhiều kỳ.
#2. Chiêu thức 1 – Khai thác XXE nhằm trích xuất file
Để triển XXE injection attack nhằm trích xuất file tùy ý từ server filesystem, tôi sẽ cần hiệu chỉnh XML theo kiểu:
- Bổ sung (hoặc chỉnh sửa) DOCTYPE element định nghĩa external entity chứa đường dẫn đến file;
- Hoặc chỉnh sửa data value trong XML (có thể được trả về trong response) để tận dụng cái external entity đã định nghĩa.
Lưu ý: Thực tế, với XXE vulnerabilities, cái XML sẽ chứa cả tấn data values. Và đâu đó trong cá núi data values này, sẽ có một (hoặc một số thằng) có thể được trả về trong response. Với nguyên lý giết nhầm còn hơn bỏ sót, tôi sẽ phải mâm mê, thử nghiệm từng thằng để xác định coi thằng nào sẽ xuất hiện trong response.
Rồi, không chém gió nữa. Tôi vào phần demo đây. Đầu tiên, tôi truy cập thử vào chức năng Check stock của ứng dụng.

Với Intercept is on (của phần Burp Suute Proxy), tôi túm cái request tương ứng coi thử.

Ở đây tôi có thể mông má trực tiếp cái request này (hoặc đẩy qua Burp Suite Repeater) để chèn vào external entity nằm giữa cái XML declaration và stockCheck element kiểu như sau:
<!DOCTYPE test [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>
Sau đó, tôi thay cái productId với phần reference (tham chiếu) đến external entity (&xxe).

Như có thể thấy ở trên, lúc này response trả về chứa đựng nội dung file /etc/passwd như ý đồ đen tối của tôi.
#3. Chiêu thức 2 – Khai thác XXE để triển SSRF attack
Chuyển sang kịch bản tôi tận dụng XXE để làm bàn đạp triển SSRF attack. Để có một sự vụ khai thác thành công, tôi sẽ cần định nghĩa external entity với URL mà tôi định tấn công. Sau đó tôi sẽ đưa cái entity đã định nghĩa này vào một data value có thể trả về trong response từ đó mở đường cho tương tác 2 chiều với backend system (nếu không được thì tôi sẽ chuyển qua chiêu Blind SSRF).
Với nguyên lý nói trên, tôi lại cắm đầu vào phần demo. Tương tự như kịch bản trước đó, tôi cũng ghé thăm cái Check stock function và hốt cái request tương ứng thảy qua Burp Suite Repeater.

Kế đến, tôi chuẩn bị cái external entity để chèn vào giữa phần XML declaration và stockCheck element.
<!DOCTYPE test [ <!ENTITY xxe SYSTEM "http://169.254.169.254/"> ]>
Sau đó tôi đổi cái productId sang phần reference đến external entity (&xxe).

Lưu ý: Cái IP trong chỗ external entity là để demo cho nhanh. Thực tế bạn sẽ phải bỏ công ra thu thập, phân tích và xác định.
Lúc này, ngay sau thông tin “Invalid product ID”, tôi đọc được metadata của cái endpoint đã đưa vào (folder name “latest” trong trường hợp này). Với thông tin này, tôi cập nhật lại cái URL trong DTD để dò cái thông tin tiếp theo (“meta-data” như bên dưới).

Tua nhanh qua đoạn xử lý cơ bắp này, tôi xác định được URL trùm cuối (/latest/meta-data/iam/security-credentials/admin) và cập nhật lại như sau.

Và lúc này, cả đám thông tin thú vị (nhất là cái SecretAccessKey) phọt vào khuôn mặt đang hả hê của tôi.
1 thought on “Penetration Testing Step 3 – Lần đầu làm chuyện ấy với XML External Entity Injection”