The State of Server-Side Request Forgery Risks in 2022

Perhaps one of the best Black Hat talks in recent years was renowned web security researcher Orange Tsai’s presentation about bypassing Server-Side Request Forgery (SSRF) defenses. Together with his team, Tsai proposed a “very general attack approach” to discover numerous zero-days in built-in libraries of widely-used programming languages including Java, PHP, Python, Perl, JavaScript and other programming languages.

Now, Tsai’s suggested method is already part of the spectrum of modern solutions used to address SSRF, but the problem persists. Server-side request forgery risks remain, and organizations continue to suffer the costs and inconvenience of being targeted by SSRF attacks. It is important for the solutions to evolve and to properly respond to the changing tactics threat actors employ.

The nature of Server-Side Request Forgery (SSRF)

A Server-Side Request Forgery attack involves the forging, simulation, or deceptive use of a request to access certain server functions to gain access to or modify resources. This threat is specific to applications that allow data imports through URLs or enable the reading of data from URLs.

Here’s a highly simplified way of putting it. Some websites or web services make use of lengthy URLs that bear data that serve as commands to a server. Loading these URLs on a web browser equates to making specific commands. Threat actors can modify these URLs to elicit certain responses from the server.

This “ingenious” attack can affect even web services that are not directly exposed on the public internet. Threat actors can pick a target URL, which then allows them to read the data from the server.

SSRF can either be server or back-end attacks. The first entails the exploitation of a process by which a web browser, app, or some other client system accesses a URL on the server directly. What attackers usually do is modify the URL to point to the local file system on the server and look for ways to access sensitive data.

The second type of server-side request forgery attack, the back-end SSRF, requires a trust relationship with a back-end component, through which the attack perpetrator gains access rights and the ability to perform unauthorized operations.

Server-Side Request Forgery risks

A successful SSRF attack can result in various consequences. Depending on the configuration of systems and the ingeniousness of the attacker, any of the following can happen.

• Unwanted or harmful data access – This is the most common consequence of an SSRF attack. Threat actors can gain access to data on the server. The data that can be accessed depends on the level of access granted to that Identity Access Management (IAM) role.
• Compromising other servers – Server-Side Request Forgery may be used as a reconnaissance tactic, wherein threat actors scan for and gather information about internal networks. As organizations reduce their attack surfaces, they decrease the number of public-facing servers and use servers for internal communications instead. This setup, if not done properly, can create vulnerabilities that can be detected through SSRF. If an attacker manages to gain access to a server through the vulnerabilities identified, it will not be difficult for them to breach other servers within the same network.
• Protocol smuggling attacks – SSRF attack perpetrators know that their attacks will not always yield useful information from the targeted server. Inventive cybercriminals look at other information such as the timeout and response times. With these, it is possible to profile the services on a network and initiate an HTTP smuggling attack to access protected resources and sensitive data, hijack web user sessions and launch cross-site scripting attacks.
• Internal Denial of Service – SSRF can also be used to disrupt web services by flooding internal servers with large amounts of traffic. This is not as big as the typical DoS attacks that target public-facing servers, but it works because of the naturally lower bandwidth configuration of internal servers.
• Remote code execution – Some organizations implement services that are fully interfaced through HTTP queries, which may not impose restrictions on the URL functionality. This can be exploited by cybercriminals to carry out remote code execution on the core server.

These are not new adverse outcomes that come with SSRF, but they remain to be a significant threat to organizations worldwide. OWASP does not consider it a critical concern, given its relatively low incidence rate and above-average testing coverage. Still, it is a serious risk that can have a significant impact on an organization’s operations.

In 2022, a number of SSRF attacks have been documented. One of which was the compromise on Pascom phone systems, which was identified as a flaw in an external piece of software and risk associated with post-authentication remote code execution.

Device42, a full-stack IT discovery and dependency company, was also reported to have had a SSRF vulnerability in the Exago Reports component. The company had to issue an advisory asking all users to update to the latest software version to get the necessary security patches.

There were also reports of an SSRF issue in some versions of the VMWare authentication software. This vulnerability had the potential to allow network access to make HTTP requests to arbitrary origins.

Additionally, an SSRF bug was recently discovered in the OX App Suite, a modular email and productivity software suite specifically intended for the telecommunications industry. This vulnerability reportedly enabled the prediction of multipart-formdata boundaries and the overwriting of its content.

It is also worth noting that even Google itself was discovered to have had an SSRF bug. This was a URL parsing issue that made the Google Cloud project vulnerable to attempts to access sensitive resources and run malicious code. The bug was already patched, but this discovery shows that even the biggest and most renowned technology companies are not safe from SSRF risks.

Addressing SSRF

SSRF may not be as big a threat as several other types of cyberattacks such as ransomware and DDoS, but it is not something to be downplayed. As mentioned, it can also be used to carry out an internal denial of service attack and introduce malicious software (including ransomware) to networks and systems.

To prevent it from becoming a bigger threat, it is advisable to do the following precautionary measures:

• IP whitelisting and DNS resolution – As much as possible, limit access to specific IP addresses or DNS names that are essential in the operation of applications or web services. Only implement blacklisting if the costs outweigh the benefits.
• Unused URL schemas disabling – More URL schemas create more opportunities for attackers. If only HTTP or HTTPS are needed for initiating requests, then it makes sense to only use these schemas.
• Internal service authentication – SSRF vulnerabilities can exist in internal services, which are generally deployed without a verification requirement by default. These are opportunities for threat actors and should be eliminated by requiring verification as much as possible.

Server-side request forgery does not have to be a major threat to an organization. There are easy-to-implement strategies to prevent SSRF attacks from succeeding or escalating into bigger cybersecurity issues. Also, there are existing cyber defense suites that practically make SSRF impotent as an attack vector on modern systems. Virtually all the possible flaws that server-side request forgery attacks exploit can be addressed by advanced cyber defense solutions that include web application firewall, runtime application self-protection, API security, advanced bot protection, attack analysis, and DoS/DDoS functions.

Not much has changed for SSRF in 2022. It has not become a headliner threat, although it would be wrong to think of it as a negligible risk. It should be addressed with the same level of prudence accorded to other threats.