Mitigating OWASP Web Application Risk: Server Side Request Forgery (SSRF) using F5 Advanced WAF

Introduction

Server-Side Request Forgery (SSRF) is a type of vulnerability that allows an attacker to make arbitrary requests from a server to other internal or external resources. This attack exploits the trust that a server has in making HTTP requests to other systems, often bypassing firewalls or other security measures that restrict access to certain parts of a network.

How SSRF Works

In an SSRF attack, an attacker sends a crafted request to a vulnerable server, tricking it into sending a request to an internal or external resource on behalf of the attacker. The key factor in an SSRF attack is that the request is made by the server itself, which can lead to dangerous consequences depending on the server's configuration and what it has access to.

Types of SSRF Attacks

• Internal Network Access: The attacker might be able to use SSRF to access internal systems and services that are not exposed to the outside world. This can include databases, administration panels, or other internal endpoints.
• Bypassing Firewall/ACLs: SSRF can bypass firewalls and access control lists (ACLs) because the server might have fewer restrictions on outgoing requests, especially to local or internal IP addresses.
• Exploiting Services with Poor Security: Some services, like web servers or cloud services, may have weak configurations that could be exploited through SSRF. For example, SSRF could target metadata endpoints on cloud providers (e.g., AWS, Google Cloud) to retrieve sensitive configuration data like secret keys or instance metadata.
• Denial of Service (DoS): An attacker can use SSRF to overwhelm an internal service by sending many requests, effectively causing a denial of service.

Example:

Imagine an application that allows users to provide URLs for fetching data (like images or metadata). If the server does not properly validate or sanitize user input, an attacker can supply a URL pointing to an internal service that is not directly accessible from outside the server, like http://localhost/admin. The server, believing this is a legitimate request, might send the request internally, potentially leaking sensitive information or accessing restricted services.

 

 

 

 

Attack Demonstration and Mitigation:

For this attack demonstration, we will look at how we can retrieve sensitive metadata from an instance running on AWS using the SSRF attack. To perform this attack we are going to use the DVWA demo application, which is deployed in the same instance as the docker container. This application is added as a pool member to BIG-IP and can be accessed via a virtual server. For more information, refer to how to add pool member.

 

 

Login to BIG-IP console and navigate to Security > Application Security > Security Policies > and create an application policy with below configurations.

Enforcement mode: Blocking

Signature Staging: Enabled

Policy Building Learning Mode: Automatic

Virtual Server: < Virtual server on which dvwa application is accessible >

Other configs are set to default values

Note: Staging is enabled by default while creating the application security policy and the default staging period is 7 days. It can be tuned according to the customer’s requirements. For more information related to staging, refer to Attack Signatures & Staging

 

First navigate to the “File Inclusion” page of the DVWA application and next, if you take a close look at the URL, there is a query parameter called “page” which takes some path as input.

Now replace the query parameter value with AWS metadata server URL (http://169.254.169.254/latest/meta-data/) and send the request. As you can see, we are able to retrieve all the metadata of the instance which contains sensitive details like IP, OS info, etc.

Now let’s try to retrieve the public IP, region, ami-id, instance-type of the instance from the metadata. With these details, an attacker will be easily able to launch a DDOS attack on the application.

For the purpose of this demo, we've done the first test having staging enabled. Since staging is enabled and the staging period (by default 7 days) is not completed, Advanced WAF will be able to detect the malicious request but it won’t block the request. Only when the staging period gets completed, all the malicious requests that are detected will get blocked. For more information on staging and staging period, refer to Staging.

Let’s try to generate the attack again post the configured staging period, and as you can see below, Advanced WAF was able to detect and block the attack.

 

 

Conclusion:

This article covers the basics of SSRF attacks, its types, and a simple demonstration of this attack. We have also showcased how these attacks can be effectively mitigated by implementing robust application policies and enforcing relevant attack signatures through F5 BIG-IP Advanced WAF ensuring enhanced security against such vulnerabilities.

For further information, please refer to:

SSRF ATTACK-OWASP

Mitigating SSRF Attack Using F5 Distributed Cloud Platform