Penetration Testing Step 3 – Nhập môn Server-side request forgery – SSRF

Kết thúc nội dung Penetration Testing Step 3 – Khai thác file upload vulnerabilities (Hiệp cuối), tôi xin tạm gác lại câu chuyện về File Upload Vulnerability. Trong kỳ này, tôi sẽ chuyển sang một chủ đề mới trong công cuộc Penetration Testing là Server-side request forgery – SSRF.

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 Burp Suite bạn có thể xem 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;
• Chi tiết việc sử dụng Burp Suite Intruder bạn có thể xem trong nội dung Penetration Testing Step 3 – Chuẩn bị đổ mưa bom, bão đạn lên mục tiêu với Burp Suite Intruder;

#1. Server-side request forgery – SSRF lợi hại đến đâu?

SSRF là dạng lỗ hổng cho phép attacker dụ dỗ server-side application “vô tình” thực hiện request nằm ngoài chủ đích. Việc này có thể dẫn đến server thực hiện kết nối đến khu vực chạy các chức năng nội bộ của hệ thống, đến các hệ thống khác có liên kết với server hoặc kết nối đến hệ thống bên ngoài. Và các hoạt động này có thể gây ra một số dạng hậu quả phổ biến như:

• Rò rỉ dữ liệu nhạy cảm khi kết nối đến hệ thống bên ngoài;
• Thực thi các hoạt động nằm ngoài thẩm quyền cho phép hoặc truy cập trái phép vào dữ liệu của mục tiêu (hoặc các hệ thống có kết nối với mục tiêu);
• Kích hoạt khả năng thực thi command bất kỳ.

Nguồn: portswigger.net

Như nói trên, SSRF attack sẽ có thể rơi vào các tình huống như sau:

• Tấn công vào chính server chứa ứng dụng;
• Tấn công vào các hệ thống có kết nối với server.

Tôi sẽ lần lượt demo làm rõ các kịch bản này với cả hai trường hợp khi mục tiêu có và không có triển khai giải pháp để đối phó SSRF attack.

#2. SSRF attack vào chính server chứa ứng dụng

Với dạng này, attacker sẽ dụ dỗ ứng dụng thực hiện HTTP request về server mà ứng dụng đang lưu trú (ví dụ thông qua loopback network interface với hostname kiểu 127.0.0.1 hoặc localhost).

Lúc này (tất nhiên kèm theo một số điều kiện khác mà tôi sẽ giới thiệu ở phần demo ngay bên dưới), request đến các vị trí quan trọng như /admin sẽ ghi nhận đến từ local machine do vậy nguyên đám giải pháp access control chỉ đứng trố mắt ra dòm mà không làm gì sất. Và với khả năng truy cập administrative functionality không bị kiểm soát, attacker sẽ tha hồ tung tóe mà không sợ bố con thằng nào.

Lưu ý: Bạn có thể xem thêm về Access control trong nội dung Penetration Testing Step 3 – Authorization và những ngả đường của vertical privilege escalation.

Rồi, để tôi triển ngay cái demo khai vị cho dễ hình dung. Đầu tiên tôi truy cập vào ứng dụng (trong trường hợp này là một shop bán hàng) và chọn xem chi tiết một sản phẩm. Kế đến, tôi chạy thử cái chức năng Check stock.

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

Lúc này, bên phía Repeater, tôi lấy cái URL trong stockApi mang đi URL-decode để nhìn cho dễ.

Sau khi đã nắm rõ cái cấu trúc URL chỗ stockApi, tôi thử chỉnh sửa lại thành http://localhost/admin và chạy request.

Cái đệt, làm chơi ai dè ăn thật! Soi cái resposne, tôi ghi nhận sự xuất hiện của href delete user vốn dĩ chỉ tồn tại trên administration interface.

Vào đến đây mà không táy máy tay chân là có lỗi với đồng bào, tôi thử chỉnh lại để xóa account của ông Carlos với cái URL xác định ở trên (http://localhost/admin/delete?username=carlos) rồi send request.

Hết sức nhẹ nhàng, tôi nhận về cái status code 302 báo hiệu cho biết đã triệt hạ thành công account của Carlos.

#3. SSRF attack vào các hệ thống backend có liên kết với server chứa ứng dụng

Trong kịch bản này, phương án bảo vệ sẽ dựa vào việc che đậy thông tin về kiến trúc hệ thống, hạn chế người dùng truy cập trực tiếp và chỉ cho application server tương tác với các hệ thống backend có kết nối. Do đó, đám backend sẽ có niềm tin mù quáng là các request đến từ application server đều chuẩn cmn mực nên không cần kiểm tra xác nhận làm gì.

Và đó chính là những gì tôi cần để có một sự vụ đâm thọc thành công. Tương tự như trên, tôi cũng truy cập một sản phẩm cụ thể của cái shop bán hàng sau đó soi kèo cái chức năng Check stock.

Kiểm tra bên phía Burp Suite Proxy HTTP history, tôi hốt cái request tương ứng.

Lần này, do cần dò tìm đám hệ thống backend có liên kết nên tôi sẽ ném hàng qua Burp Suite Intruder trước. Tại tab con Positions, tôi xóa đám payload marker đề xuất mặc định (với Clear §) và đổi cái URL chỗ stockApi thành http://192.168.0.1:8080/admin. Kế đến, tôi chọn số “1” cuối trong chỗ địa chỉ IP và click Add § để đánh dấu payload position như sau.

Chuyển qua tab con Payloads, với Payload type Numbers, tôi thiết lập khoảng giá trị từ 1 đến 255 với step bằng 1 để dò IP của các hệ thống có kết nối đến mục tiêu rồi xả đạn với Start attack.

Theo dõi kết quả và sort theo cột Status, tôi quan sát thấy có một thằng trả về code 200 (tương ứng con số 168) với cái href liên quan đến xóa account ghi nhận trong response.

Xong việc với Intruder, tôi đẩy cái request này về Repeater. Sau đó đổi thông tin chỗ stockApi sang /admin/delete?username=carlos và lại triệt hạn account của nạn nhân Carlos.

#4. SSRF attack với chiêu ngụy trang để bypass blacklist-based input filter

Với kịch bản này, mục tiêu đã “rút kinh nghiệm sâu sắc” nên hễ thấy đám input nào có chứa hostname kiểu 127.0.0.1/localhost hay URL /admin nó chém ngay không cần hỏi. Phương án này sẽ cải thiện được tình hình nhưng vẫn có thể bị vô hiệu hóa nến attacker sử dụng các kỹ thuật như:

• Sử dụng các cách biểu diễn khác của 0.0.1, kiểu như 127.1, 2130706433 hay 017700000001.
• Tự dựng domain name để phân giải ra 0.0.1 hoặc dùng Burpcollaborator (tôi sẽ giới thiệu thằng này sau);
• Sử dụng URL encoding và các phương án để ngụy trang, che đậy các cái string nằm trong blacklist.

Lưu ý: Nếu muốn xem kỹ hơn về vụ alternative ip representation, bạn có thể bơi vào GitHub – vysecurity/IPFuscator: IPFuscator – A tool to automatically generate alternative IP representations.

Với ý tưởng nói trên, tôi lao vào phần demo minh họa. Vẫn như cũ, tôi truy cập đại vào một sản phẩm của cái shop bán hàng và thử chạy chức năng Check stock.

Sau đó, tôi túm cái request này bên Burp Suite Proxy HTTP history quăng qua Repeater.

Ở đây, khi định giở trò đồi bại đổi URL chỗ stockApi sang http://127.0.0.1/ tôi sẽ bị chửi thẳng mặt với cái status code 400 kiểu như sau.

Tung hỏa mù ngụy trang, tôi thử chuyển sang http://127.1/ thì mọi chuyện lại trở nên êm đẹp.

Tuy nhiên, nếu định ăn quen chuyển sang http://127.1/admin thì tôi lại bị ăn chửi.

Một lần nữa, tôi lại phải tung đòn ngụy trang với double-URL encoding để giấu đi cái từ cấm “admin” thông qua việc biến cái chữ “a” thành %2561 (khi ứng dụng decode 2 lần thì sẽ nó sẽ hiện nguyên hình thành chữ “a” như sau).

Và trời không phụ lòng người, lần này tôi đã có thể hiên ngang truy cập vào administration interface với chức năng delete user đầy uy quyền.

Với thông tin này, việc ra tay hạ sát account của Carlos chỉ còn mang tính chất thủ tục.