Mitigating OWASP Web Application Risk: SSRF Attack using F5 XC Platform
Introduction to SSRF attack:
In recent OWASP Web Application Top 10 report, SSRF is observed as one of the widely happening web application attack. Please refer to OWASP WebApp Top10 article for more details on Top 10 vulnerabilities.
This article demonstrates the SSRF attack and its mitigation technique using F5 Distributed Cloud platform. Server-Side Request Forgery (SSRF) attack is a technique which allows an attacker to manipulate the server-side application vulnerability and make a malicious request to the internal-only resources. These internal resources are not intended to be exposed to the outside world, instead they are used by the web application to fetch configurations such as Metadata, connect to internal databases and read the data, communicate with the peer web applications. Attacker exploits the web application by modifying/crafting a URL which forces the server to retrieve and disclose sensitive information from the internal servers which are not accessible from outside world.
Demonstration:
In this demonstration, we will see how to generate a simple SSRF attack and mitigate it using F5 Distributed Cloud (F5 XC) platform.
We are using:
- AWS instance with Docker
- DVWA vulnerable application installed as container to act as a target for the SSRF attack
- F5 Distributed Cloud (F5 XC) Platform for mitigation
Brief on SSRF attack scenario in AWS:
The AWS instance uses an internal web service to obtain its metadata i.e., instance specific information and this metadata service can be accessed only from the AWS instance. When EC2 instance requires any kind of metadata, it initiates a request to this service and the information gets served according to the request made. AWS uses 169.254.169.254 address to fetch the Instance metadata.
As shown in the above architecture, a vulnerable application is deployed in an AWS instance. Attackers can access the application and try to exploit this vulnerable application. This can be done by modifying or providing a URL that will initiate a request from the AWS instance to the internal web service and retrieve the sensitive metadata.
Step by Step process:
- Launch an EC2 instance.
- Deploy DVWA application in the instance and make sure the application is up and running.
- Configure HTTP load balancer in F5 XC without enabling WAF policy. Please follow below provided steps on how to configure F5 XC HTTP load balance.
- Access the backend vulnerable application using configured load balancer domain.
- Wait for the application to load and login to the application.
- Navigate to “File Inclusion” page in the application.
- In the URL, modify the value of query parameter ‘page’ to http://169.254.169.254/latest/meta-data/
- Observe that application page displays sensitive metadata of the EC2 instance.
The retrieved metadata will be displayed on the vulnerable application as below.
Configuration of HTTP Load balancer for mitigation of attack:
Step 1: Creation of Origin Pool
- From your desired namespace, navigate to Manage > Load Balancers > Origin pools.
- Click on "Add Origin Pool" and provide a name for Origin pool.
- Configure Origin server details with valid Port details.
Step 2: Configuration of Load Balancer with WAF enabled
- Navigate to Manage -> Load Balancers -> HTTP Load Balancers
- Click on "Add HTTP load balancer" and provide a name for the Load Balancer
- Provide valid domain name and choose appropriate load balancer type under Basic Configuration
- Associate the above created Origin Pool in the load balancer.
- Enable “Web Application Firewall” and create a WAF configuration with Blocking mode
- Click on Continue and observe that above created WAF configuration is being used.
- Click on “Save and Exit”.
Step 3: Access the vulnerable application and repeat the attack scenario.
- In browser, access the backend application using configured load balancer domain.
- Wait for the application to load and login to the application.
- Navigate to “File Inclusion” page in the application.
- In the URL, modify the value of query parameter ‘page’ to http://169.254.169.254/latest/meta-data/
- Observe that page cannot read metadata of the server and request gets blocked due to WAF policy.
Step 4: Validate logs and blocked request details
- Navigate to Virtual Hosts -> HTTP Load Balancers -> choose appropriate load balancer -> Security Monitoring -> Security events
- Observe that malicious request gets blocked due to applied WAF policy
- Expand the request and observe details about blocked request
Conclusion:
As you can see from the above demonstration, SSRF attacks can be mitigated by configuring a WAF policy in F5 Load balancer which automatically detects attack signature and block them.