SSRF - Applied Review

What is Server Side Request Forgery?

#

SSRF is a vulnerability that allows attackers to cause the application to make requests to an unintended location from the server that the application is running on.

In a typical SSRF attack, the attacker might get the server to connect to internal-only resources and in some cases attackers can even force the server to connect to arbitrary systems.

What is the Impact?

#

Successful SSRF attacks can often result in unauthorized actions and data access. This can be entirely within the vulnerable application or on other adjacent back-end systems. In some cases, SSRF can even lead to command execution under the right circumstances.

An SSRF exploit that causes connections to external third-party systems might result in malicious onward attacks. these can appear to originate from the organization hosting the vulnerable application.

Common SSRF Attacks

#

SSRF attacks tend to exploit trust relationships to perform actions that would otherwise be unauthorized. These trust relationships might be in relation to the server itself or the back end systems in the same organization.

SSRF Attacks Against The Server

#

When launching an attack against the server, we are just making a request from the vulnerable application back to the server that it is hosted on. This is usually done by supplying a URL with a hostname like 127.0.0.1 or localhost so that any request is sent back to the hosting server.

But, why would an application behave this way?

It could be any number of things but some of the common reasons are:

• The access control check might be implemented in a component that sits between external hosts and the application, meaning internal traffic won’t need authentication.
• The application might allow the application to perform administrative actions on the server for the purpose of recovery (in the event a developer forgot their credentials but wants to be able to access the server).
• The administrative interface might be listening on a different port than the main application, which might not be accessible by normal users.

These kinds of trust relationships that treat internal requests different than ordinary requests are often the kinds of relationships that make SSRF into a critical vulnerability.

HTB - Love

#

This machine has a pretty good, but easy example of SSRF. After performing some initial enumeration and adding a domain to our /etc/hosts file, we can look at a site that gives us the option to log on:

Trying some default credentials doesn’t work out and if we look up the Voting System Using PHP, we do get a few vulnerabilities but they are for an authenticated user.

We can do some subdomain enumeration and find another HTTP host called staging.love.htb which we can view after adding to out hosts file.

It looks like we can get this part of the web application to scan a fie hosted at a particular URL. We can get it to call out to our machine just fine and read file contents but that seems to be all.

We can try reaching out to localhost on port 5000, which our scan returned a 403 - Forbidden error for. Maybe the server on port 80 that we have access too is authorized to view it:

Nice, so using the site’s scanning functionality we were able to circumvent a site on port 5000 that would otherwise be blocked. The whole point here is that we wouldn’t be able to access this endpoint if we couldn’t forge the request from the web application.

SSRF Attacks Against Other Back-End Systems

#

In some cases, the application server is able to interact with other systems in its network. This might make sense if multiple services are hosted on that network that need to share resources from another system. Like if there are two web servers being hosted on two different machines that both make calls to a shared database hosted on another IP in the network.

It would make sense that the database server would not be able to receive requests from outside the network, but if we are able to get the web server to forge requests on our behalf it is a different story.

Circumventing Common SSRF Defenses

#

Sometimes you might run into systems that contain functionality that appear to be vulnerable to SSRF, but have some kind of defenses aimed to stop exploitation. Often times these defenses can be bypassed.

SSRF With Blacklist-Based Input Filters

#

Some applications will block hostnames like 127.0.0.1 and localhost or even sensitive URLs. We can sometimes get around these filters by:

• Using alternative representations of IP addresses
• Register your own domain name that resolves to localhost
• Obfuscate blocked strings using URL encoding case variation
• Provide a URL that you control that redirects to the target URL. Different redirect codes and protocols can sometimes bypass anti-SSRF filters.

HTB - Gofer

#

The main web application doesn’t have much to offer but once we do some subdomain enumeration we can add proxy.gofer.htb to our hosts file and take a look.

But the page requires some kind of authentication, which can be troublesome and running directory enumeration seems to return only 403 codes. If we try a bit harder and look for POST requests when we scan for directories, we are able to see an endpoint called /index.php that will return a 200 so let’s look there in Burp:

If we include a URL parameter like the message tells us to, we can get it to call out to our machine:

But we can’t really tell what the machine is doing with these files even with just a netcat listener to view more of the details. Let’s try and read some local files:

So they are doing some blacklisting that we can try to get around, one way is by converting the IP address to a decimal but when I try it, we get timed out.

I don’t want to get too much off topic for this lab so if you’d want to follow along you can do so using my writeup.

To summarize, we can use this SSRF to send an email to another employee (who we know will click on a malicious file we include) which we have configured to give us a shell when they click on it.

SSRF With Whitelist-Based Input Filters

#

Some whitelist implementations use simple matching that means if we contain the whitelisted value in out input, it will pass the check. We might be able to use this feature in conjunction with inconsistent URL parsing to pull off an exploit.

• You can sometimes embed credentials in a URL before the hostname using the @ character: http://vulnerable:fakepass@evilmachine
• You can use the # character to indicate a URL fragment: http://evilmachine#vulnerable
• You can leverage DNS naming to place input into a FQDN that you control: http://vulnerable.evilmachine
• You can also combine these techniques together.

Bypassing SSRF Filters Using Open Redirection

#

Sometimes filter-based defenses don’t account for redirection-related issues. If a web application is strictly validating a URL to prevent malicious exploitation of SSRF behavior, but application URLs use a vulnerable implementation of open redirect then we might be able to construct a redirect that satisfies the filters and still works.

For example, if a website uses the path parameter to redirect you to a page:

/posts/nextPage?currentPageId=3&path=http://vulnerable.com/page4

But if we are able to manipulate the path parameter to redirect to an IP we control or an internal resource, there could be issues:

/posts/nextPage?currentPageId=3&path=http://evilmachine.com

#or this

/posts/nextPage?currentPageId=3&path=http://localhost/admin

Blind SSRF Vulnerabilities

#

This is when the front-end application doesn’t seem to reveal any information about how the back-end processed our forged request.

The impact for these is often lower than informed (visible) SSRF because of how one-way they are. These don’t allow us to retrieve data as easily, but we can still achieve remote code execution in some cases.

Finding and Exploiting Blind SSRF

#

The most reliable way to do this is by using out-of-band techniques, or trying to trigger an HTTP request to an external system that you control while monitoring for network interactions for that system. You can do this with the Burp Collaborator or a simple netcat listener.

Of course, just triggering out of band requests isn’t really an exploit even though it may not be intended functionality of the web application you’re testing. Further exploitation is mostly contextual but depending on the circumstances you can enumerate for common issues.

HTB Awkward

#

We can start this machine by enumerating a subdomain and then enumerating some endpoints that reveal information about the underlying API. One of the API pages has hashes for users that we can crack to log in and then we can navigate to a dashboard page and start looking through requests when we load the page:

This is one of the requests send during the dashboard refresh process that we might be able to manipulate into SSRF, first we can try to get it to call out to our IP address:

This works, but doesn’t give us much information. We can use this to try and enumerate internal resources by using the Burp Intruder or wfuzz:

╰─ wfuzz -z range,1-65535 --hh 0 -u http://hat-valley.htb/api/store-status\?url\=%22http:%2F%2F127.0.0.1:FUZZ%22
 /usr/lib/python3/dist-packages/wfuzz/__init__.py:34: UserWarning:Pycurl is not compiled against Openssl. Wfuzz might not work correctly when fuzzing SSL sites. Check Wfuzz's documentation for more information.
********************************************************
* Wfuzz 3.1.0 - The Web Fuzzer                         *
********************************************************
Target: http://hat-valley.htb/api/store-status?url=%22http:%2F%2F127.0.0.1:FUZZ%22
Total requests: 65535
=====================================================================
ID           Response   Lines    Word       Chars       Payload        
=====================================================================

000000080:   200        8 L      13 W       132 Ch      "80"           
000003002:   200        685 L    5834 W     77002 Ch    "3002"         
000008080:   200        54 L     163 W      2881 Ch     "8080"         

We can then go into burp and see what is so long on port 3002:

In this instance, we are able to see an internal documentation site that you can use to construct a more complicated attack against the machine.

SSRF Attack Surface Enumeration

#

Many of these vulnerabilities are easy to find because the application’s normal traffic involves the request parameters that contain full URLs. Other types of examples could be hard to find:

Prevention

#

A lot of the prevention techniques are low level in terms of their implementation but there are some general guidelines we can follow:

• Input Validation and Whitelisting: Always rigorously validate and sanitize user input and maintain whitelists of trusted URLs or IP addresses.
• Access Controls: Implement strict access controls to restrict the server’s privileges, ensuring that it only accesses resources necessary for its intended functionality.
• Segregation: Avoid using user input to access internal resources, separating internal and external requests effectively.
• Content Security Policies (CSP): Enforce Content Security Policies to specify which external domains your application is allowed to communicate with, enhancing security.
• URL Parsing: Ensure secure and correct URL parsing within your application to prevent manipulation such as URL encoding.