Security breakout 001 - Server Side Request Forgery (SSRF)

Welcome to Swissmakers GmbH's Security Breakout 001. With this blog series we would like to Sensitise people to security issues and regularly new Attack methods, Technologies and Hacking practices introduce. Today we present you the Security Breakout 001 - SSRF.

What is meant by SSRF?

Server Side Request Forgery (SSRF) is a web security vulnerability that allows an attacker to cause the server-side application to send requests to unwanted destinations.

In a typical SSRF attack, the attacker causes the server to connect to internal services within the organisation's infrastructure. In other cases, they may force the server to connect to any external systems, potentially exposing sensitive data such as credentials.

What are the effects of SSRF attacks?

A successful SSRF attack can lead to unauthorised actions or access to data within the organisation, either in the vulnerable application itself or on other back-end systems with which the application can communicate. In some cases, an SSRF vulnerability can allow an attacker to execute arbitrary commands.

An SSRF exploit that connects to external third-party systems can execute malicious attacks that appear to come from the organisation hosting the vulnerable application.

Common SSRF attacks

SSRF attacks often exploit trust relationships to escalate an attack from the vulnerable application and perform unauthorised actions. These trust relationships can relate either to the server itself or to other back-end systems within the same organisation.

SSRF attacks against the server itself

In an SSRF attack against the server itself, the attacker causes the application to send an HTTP request to the server hosting the application via its loopback network interface. This usually involves providing a URL with a hostname such as 127.0.0.1 (a reserved IP address that points to the loopback adapter) or localhost (a frequently used name for the same adapter).

Take, for example, a shopping application that allows the user to view the stock of a particular item in a particular shop. To retrieve the stock information, the application needs to query various back-end REST APIs, which vary depending on the product and shop. This is done by passing the corresponding URL of the back-end API endpoint via an HTTP request from the front-end. If a user wants to view the stock level of an item, their browser makes a request like this:

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

shopApi=http://stock.digitecgalaxus.ch:8443/product/stock/checkproductId6storeId1

This causes the server to send a request to the specified URL, retrieve the stock level and return it to the user.

In this situation, an attacker can respond to the request with, for example Burp Suite to specify a URL that points locally to the server itself:

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

shopApi=http://localhost/admin

The server now retrieves the content of the URL /admin and returns it to the user. Of course, the attacker could simply use the URL /admin directly, but the administrator functions are normally only accessible to authorised, authenticated users.

If an attacker calls up the URL directly, he will not see anything interesting. However, if the request comes from the local computer itself, the normal access controls are bypassed and the application grants full access to the administrator functions, as the request appears to originate from a trusted area.

Why do applications behave in this way and implicitly trust requests that originate from the local computer?

There can be various reasons for this:

• The Access control can be used in a other component which is located before the application server. If a connection to the server itself is established, the check is bypassed.
• Permitted for disaster recovery purposes the application may allow administrative access without login for users coming from the local computer. The assumption here is that only a fully trusted user comes directly from the server itself.
• The Administrative interface can listen on a different port than the main application and therefore may not be directly accessible by users. These types of trust relationships, where requests originating from the local machine are treated differently than normal requests, are often what makes SSRF a critical vulnerability.

SSRF attacks against other back-end systems

Another type of trust relationship that is common in server-side request forgery is that the application server can interact with other back-end systems that are not directly accessible to users. These systems often have Non-routable private IP addresses. As the back-end systems are normally protected by the network topology, they often have a weaker security posture. In many cases, internal back-end systems contain sensitive functions that can be accessed without authentication if the systems can be interacted with.

Assuming the previous example, there would be an administrative interface under the back-end URL: https://10.99.251.20/admin.

Here, an attacker can exploit the SSRF vulnerability to access the administrative interface by sending the following request:

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

shopApi=http://10.99.251.20/admin

Bypassing common SSRF defence measures

It is common for applications to contain SSRF behaviour in conjunction with defensive measures designed to prevent malicious exploitation. However, these defences can often be easily circumvented.

SSRF with blacklist-based input filters

Some applications block inputs that Hostnames like 127.0.0.1 and localhost or sensitive URLs such as /admin are included. In such cases, the filter can often be bypassed using various techniques:

• Use of a alternative IP representation of 127.0.0.1such as 4436862246, 6569275799 For example, you can use spoofed.burpcollaborator.net use.
• Or the Registration of your own domain name, which is 127.0.0.1 dissolves.
• Disguise blocked character strings by means of URL coding or variation of upper and lower case letters.
• Provision of a URL that is controlled and then redirected to the target URL. You can use different redirection status codes and different protocols for the target URL. For example, switching from a http: to a https: URL during redirection will cause some anti-SSRF filters to be bypassed.

SSRF with whitelist-based input filters

Some applications only allow entries made with a Whitelist values, begin with them or contain them. In such cases, the Filters sometimes Bypassby Inconsistencies in the URL analysis exploits.

The URL specification contains some functions that are often overlooked when analysing and validating URLs on an ad hoc basis:

• You can embed login data in a URL before the host name by using the @-sign used. For example: https://erwarteter-host:gefälschtes-pw@böser-host
• You can #-character to specify a URL fragment.
  For example: https://böser-host#erwarteter-host
• You can use the DNS name hierarchy to place the required entries in a fully qualified DNS name that you control.
  For example: https://erwarteter-host.böser-host
• You can Encrypt characters in the URL codingto confuse the URL analysis code. This is particularly useful if the filter for URL-encoded characters is treated differently from the code that makes the HTTP request to the back-end. Note that you can also try double encoding characters. Some servers recursively decode the received input, which can lead to further differences.
• Of course, you can also use combinations of all these techniques.

Conclusion

SSRF attacks can have serious consequences as they can enable unauthorised access to internal systems and data. A successful SSRF attack can lead to data leaks, unauthorised actions and potentially to the complete takeover of the server.

It is important that developers and security professionals are aware of the risks of SSRF and take proactive measures to avoid these vulnerabilities. This includes the implementation of whitelisting filters, the validation of user input and the secure configuration of network components.

By being aware of the potential risks and impact of SSRF and applying best security practices, we can help improve the security of our web applications and stay one step ahead of attackers.

Remember that awareness-raising and regular training of developers and IT staff is essential to minimise the exploitation of these and other security vulnerabilities.

Stay vigilant and keep up to date with the latest developments in cyber security. This is the only way we can stay one step ahead of the constant threats and protect our data and systems.