Server-Side Request Forgery (SSRF) is an attack in which, an attacker can abuse functionality on the server to read or update internal resources.
Table of Contents
- What is SSRF?
- What are the possible attacks via SSRF
- How Server-Side Forgery works
- Deep Understanding of Capital One SSRF Breach
- Performing a SSRF Attack Using BurpSuite Tool
- Prevention from SSRF Attack
- Conclusion
What is Server-Side Request Forgery (SSRF) Attack?
Server-Side Request Forgery (SSRF) refers to an attack, wherein an attacker can send a maliciously crafted request from a vulnerable web application. SSRF is mainly used to target internal systems behind WAF (web application firewall), that are unreachable to an attacker from the external network. Additionally, it’s also possible for an attacker to mark SSRF, for accessing services from the same server that is listening on the loopback interface address called (127.0.0.1).
What are the further Attacks that are possible via SSRF?
- Bypass Whitelisting
It helps the attacker to bypass the IP Address Whitelisting to perform his attacks.
Misusing the Trust relationship between the vulnerable server and others.
- Bypassing Authentication levels
It helps the attacker to bypassing the Host-based authentication services.
- Interacting with Services
It allows the attacker to View status pages and interact with the APIs as the webserver.
- Cross-Site Port Attack (XSPA)
SSRF allows an attacker to perform a port scan to further enumerate other systems.
- Internal Scans
It allows the attacker to scan the internal systems and services which are behind the vulnerable system.
- Providing Pseudo-anonymity
It provides a Pseudo-anonymity for the attacker as the requests are routed via the vulnerable system.
- Enumerating Other Protocols
Attackers can use HTTP to enumerate other protocols. It is possible to make a request to other protocols through a web browser over HTTP, using URLs such as “ssh://”, “ftp://”, and “file://”. (E.g. PHP also supports quite a few other protocols such as (fopen(), copy(), filesize())by default, which makes SSRF vulnerabilities on PHP servers especially dangerous.)
Vulnerability Classification and Severity Table
How Server-Side Request Forgery Works?
As the attacker’s request is blocked by the firewall, he cannot send a direct request to the victim’s server, so in order to attack the target server the attacker has to:
- Send a request to the vulnerable web server that abuses the SSRF vulnerability.
- The web server makes a request to the victim’s server which is situated behind the firewall.
- The victim’s server responds with the data.
- If the specific SSRF vulnerability permits it, the data is sent back to the attacker.
A Simple Scenario for SSRF
Typically, Server Side Request Forgery (SSRF) occurs when a web application is making a request, where an attacker has full or partial control of the claim that is sent. A typical example is when an attacker can control all or a part of the URL to which the web application makes a request to some third-party services. Here, I had captured the parameter of file= URL, and I’ve tried to perform this server-side forgery attack.
In the above figure, the perpetrator forges a request for a fund transfer website, and he embeds it into the visitor site. When the visitor logs the website for the transaction and clicks the perpetrator created link, it eventually redirects to the perpetrator’s site, and the amount is transferred to his account.
Deep understanding of Capital One SSRF Breach
One of the most notable breaches of 2019 was the Capital One breach, where the attacker used a Server Side Request Forgery (SSRF) attack to steal data.
Case Study
On 29th July 2019, Capital One Financial Corporation announced that they had determined there was unauthorized intrusion takes place by an unknown outsider who stolen customers Personal Information those who were applied for credit card product and Capital One credit card customers details.
Affected People?
Capital One states that this breach affected,
- Approximately 100 million individuals in the U.S.
- Nearly 6 million people in Canada.
What Hackers Gained?
The attacker gained access to data that approximately included,
- 140,000 Social Security numbers,
- Nearly 80,000 bank account numbers on U.S. consumers, and
- Roughly 1 million Social Insurance Numbers (SINs) for Canadian credit card customers.
What Capital One had Done?
Capital One immediately fixed the issue and immediately began to work with federal law enforcement and captured the intruder with the help of the FBI. The Government makes sure that there is no evidence the stolen data was used for fraud or shared by the attacker.
A Copy of the Complaint for the Violation tells this.
Outline of the Breach
- On July 19th 2019, a security researcher reached Capital One via its Responsible Disclosure Policy email address stating that he had found a public Github gist that contains the commands that were run and the list of AWS S3 buckets with sensitive data was stolen.
- The attack to obtain the keys to gain access to S3 and the downloading of the data happened on March 22 and 23, 2019
Technical Summary of the Attack
Here is a summary of how the Capital One breach happened,
- The attacker gained access to a set of AWS access keys by accessing the AWS EC2 metadata service via an SSRF vulnerability.
- The vulnerable application was the open source legacy WAF (Web Application Firewall) ModSecurity.
- ModSecurity was deployed on AWS’ EC2 (Elastic Cloud Compute) service and thus had access to an AWS backend service known as the Metadata service.
- The AWS Metadata service is a web service only EC2 instances (virtual machines running on EC2) have access to, and when an instance makes a request to that service, it provides metadata information about that instance.
- In the case of Capital One, the vulnerable WAF accepted a malicious request from the attacker, which queried the metadata service and returned the AWS IAM (Identity and Access Management) role running the instance hosting the WAF, back to the attacker.
- That role was configured to be overly permissive and had access to the sensitive customer data stored in AWS S3 (Simple Cloud Storage Service) buckets and the access keys allowed the attacker to list and sync the S3 buckets to a local disk thereby providing access to all the data contained in them then used to download that data.
Performing a SSRF Attack Using BurpSuite Tool
By this attack, an attacker can gather information about ports, IP addresses, Remote Code Execution (RCE), and can also discover the IP addresses of servers running behind a reverse proxy, etc.
For example, I had tried SSRF attack on a testing site for your reference.
POC 1: In Burp Suite, I checked for some different redirection parameters other than URL=, and in the search field, I’ve tried with various parameters. By using this parameter of file=, I’ve captured the request of the particular path and had sent it to the repeater.
POC 2: Request is captured from the search file in the repeater, and here in file feed, a .jpg file is available. Now, I had removed the file and entered a third party URL on file Redirected URL: https://www.expressvpn
POC 3: Once I click on Go to capture response, the response is changed to expessvpn.com and you can see the IP of the testphp.vulnweb.com.
POC 4: But in the render page, you can see the expressvpn.com site getting loaded that confirms the SSRF attack as shown below:
Prevention From SSRF Attack
- Proper Whitelisting of IP address and DNS resolution
Follow a whitelist approach of all the application needed and trusted IP addresses and DNS names in order to avoid Server-Side Request Forgery attack. If a whitelist approach does not suits for your application then follow a blacklist approach.
- Validate and Sanitize User Inputs
Never trust and accept the user supplied inputs blindly into the application. The Application should validate and sanitize user given inputs to avoid SSRF attack. (E.g. do not allow a request to private IP (non-routable) addresses and internal services (as detailed in RFC 1918).
- Implement Proper Error Handling mechanisms
Create and use a customized error page (that does reveal any information about the application) to all the users when an error occurs. An unhandled error response might end up in revealing sensitive information or data leakage about the server to the attacker, when any other raw response or different parameter is used.
- Disable unused URL schemas
URL schemes other than HTTP and HTTPS should be blacklisted. Instead, these two mentioned protocols should be whitelisted thereby blocking different schemes which are not in use like file:///, direct://, feed://, touch://, and FTP://, which might prove to be dangerous for SSRF.
- Implement Next-Generation-Firewall
Implement a Next-Generation Firewall with a powerful and latest rule set that will block most of the web based attacks and provides a maximum security (Note: Remember Firewall is also a product is not a permanent solution to cyber threats, it is added advantage to the application that gives some extra protection).
- Implement Authentication on Internal Services
By default, services such as Memcached, Redis, Elasticsearch, and MongoDB do not require authentication. An attacker can use Server Side Request Forgery vulnerabilities to access some of these services without any authentication. Therefore, to ensure web application security, it’s best to enable authentication wherever possible, even for services on the local network.
CONCLUSION
Hackerone explains about the SSRF in more detail. Server-Side Request Forgery is an extremely lucrative vulnerability among the hackers, especially when your business infrastructure is on the cloud. It is hard to completely remove a vulnerability such as SSRF but it is better and best to mitigate the effects of exploitation by following all the necessary best practices and remediation measures such as OWASP cheatsheet etc.
Security is a shared responsibility it is also good to consult or get guidance from a Cyber Security Solution Provider to get your business in a right path.
How Briskinfosec helps you?
To practically educate about these issues and to provide contemporary security quality, a competent cybersecurity firm is mandatory. Briskinfosec security professionals validate the input parameters of the incoming requests through effective security assessments. We scrutinize them and encumber those, if detected vulnerable. We also deliver you, noble notions of cyber awareness against both old and latest cyber threats, educating you to be cautious against such possible threats.
Curious to read our Case studies?
Our case studies are one of the best totems of our security assessments quality. Our clients have always felt contented with our security assessments quality as we’ve always met their security requirements on time, with zero compromises. We have a vast collection of case studies, just take a look at them.
Last but not the least
People check out for the recent and significant cyberattacks, to gain knowledge and sometimes, to check the affected companies. For doing so, they’ve got to search spotlessly and at some point of time, they feel tiresome. But, Briskinfosec provides you an easy way to acknowledge the recent and significant cyberattacks, the impacts of them on respective organizations, the losses faced by them and all these are done in just one single report named as Threatsploit Adversary Report. Check them out and they’ll surely be fulfilling.
You may be interested on
- Techniques to Secure your SOAP and REST API
- Future is Cryptocurrency Era
- Guidelines to Secure Web Services and API End Points
- How To Secure Yor GitHub Repo
- Cross-Site-Port Attack (XSPA)