Major milestone in cybersecurity: CYBERS integrated into NEVERHACK’s ecosystem
Press release: CYBERS joins NEVERHACK SAS, a leading European cybersecurity group, to enhance its market position, expand reach, and offer added value to its clients.
Server-side Request Forgery – Open door to Your internal services
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]
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
Strategic Merger Unites CYBERS and NEVERHACK: A New Dawn in cybersecurity
CYBERS and NEVERHACK Merger: A Game-Changing Alliance in cybersecurity
Securing the future: uniting service design and cybersecurity for digital excellence
Explore the fusion of service design and cybersecurity in our latest blog post, inspired by KüberCAST’s enlightening episode with Andres Kostiv. Learn how this integration not only enhances digital service innovation but also fortifies user trust and safety in the evolving digital landscape.