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
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.
[/vc_column_text]
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.
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.
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.
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.
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.
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.
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.
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.
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.
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!
In this edition of KüberCAST, Ronnie Jaanhold and Siim Pajusaar, along with guest Andrus Aaslaid, delve deeper into this phenomenon. Tune in to the podcast and discover what lies beneath the seemingly ordinary radio station frequencies.
In today’s world, it is not enough to claim that we know and do everything safely. Customers and business partners want proof of this statement, and now we can confirm it – we are certified according to the ISO 27001 standard.
Locked Shields is the world’s largest cyber defense exercise of its kind, organized by the NATO Cooperative Cyber Defence Center of Excellence (CCDCOE). The event was held from 18 to 21 April in Tallinn and had nearly 3,000 participants. Participants included NATO member states and NATO-friendly countries (last year Georgia, this year Ukraine). The main … CYBERS & NATO CYBER DEFENSE EXCERCISE LOCKED SHIELDS
