Server-side Request Forgery (SSRF) is a notable web security vulnerability that can be used by attackers to extract sensitive data from within an organization’s infrastructure. The threat of SSRF attacks remain significant given its addition to the 2021 OWASP Top 10 list.

On April 7th, 2022, API Security Company, Salt Security, identified an SSRF vulnerability in a digital platform of a US-based FinTech company that serves hundreds of banks and millions of customers. If exploited, the API vulnerability could lead to administrative account takeover, which can lead to further attacks such as privileged access to banking system, user banking details, personal data, and even unauthorized fund transfers.

Introduction

In 2021, Server-Side Request Forgery (SSRF), was a newly listed in the Open Web Application Security Project’s (OWASP) Top 10 critical security risks. Created in 2003, the OWASP Top 10 is primarily an Application Security awareness listing that has been used by many companies as a standard during web development.

SSRF has been employed in major cyberattacks, such as the Capital One data leakage that occurred in 2019. In this example, the attacker gained a set of AWS security keys through the exploitation of a SSRF vulnerability. This allowed the attacker to synchronize the S3 buckets to a local disk and obtain access to all data contained in them. This attack impacted about one hundred million individuals in the United States and six million in Canada.

SSRF vulnerabilities were also exploited in cyberattacks on Microsoft Exchange in 2021. In this incident, the SSRF vulnerability was targeted at the beginning of the attack for access and authentication of the Exchange server. The attackers then followed up by exploiting other vulnerabilities, such as a Microsoft Exchange Remote Code Execution (RCE) Vulnerability. This attack impacted an estimated 250,000 servers.

What is SSRF about?

SSRF a web security vulnerability that allows an attacker to induce the web application to make requests to a domain that the server has already been authenticated. This domain can be either internal or external, and can allow the attacker to bypass authentication, resulting in the attacker performing unauthorized actions, or gaining access to unauthorized data.

This vulnerability works on 2 main principles:

• SSRF is a GET based vulnerability, where a response for a user supplied URL is fetches via a HTTP GET request by the server.
• A lack of authentication at the Instance Metadata endpoint.

SSRF comes in two forms:

• For Basic SSRF, the targeted server returns data to the attacker. This is used when the attacker’s aim is to exfiltrate data or gain access to unauthorized features.
• For Blind SSRF, the targeted server does not return any data to the attacker. This is used when the attacker’s aim is to perform an action on the target server.

How is it executed?

In a SSRF attack against the server itself, the attacker induces the web application to send a HTTP request to the server that is hosting the application. This is done through supplying or modifying the URL. When the modified URL is sent to the server, the server responds and tries to read data as per the URL received.

Common targets include:

• Public IPs that distribute Cloud Server Instance metadata from Amazon Web Services (AWS), Microsoft Azure, Digital Ocean.
• Files can be read using file:// URLs.
• Database HTTP interfaces
• Internal REST interfaces
• Port Scanning

In AWS, the EC2 Instance Metadata Service (IMDS) is vulnerable to SSRF attacks. EC2 IMDS enables applications to have configuration and management capabilities. Instances and servers can be assigned roles, which allow them to access required services, and bypass the authentication required at startup. On a compromised server, an attacker can then impersonate the role, and forge a request to the targeted service, potentially obtaining sensitive information such as security credentials.

Example of SSRF

For example, consider a scenario whereby a shopping application lets the user view detailed item information. To provide the required information, the application will query the backend API using the product ID. This is done by passing an HTTP request from the web application to the backend API.

Example of a HTTP request from the web application to the API:

https://shopx.com/products?url=prodinfo.com?type=furniture&id=11

In this scenario, upon receiving the request, the API will find the details required and send the information to the web application, which will then be displayed to the user.

If the SSRF vulnerability is on the web application, the attacker can modify the URL for the following purposes:

• Obtaining Cloud Server Instance metadata

https://shopx.com/products?url=http://169.254.169.254/latestlmeta-data/iam/security-credentials/{role-name}

• Opening files

https://shopx.com/products?url=file://etc/passwd

• Accessing systems

https://shopx.com/products?url=127.0.0.1

• Port Scanning (by changing the port number and evaluating the response received, attacker can determine the ports and services running on a particular server)

https://shopx.com/products?url=192.168.1.100:21

Prevention of SSRF

A commonly used approach to preventing SSRF attacks is to restrict the system to only a select few protocols, such as HTTP or HTTPS, depending on company requirements. At the same time, unlike the above example, the web application should be configured such that an URL parameter should never be passed over.

Another commonly used approach in the prevention of SSRF is to utilize allow-list and deny-list. Allow-list, or white-listing, allows the web application to only access specified servers and objects. Deny-listing, or black-listing, denies the web application from accessing common hostnames such as the loopback address (127.0.0.1) or cloud metadata (169.254.169.254). Between the
two, allow-listing is preferable as it is more secure when compared to deny-listing, as the latter can be bypassed by attackers in a variety of manners, such as obfuscating the URLs.

In AWS, another method to prevent SSRF is to adopt IMDSv2. IMDSv2 addresses the 2 principles that allow SSRF to work, as a session token is now required for authentication purposes in the request sent. This token is generated by a PUT request from the server. This makes it harder for SSRF to be utilised, as the attacker would need to be able to control the server to make a PUT request instead of a GET request.

References

• https://salt.security/blog/api-threat-research-server-side-request-forgery-on-fintech-platform-enabled-administrative-account-takeover
• https://portswigger.net/web-security/ssrf
• https://owasp.org/www-community/attacks/Server_Side_Request_Forgery
• https://stackoverflow.com/questions/55096126/is-169-254-169-254-only-used-by-aws-ec2
• https://www.imperva.com/learn/application-security/server-side-request-forgery-ssrf/
• https://owasp.org/Top10/
• https://www.prplbx.com/resources/blog/what-is-ssrf/#:~:text=SSRF%20Impact,-If%20the%20user&text=Port%20scanning%3A%20A%20user%20can,%3A%2F%2F%2F%20protocol%20handler
• https://www.acunetix.com/blog/web-security-zone/defend-recent-attacks-microsoft-exchange/
• https://www.csoonline.com/article/3635894/ssrf-attacks-explained-and-how-to-defend-against-them.html
• https://blog.appsecco.com/server-side-request-forgery-ssrf-and-aws-ec2-instances-after-instance-meta-data-service-version-38fc1ba1a28a
• https://www.reblaze.com/blog/waf/defeating-ssrf-attacks-on-aws/
• https://cobalt.io/blog/a-pentesters-guide-to-server-side-request-forgery-ssrf