SSRF:
What is an SSRF?
SSRF, which stands for Server-Side Request Forgery, represents a vulnerability enabling malicious users to manipulate the webserver into generating additional or edited HTTP request to the resource of the attacker's choosing.
Types of SSRF
Two distinct types of SSRF vulnerability exist. The first is a standard SSRF, wherein data is returned and displayed on the attacker's screen. The second is known as Blind SSRF vulnerability, which also involves an SSRF occurrence, but it does not return any information visible to the attacker on their screen.
What's the impact?
Upon a successful SSRF attack, the potential outcomes encompass:
Unauthorized access to restricted areas.
Exposure of customer/organizational data.
Ability to infiltrate internal networks.
Unveiling or revealing of authentication tokens/credentials.
SSRF Examples:
The following illustration demonstrates how the attacker can attain full control over the page requested by the webserver. The Expected Request represents the information on the website.thm server anticipates receiving, wherein the section highlighted in red denotes the URL the website will fetch. The malicious actor has the capability to alter the red zone to any URL they desire, granting them control over the destination of the information retrieval.
The given instance illustrates how a potential attacker can successfully access the /api/user page by exploiting directory traversal. When the website.thm server receives the "../" input, it interprets it as a directive to navigate up one directory level. As a result, the "/stock" portion of the initial request is eliminated, transforming the final request into "/api/user." This manipulation enables the attacker to reach the intended /api/user page.
In this instance, the attacker can manipulate the server's subdomain to receive the request. Notably, the payload ending in "&x=" prevents the remaining path from directly attaching to the attacker's URL. Instead, it transforms into a parameter "?x=" within the query string.
Returning to the original request, the attacker can compel or force the webserver to fetch content from a domain of their choosing. Consequently, we can intercept the request headers sent to the specified domain. These headers might include authentication credentials or API keys sent by "website.thm" that would normally authenticate to "api.website.thm".
What is the flag from the SSRF Examples site?
We change the URL to force the webserver to return data from "https://server.website.thm/flag?id=9", so we change the parameter server form API to the following URL https://server.website.thm/flag?id=9. As we hit enter we can see the server request in the bottom of the browser.
The server asking for "id=2" from ".website.thm/api/item", we can bypass this by adding "&x=" to the end of the URL.
Finding an SSRF
Various potential SSRF vulnerabilities can be identified in web applications through diverse methods. Below, I present four typical locations to investigate:
Certain examples may prove easier to exploit than others, and this is where a lot of trial and error will be required to discover a functional payload.
In cases of blind SSRF where no output is directly reflected back, external HTTP logging tools like requestbin.com, your own HTTP server, or Burp Suite's Collaborator client become indispensable for monitoring requests.
Defeating Common SSRF Defenses
Security-conscious developers who are aware of the risks associated with SSRF vulnerabilities often implement checks in their applications to ensure that requested resources adhere to specific rules. Typically, there are two approaches to this: a deny list and an allow list.
Deny List
A Deny List approach involves accepting all requests except those that match specific resources listed or follow particular patterns. Web applications may use a deny list to safeguard sensitive endpoints, IP addresses, or domains from public access while permitting access to other locations. For instance, the "localhost" endpoint, which might contain server performance data or sensitive information, could be included in a deny list. However, attackers can potentially bypass a Deny List by using alternative references to "localhost," such as 0, 0.0.0.0, 0000, 127.1, 127.*.*.*, 2130706433, 017700000001, or by utilizing subdomains with DNS records resolving to the IP Address 127.0.0.1, like 127.0.0.1.nip.io.
In a cloud environment, it's essential to restrict access to the IP address 169.254.169.254, which holds metadata for the deployed cloud server, potentially containing sensitive information. However, attackers may attempt to bypass this by setting up a subdomain on their own domain with a DNS record pointing to the IP address 169.254.169.254.
Allow List
An allow list operates by denying all requests unless they are listed or match specific patterns, like requiring URLs in parameters to start with "https://website.thm." However, an attacker can exploit this by creating a subdomain on their domain, like "https://website.thm.attackers-domain.thm." The application logic would accept this input, enabling the attacker to control the internal HTTP request.
Open Redirect
In case the previous bypass attempts fail, the attacker can resort to an open redirect. An open redirect is a server endpoint that automatically redirects website visitors to another web address. For example, consider the link "https://website.thm/link?url=https://tryhackme.com," designed to track the number of clicks for advertising/marketing purposes. If the application has a potential SSRF vulnerability with strict rules allowing only URLs beginning with "https://website.thm/," the attacker can exploit this feature to redirect the internal HTTP request to a domain of their choosing.
SSRF Practical
During our content discovery exercise against the Acme IT Support website, we encountered two new endpoints. The initial one, "/private," presented an error message indicating that the contents were inaccessible from our IP address. The second endpoint, "/customers/new-account-page," introduced a novel feature that enables customers to select an avatar for their accounts.
Once you signed in, visit https://10-10-70-92.p.thmlabs.com/customers/new-account-page to view the new avatar selection feature. By viewing the page source of the avatar form, you'll see the avatar form field value contains the path to the image. The background-image style can confirm this in the above DIV element as per the screenshot below:
If you choose one of the avatars and then click the Update Avatar button, you'll see the form change and, above it, display your currently selected avatar.
Viewing the page source will show your current avatar is displayed using the data URI scheme, and the image content is base64 encoded as per the screenshot below.
Now, we will attempt to make a request, but this time we'll modify the "avatar" value to "private," hoping the server will access the resource and bypass the IP address block. To achieve this, start by right-clicking on one of the radio buttons in the avatar form and then select Inspect:
And then edit the value of the radio button to private:
Make sure to select the avatar you edited, and afterward, click on the Update Avatar button. However, it appears that the web application employs a deny list, which blocks access to the "/private" endpoint.
Observe the error message indicating that the path cannot begin with "/private." However, don't worry, we still have a trick to bypass this restriction. Let's use a directory traversal technique to reach our intended endpoint. Try setting the "avatar" value to "x/../private."
As you can see, we have successfully bypassed the rule, and the user's avatar has been updated. This trick works because when the web server receives the request for "x/../private," it interprets the "../" string as moving up one directory level, resulting in the request being translated to just "/private."
Upon inspecting the page source of the avatar form, you'll notice that the presently set avatar contains the contents from the "/private" directory, encoded in base64 format.
We can decode this content VEhNe1lPVV9XT1JLRURfT1VUX1RIRV9TU1JGfQ==
$echo "VEhNe1lPVV9XT1JLRURfT1VUX1RIRV9TU1JGfQ==" > file
$base64 -d file
THM{YOU_WORKED_OUT_THE_SSRF}
And we got the flag THM{YOU_WORKED_OUT_THE_SSRF}