Server-side Request Forgery – Open door to Your internal services

CYBERS 12.07.2021

Server-side request forgery aka SSRF, is a vulnerability that enables an attacker to use a vulnerable server as a proxy to make HTTP requests on behalf of the attacker. SSRF’s are regularly used to target internal services that are behind firewalls and not exposed to the public directly. A vulnerable server could allow mapping the internal network or services and possibly give access to administrative functionality. A good example of such vulnerability could be the Microsoft Exchange Server CVE-2021-26855 aka ProxyLogon

What can we do with SSRF?

Server-side request forgery can be made possible when a web application is making a request and the attacker has partial or full control over request parameter(s). As Burp Suite is a common tool in the penetration testing community, examples from their SSRF lab are used within this blog post to show how the attack works. The attack diagram representing the flow of the attack is taken from the OWASP cheat sheet series, which is another very good resource for penetration testers.

 

SSRF attack diagram from OWASP:

[/vc_column_text][vc_single_image image=”7280″][vc_column_text]

Example request:

POST /product/stock HTTP/1.0

Content-Type: application/x-www-form-urlencoded

Content-Length: 118

stockApi=http://stock.weliketoshop.net:8080/product/stock/check%3FproductId%3D6%26storeId%3D1

As we can see, stockApi parameter is using the full URL as a value to fetch some data. This could be abused if the application has no protection against it.

Malicious request:

POST /product/stock HTTP/1.0

Content-Type: application/x-www-form-urlencoded

Content-Length: 118

stockApi=http://localhost/admin

With this request, we are trying to get the internal admin page content. By fetching this page, a malicious user could see the admin panel because the request comes from the server itself and not from outside.

SSRF is not limited to HTTP protocol!

HTTP requests are the most common examples of SSRF, but it is not limited to that as the application itself does the second request.  It could be possible to use different protocols (such as FTP, SSH, SMTP, SMB, etc.) or schemes (such as file://, gopher://, dict://, php://, jar://, tftp://, sftp//, ldap// etc.). These are highly dependent on the application under testing.  Additionally, in case there is XML external entity injection vulnerability in the application, it is highly likely that it could be turned into SSRF  attack.

Based on these examples, the malicious request could also look like this:

POST /product/stock HTTP/1.0

Content-Type: application/x-www-form-urlencoded

Content-Length: 118

stockApi=file:///etc/passwd

If the application would be vulnerable to this attack, the content of the password file would be returned in the response.  But this could be used to get any other file, and this could mean revealing secrets on the server or used by the application. For example AWS keys and internal data.

It could be possible to map internal IP-s and services on these:

POST /product/stock HTTP/1.0

Content-Type: application/x-www-form-urlencoded

Content-Length: 118

stockApi=sftp://localhost:2222

This request might return an SSH service banner and with that knowledge of what library is in use. This might open up a new attack vector, an example from the older days would be ShellShock.

What is a blind SSRF attack?

A blind SSRF attack is when the backend server does the requests for attacker issues, but the response is not sent to the frontend. This still can be detected when the attacker monitors networks requests to the domain they control. In penetration tests, one of the ways to test this would be with the Burp Collaborator plugin and by using the Burp Collaborator client to generate a new domain.

Example of such case from blind SSRF lab:

GET /product?productId=2 HTTP/1.1

Referrer: https://918luczqaiigs075z5e4cc413s9ix7.burpcollaborator.net

And when polling information from the Burp Collaborator client, it is possible to see that HTTPS request to that burpcollaborator.net domain was done.

How SSRF vulnerabilities can be dangerous?

SSRF attacks could lead to data exfiltration or even worse, system-level access to affected service. The aforementioned ProxyLogon vulnerability is a good example of this from the Microsoft Exchange SSRF vulnerability (CVE-2021–26855), which allowed attackers to send arbitrary HTTP requests with the highest privileges on internal services. It made it very easy to download any user’s emails by just knowing the victim’s email address. Another use case would have been uploading a web shell to a vulnerable server. For that SSRF attack would have been combined with CVE-2021–26858 or CVE-2021–27065 to write a file onto the server.  A good review of the attack against Exchange servers could be read from here: Hunting Down MS Exchange Attacks. Part 1. ProxyLogon (CVE-2021–26855, 26858, 27065, 26857)

There are many examples of how SSRF has been used against well-known services and companies, one good awarded bug bounty is from Ezequiel Pereira and how he found remote code execution through SSRF in Google Cloud Deployment Manager and was awarded $164,674 for this bug. For that same finding, there is a very good video also.

Mitigation

Unfortunately, there is no universal solution how to fix this. A good start would be by whitelisting IP addresses and DNS names that the application is allowed to access. Have strong input validation throughout the application and do not allow the application to trust any input. If possible, whitelist protocols and schemas used by the application so no other could be used. Additionally, have a generic error message for exceptions and define a “last resort” error message,  in case all other exception handling fail.

Conclusion

Server-side request forgery attacks make use of parameters where full or partial URL is used or can be used. This could be a dangerous vulnerability to have on Your application. In recent years it has had more attention because as widely used systems have been affected, like referenced throughout this blog post. Protect Your application by having strong input validation and whitelisting. Get Your application tested by professionals!

Latest blog posts

03.03.2022

Cybersecurity as part of defense measures against modern war fighting capabilities

CYBERS in cooperation with Recorded Future will share insights on the ongoing cyber crisis which started several months before the military invasion. This article provides an overview of the current situation, as well as the recommended emergency actions that should be taken by organizations to withstand this cyber conflict.

Keep reading
20.01.2022

Testing and identifying the value of your next cybersecurity solution

The security world is changing rapidly and we are slowly reaching another huge milestone. Not a very happy one though: manual security operations are no longer sufficient. This is a little bit painful to admit but the fact remains: if you rely on the manual labour of CTOs, CISOs and their teams to react to an incident, then you are in for a very rude awakening.

Keep reading
27.12.2021

Are you at risk from the security vulnerability found in the Java-based Apache Log4j logging feature?

A security hole was discovered in the Java-based Log4j logging feature, affecting millions of businesses, government agencies, and cloud services using this popular Apache library. Are you at risk?

Keep reading