Penetration Testing Step 3 – Làm gì khi mục tiêu che chắn các lỗ hổng XXE Injection dễ ăn?

Kết thúc nội dung Penetration Testing Step 3 – Lần đầu làm chuyện ấy với XML External Entity Injection, kỳ này tôi sẽ chuyển sang tình huống khi mà mục tiêu đã nâng cao cảnh giác và tiến hành che chắn các lỗ hổng “lộ thiên” nhằm khai thác XML External Entity Injection (XXE 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. Mò mẫm các attack surface phục vụ XML External Entity Injection

Trong 2 kịch bản đề cập ở kỳ trước, attack surface (tạm dịch là phương án tấn công) cho XXE injection khá rõ ràng vì HTTP traffic bao gồm các request chứa data dạng XML format. Tuy nhiên, đôi khi đời không như mơ, ví dụ với request không chứa XML gì sất, tôi sẽ phải mò mẫm xác định các con đường tà đạo khác để có thể ra đòn tấn công hợp lý.

Trong tình huống này, để tránh lạc lối trong quá trình mò mẫm, tôi có thể cân nhắc các phương án theo thứ tự như sau:

• Kiểm tra khả năng khai thác XXE injection “dễ thấy dễ ăn” như trích xuất file hay thực thi SSRF attack;
• Kiểm tra khả năng khai thác lỗ hổng cho phép dí hàng do user cung cấp (non-XML data) vào XML document của server (ví dụ như kiểu Xinclude attack bên dưới);
• Kiểm tra khả năng khai thác lỗ hổng XXE injection với tính năng file upload hay mông má Content-Type header của Post request (ví dụ đổi application/x-www-form-urlencoded thành text/xml) để đưa data theo XML format vào message body từ đó khai thác thêm các đường “ăn” XXE injection khác;
• Kiểm tra khả năng khai thác Blind XXE vulnerabilities (tôi sẽ giới thiệu chi tiết sau);

#2. Khai thác XXE với XInclude attack nhằm truy xuất file

Một số ứng dụng sau khi nhận dữ liệu client gửi lên server sẽ tiến hành embed (tạm dịch là “nhúng”) vào XML document và sau đó parse (tạm hiểu là phân tích) cái document này. Với kiểu này, tôi sẽ không kiểm soát được hoàn toàn cái XML document nên chả thể nào định nghĩa hay mông má cái DOCTYPE element. Tuy nhiên, tôi vẫn còn một đường binh khác là sử dụng Xinclude.

Lưu ý: Xinclude là một phần của XML specification cho phép dựng XML document từ sub-document. Nhờ vào đối tượng này, tôi có thể mở combat dù chỉ kiểm soát một phần dữ liệu đút vào server-side XML document.

Rồi, tôi đi vào phần demo làm rõ ngay đây.

Trong kịch bản này, tôi sẽ lại truy cập một sản phẩm cụ thể và thử tính năng Check stock của ứng dụng.

Sau đó, tôi kiểm tra Burp Suite Proxy History và hốt cái request tương ứng đẩy qua Burp Suite Repeater.

Kế đến, tôi mông má lại chỗ productId thành kiểu:

<foo xmlns:xi="http://www.w3.org/2001/XInclude"><xi:include parse="text" href="file:///etc/passwd"/></foo>

Và như có thể thấy ở kết quả trên, tôi dễ dàng hốt thông tin từ file /etc/passwd về với cái Xinclude.

Lưu ý:

• xmlns là XML namespace, có thể dùng để khai báo namspace mặc định hoặc các prefix liên quan (ví dụ prefix “xi” – XInlude như trường hợp trên). Bạn có thể xem chi tiết về XML namespace trong nội dung XML namespace – Wikipedia;
• w3.org/2001/XInclude là trang cung cấp thông tin về Xinclude (XML Inclusion) namespace;
• org do ông World Wide Web Consortium (W3C) quản lý. Đây là cộng đồng quốc tế phụ trách việc phát triển các tiêu chuẩn mở hỗ trợ việc phát triển Web nói chung. Bạn có thể bơi vào World Wide Web Consortium (W3C) để xem thêm chi tiết nếu cần;
• xi:include element có thể có nhiều attributes (tạm dịch là thuộc tính). Trong trường hợp ở trên, atributes href cung cấp thông tin về URI/IRI reference để chỉ định vị trí resource (ví dụ file:///etc/passwd) được lấy để kèm vào. Attribute parse dùng để cho biết phương thức phân tích xử lý (ví dụ text hay xml) included resource (nội dung cái etc/passwd ở trên);

#3. Khai thác XXE thông qua file upload

Nếu phương án Xinclude ở trên cũng không khả thi, tôi có thể thử tiếp phương án khác thông qua khả năng upload file với các format sử dụng XML hoặc chứa XML subcomponents như kiểu DOCX hay SVG.

Tôi chuyển sang phần demo để minh họa cho rõ cái ý tưởng nói trên.

Để giở trò bẩn bựa, trước hết tôi cần tạo một file image SVG với nội dung kiểu như sau:

<?xml version="1.0" standalone="yes"?><!DOCTYPE test [ <!ENTITY xxe SYSTEM "file:///etc/hostname" > ]><svg width="128px" height="128px" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1"><text font-size="16" x="0" y="16">&xxe;</text></svg>

Lưu ý: www.w3.org/1999/xlink là XML namespace định nghĩa XML Linking Language (XLink) specification phục vụ việc quản lý các thành phần có thể chèn vào XML document nhằm tạo liên kết giữa các resources . Bạn có thể xem thêm chi tiết ở trang XML Linking Language (XLink) Version 1.1 (w3.org).

Sau đó, tôi mở đại một blog post nào đấy rồi bay vô phần comment để upload cái file đểu vừa mới tạo (thông qua cái Avatar upload).

Sau khi post comment với hàng đểu làm avatar (cái fake.svg), tôi truy cập lại phần comment để thưởng thức thành quả. Tại đây, tôi nhận thấy có gì đó “khang khác” chỗ avatar.

Thử soi kèo cái image chỗ avatar, tôi ngỡ ngàng nhận ra cái server hostname xuất hiện như bên dưới.

Đến đây tôi xin tạm dừng nội dung demo của kỳ này. Kỳ tới tôi sẽ chuyển sang một chiêu thức tương đối phức tạp hơn để khai thác Blind XXE vulnerabilities.