In this blog, we will dive into the fundamentals of SSRF and explore how to exploit it to get bug bounties
Learning SSRF for Fun and Bounties
In this blog we are going to explain what Server-side request forgery (SSRF) is and how you can exploit it to find vulnerabilities and earn some bounties.
Imagine you're browsing the Internet. You click on a link that takes you to a website. Normally, your browser requests information from that website, and it shows you what you asked for. But what if a hacker tricks the website into asking for something else – something they want, not what you want?
That's a bit like what SSRF is about. It's a vulnerability that allows a hacker to make a server send requests, not from you, but from itself. So instead of you asking for a webpage, the server might be tricked into asking for sensitive information or accessing systems it shouldn't. This could mean accessing the admin panel, files, or even talking to other servers within a network, all without the server owner knowing.
Think of it like someone is pretending to be you, asking for things you never intended to ask for. This can be a big problem because it can lead to data leaks, unauthorized access to systems, or even the server being used to attack other computers or networks.
When it comes to SSRF attacks, there are three main types based on how the server responds to the initial request.
Blind SSRF: In a blind SSRF, the original request doesn't provide any information about the target service. The attacker submits a URL but doesn't get any data in return. To check if the server is vulnerable, the attacker needs to make DNS or HTTP queries to a server they control.
Semi-Blind SSRF: Unlike blind SSRF, the semi-blind version gives some information back. The attacker gains access to partial data, such as error messages or metadata about a request, like response times. While this confirms the vulnerability, it doesn't expose sensitive data.
Non-Blind SSRF: The most serious type is non-blind SSRF. Here, data from any URL can be taken and sent to the attackers who initiated the query. Non-blind SSRF allows hackers to access information that can be used to launch further, potentially harmful, attacks.
Imagine a scenario where a hacker discovers an SSRF vulnerability on a payment site. This site allows users to upload invoices via a URL to generate a PDF version. The site processes the URL to fetch the content and convert it into a downloadable PDF invoice.
The hacker, aiming to access the admin panel of the payment site, crafts a malicious request inputting a URL that points to an internal system's admin interface instead of a valid invoice URL, something like "http://internal-site/admin-panel". The payment site, trusting the user-provided URL and unaware of the manipulation, attempts to fetch the content from the specified URL (http://internal-site/admin-panel) to generate the PDF invoice.
POST /generate-invoice HTTP/1.1
Host: payment-site.com
Content-Type: application/json
Content-Length: 96
{
"url": "http://internal-site/admin-panel",
"format": "pdf"
}
The SSRF vulnerability enables the payment site's server to send a request to the internal URL as instructed by the hacker. The internal system, assuming the request comes from the trusted payment server, responds by providing access to the admin panel's sensitive information which was not previously accessible by the public internet. As a result, the hacker successfully leverages SSRF to access the internal admin panel through the payment site's vulnerability, potentially compromising sensitive data, altering configurations, or performing unauthorized actions on the internal system.
HTTP/1.1 200 OK
Date: Fri, 20 Nov 2023 12:00:00 GMT
Content-Type: application/pdf
Content-Length: [Length of the PDF file]
%PDF-1.4
%âãÏÓ
[Binary PDF Data Here]
Certain times, applications will only accept inputs that align with a specific list of allowed values. These filters might check for matches either at the start or within the input. Exploiting differences in how URLs are interpreted could potentially help bypass such filters.
The "@" symbol can sometimes trick SSRF filters. When placed in a URL, it might be overlooked by security measures, allowing attackers to manipulate the URL to access internal systems. For example:
http://example.com@internal-site.comHere, the example.com will be interpreted as a username and the web server will make a request to internal-site.com. This can come handy when the application only checks if example.com is present in the URL or not.
Open redirects on a website can be used to bypass SSRF protection. An open redirect occurs when a web application allows external URLs to redirect users. Attackers use these to redirect requests to internal systems. For instance:
http://example.com/redirect?url=http://internal-site.comDNS rebinding is a technique that abuses the time delay in DNS resolution. It involves using a domain that initially points to an external server but later switches to an internal IP, thus bypassing SSRF protection that only checks initial URL validations.
You can use this tool: https://lock.cmpxchg8b.com/rebinder.html
Attackers might encode URLs differently to deceive SSRF filters. Encoding the URL in various formats (like percent encoding or double URL encoding) can confuse security checks, allowing access to internal systems.
Attackers might purchase or control a domain that redirects or points to an internal application's IP address. By crafting requests with this domain, they can indirectly access the internal application through SSRF.
Each of these methods aims to trick the server into thinking it's accessing an external resource when, in reality, it's gaining unauthorized access to internal systems. Web developers need to be aware of these techniques and employ strong security measures to prevent such bypasses.
SSRF attacks can get around restrictions set by developers that limit access to specific domains or IPs. These restrictions are usually in place to stop outside attackers from reaching internal networks. With SSRF, because the server can make requests on behalf of itself, it can go past these restrictions. Servers within the internal network see the request as coming from within the network itself, letting it slip through despite the restrictions. Let's explore how we can take advantage of SSRF using some common tricks to make it work in our favor.
In an SSRF attack an attacker can manipulate the application into sending an HTTP request back to the server that hosts the application. This request uses the server's internal loopback network interface. The attacker achieves this by providing a URL with a specific hostname, commonly 127.0.0.1, localhost or 0.0.0.0 (which signifies the loopback IP), directly pointing to the server's loopback adapter.
This enables the attacker to access resources that are typically restricted, such as an admin page. While a direct visit to /admin might not reveal sensitive information without proper authentication, triggering the request from the local machine bypasses these security measures, granting unfettered access to administrative functionalities.
Not all SSRF attacks aim to steal data. Some attackers use details like response times to determine the success of a request. If the attacker can pinpoint a port and host, they might execute a port scan on the application server's network. This involves leveraging metadata to gauge whether a connection to a specific port is successful. By analyzing response times, attackers establish a baseline for unsuccessful requests. Successful requests significantly differ from this baseline, either being notably shorter or occasionally longer, hinting at potential vulnerabilities.
Example: Suppose you found a Blind SSRF on our payment. Now to increase the impact you can try to port scan any internal server in their network. As discussed previously by analyzing response time/body we can determine if a server/port is alive or not.
For example, when you send a request to an internal server (eg. 10.0.0.1), the server responds with:
POST /generate-invoice HTTP/1.1
Host: payment-site.com
Content-Type: application/json
Content-Length: 96
{
"url": "http://10.0.0.1",
"format": "pdf"
}
The server responds within 20ms
While with a request to:
POST /generate-invoice HTTP/1.1
Host: payment-site.com
Content-Type: application/json
Content-Length: 96
{
"url": "http://10.0.0.2",
"format": "pdf"
}
The server took 100ms to responds
This difference indicates that 10.0.0.1 is a valid host on the network, unlike 10.0.0.2.
Furthermore, SSRF can also be utilized to conduct port scanning on network machines and uncover the services they run. By providing the vulnerable endpoint with various port numbers of identified internal machines, attackers can distinguish server behaviors based on different ports.
For instance, sending a request to port 22 on an internal server (10.0.0.1:22) took 20ms while a request to port 890 on the same server (10.0.0.1:890) took 2200ms:
This time discrepancy indicates that port 22 is open on the server, while port 890 is not. Such insights help attackers identify services running on specific ports, aiding in planning tailored attacks based on the discovered services.
When exploiting Server-Side Request Forgery (SSRF) vulnerabilities, attackers Instance Metadata URLs to access sensitive data within cloud environments like Amazon Web Services (AWS) and Google Cloud. This enables cloud instances to access an API that returns data about the instance itself. The information these services reveal is often extremely sensitive and could potentially allow attackers to escalate SSRFs to serious info leaks and RCE (Remote Code Execution).
In AWS if the instance is using IMDSv1 you can query metadata using a simple GET request. For the IMDSv2, you need to ask for a token sending a PUT request with a special HTTP header and then use that token to access the metadata with another HTTP header thus making it difficult to exploit. In AWS you can use the following URLs to query metadata:
http://169.254.169.254
http://[fd00:ec2::254]
In GCP, you will need to add the header "Metadata-Flavor: Google" or "X-Google-Metadata-Request: True" to access the metadata endpoint in with the following URLs:
http://169.254.169.254
http://metadata.google.internal
http://metadata
You can use legacy-endpoint-access URLs to circumvent header requirements such as:
http://metadata.google.internal/computeMetadata/v1beta1/
For more details checkout: https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf
If an SSRF vulnerability is discovered within a system handling PDF generation or XML documents, attackers can use this to access sensitive local files such as:
Attackers can manipulate SSRF vulnerabilities to read vital system files, such as:
/etc/passwd: This file stores user account information, crucial for system access and authentication.
/etc/shadow: Contains encrypted password data for user accounts, a goldmine for attackers seeking credentials.
Exploiting SSRF, attackers can read environment-related files like:
/proc/self/environ or /proc/<pid>/environ: These files contain environment variables for the current process or a specified process, potentially revealing sensitive information.For systems running Kubernetes, attackers can target:
/var/run/secrets/kubernetes.io/serviceaccount/token: This file holds the service account token used for authenticating with the Kubernetes API. Unauthorized access compromises the security of the entire Kubernetes environment.Gopher, a lesser-known protocol from the early days of the internet, it was created for file access across TCP/IP networks.
SSRF Exploitation with Gopher: Gopher proves valuable in SSRF exploitation due to its flexibility. For instance, an SSRF payload like gopher://<IP>:<PORT>/<BYTES> can specify IP, port, and bytes for a listener to send. This allows communication with TCP servers, potentially exploiting SSRF.
You can use Gopherus to generate payloads for several services such as SMTP and MySQL