Server-side request forgery (SSRF)

 SSRF attacks can be challenging to detect because the requests come from a legitimate server, making them look like normal traffic.

WHAT IS SSRF:

In an SSRF attack, an attacker exploits a vulnerability in a web application that allows them to control the input to a server-side request. By manipulating the input, an attacker can trick the server into making requests to other systems, often with the goal of stealing sensitive data or compromising other systems. Server-Side Request Forgery (SSRF) is a type of web application vulnerability that allows an attacker to make unauthorized requests from a vulnerable server to other web applications or internal systems that are not intended to be accessible from the internet.

HOW TO CHECK AND EXPLOIT SSRF:

→For example in this application when we check the stock the application sends a request to the relevant back-end API :

This causes the server to make a request to the specified URL, retrieve the stock status, and return this to the user. In this situation, an attacker can modify the request to specify a URL local to the server.

Here, the server will fetch the contents of the /admin URL and return it to the user. We can use this vulnerability to delete the user weiner

SSRF attacks can be challenging to detect because the requests come from a legitimate server, making them look like normal traffic.

→ Basic SSRF against another back-end system:

Let’s use the stock check functionality to scan the internal 192.168.0.X range for an administrative interface on port 8080.

Let’s use burp intruder:

Payload:

To scan 1–100 ports

I got a 200 status code as the response on port 13. So let's create the payload to exploit this vulnerability:

Now let's delete the user Carlos:

SSRF with blacklist-based input filters:

Some applications block input containing hostnames like 127.0.0.1 and localhost, or sensitive URLs like /admin.

We can bypass the filter by using an alternative IP representation of 127.0.0.1, such as 2130706433, 017700000001, or 127.1

Still doesn’t work. Let’s URL encode the first letter of admin “a”, which is “%61”:

Still no use. Let’s double URL encode “a”, which is “%61”:

Now it works and we got access to /admin panel.

SSRF with whitelist-based input filters:

In some cases, the input to the application that triggers the SSRF vulnerability is filtered or validated based on a whitelist of allowed URLs. This is done in an attempt to prevent unauthorized requests to internal systems or arbitrary external systems. However, if the whitelist is not properly implemented or the attacker is able to bypass it, an SSRF vulnerability can still be exploited.

The application is parsing the URL, extracting the hostname, and validating it against a whitelist.

This is how the actual request looks like:

stockApi=http%3a//stock.weliketoshop.net%3a8080/product/stock/check%3fproductId%3d2%26storeId%3d1

Let’s URL decode this( ctrl+shift+u ):

stockApi=http://stock.weliketoshop.net:8080/product/stock/check?productId=2&storeId=1

The URL specification contains a number of features that are liable to be overlooked when implementing ad hoc parsing and validation of URLs:

• You can embed credentials in a URL before the hostname, using the @ character. For example:
• https://expected-host:fakepassword@evil-host
• You can use the # character to indicate a URL fragment. For example:
• https://evil-host#expected-host
• You can leverage the DNS naming hierarchy to place required input into a fully-qualified DNS name that you control. For example:
• https://expected-host.evil-host

Let’s add a # to the username:

From this response we can understand that the part comes after the “http://” part is considered a the URL and anything after the ‘#’ is a reference to an element in the application.

Let’s double URL encode the ‘#’ to check if this can bypass the filter.

It works.

Let’s give a real value because username in this case is not a real value:

Now let’s enter the admin panel at /admin

Payload:

stockApi=http://localhost%2523@stock.weliketoshop.net/admin

In this case the parser is viewing:

localhost -> URL

%2523@stock.weliketoshop.net -> an element in the application

/admin -> as the path

Bypassing SSRF filters via open redirection:

If the application whose URLs are allowed contains an open redirection vulnerability. Provided the API used to make the back-end HTTP request supports redirections, you can construct a URL that satisfies the filter and results in a redirected request to the desired back-end target.

For example, suppose the application contains an open redirection vulnerability in which the following URL:

/product/nextProduct?currentProductId=6&path=http://evil-user.net

returns a redirection to:

http://evil-user.net

You can leverage the open redirection vulnerability to bypass the URL filter, and exploit the SSRF vulnerability as follows: stockApi=http://weliketoshop.net/product/nextProduct?currentProductId=6&path=http://192.168.0.68/admin

Blind SSRF vulnerabilities:

Blind Server-Side Request Forgery (SSRF) vulnerabilities refer to a situation where an attacker can exploit an SSRF vulnerability, but the response from the server is not directly visible to the attacker. This could be due to the fact that the response is filtered, or the attacker is not in a position to access the response.

The impact of blind SSRF vulnerabilities can be more severe compared to other SSRF vulnerabilities. This is because blind SSRF vulnerabilities can be more difficult to detect and exploit, leading to them being present in applications for longer periods of time.his can result in a range of attacks, such as:

1. Data exfiltration: An attacker can use a blind SSRF to exfiltrate sensitive data from the target system by making requests to internal resources or other systems accessible via the network.
2. Remote code execution (RCE): Blind SSRF vulnerabilities can be used to execute code on remote systems, potentially leading to complete compromise of the system.
3. Port scanning and network enumeration: Attackers can use blind SSRF to probe for open ports and identify other hosts and services on the network, potentially leading to further exploitation.
4. Resource depletion: An attacker can use blind SSRF to create an excessive amount of network traffic, which can result in resource depletion and system instability.

WHY IT IS CAUSED:

Server-Side Request Forgery (SSRF) vulnerabilities are typically caused by inadequate input validation or sanitization. SSRF occurs when an attacker can control or influence the input parameters of a server-side application, allowing them to make unauthorized requests to internal or external systems that are normally inaccessible.

This can happen due to a range of factors, including a lack of input validation, insufficient access controls, or poorly configured network infrastructure. In some cases, attackers may also be able to exploit vulnerabilities in third-party software or libraries that are used by the server-side application.

Commonly, SSRF attacks can occur through web applications that have functionality for fetching resources from other servers, such as image loading or APIs. Attackers can then manipulate these requests to make them point to internal resources, bypassing security controls and accessing sensitive information.

WAYS TO PREVENT:

To prevent SSRF vulnerabilities, it’s essential to carefully validate and sanitize all input parameters that can be influenced by users, implement secure access controls, and limit access to sensitive resources as much as possible. Preventing SSRF requires a combination of secure coding practices, configuration hardening, and network security measures. Here are some ways to prevent SSRF:

1. Input validation and whitelisting: Validate and sanitize user input, especially URL parameters and user-supplied data, to ensure they conform to expected formats and only contain allowed characters. Implement strict input validation using whitelisting techniques to prevent attackers from providing malicious URLs or IP addresses.
2. Use a robust URL parser: Utilize a well-tested URL parsing library or function that can accurately handle various URL formats and prevent any misinterpretation or manipulation of user-supplied URLs.
3. Enforce strict server-side access controls: Implement strong access controls at the server level to restrict requests to only necessary resources and prevent access to internal systems or sensitive information. This includes proper authentication and authorization mechanisms.
4. Implement network-level protections: Use firewalls and network security measures to restrict outbound connections from the server. Apply egress filtering to prevent requests to internal or private IP ranges, loopback addresses, and other sensitive network segments.
5. Use a web application firewall (WAF): Deploy a WAF that includes SSRF protection features. A WAF can detect and block malicious requests attempting SSRF attacks by analyzing patterns and signatures associated with SSRF techniques.
6. Limit or disable URL redirection: If your application includes features like URL redirection or forwards, ensure that the functionality is restricted and only allows trusted and validated URLs.
7. Use DNS resolution controls: Restrict DNS resolution to trusted DNS servers and prevent server-side applications from resolving arbitrary hostnames or IP addresses. Implement DNS whitelisting or blacklisting to control which resources can be accessed.
8. Secure server-side configurations: Review and harden server configurations to prevent SSRF vulnerabilities. Disable unnecessary services or protocols use secure default settings, and regularly patch and update software to mitigate known vulnerabilities.
9. Regular security testing and code review: Perform security testing, including vulnerability scanning and penetration testing, to identify and remediate SSRF vulnerabilities. Conduct code reviews to ensure secure coding practices are followed.
10. Educate developers and administrators: Provide training and awareness programs for developers and system administrators to familiarize them with SSRF risks, prevention techniques, and best practices for secure coding and server configuration.

Remember that SSRF prevention requires a multi-layered approach, including a combination of secure coding practices, proper configuration, and ongoing security monitoring. It’s essential to stay updated with the latest security practices and vulnerabilities to effectively protect against SSRF and other emerging threats.