Oct 11, 2024 12:47:49 PM | application penetration testing Server-Side Request Forgery Attack & Fix

SSRF Attack We recently came across a privilege escalation attack avenue during a web application / thick client penetration test. In this blog post, I will be talking about a […]

SSRF Attack

We recently came across a privilege escalation attack avenue during a web application / thick client penetration test. In this blog post, I will be talking about a Server-Side Request Forgery attack that when discovered in certain situations could result in information disclosure leading to privilege escalations.

What is Server-Side Request Forgery?

“In a Server-Side Request Forgery (otherwise known as SSRF) attack, the attacker can abuse functionality on the server to read or update internal resources. The attacker can supply or modify a URL which the code running on the server will read or submit data, and by carefully selecting the URLs, the attacker may be able to read server configuration such as AWS metadata, connect to internal services like HTTP enabled databases or perform post requests towards internal services which are not intended to be exposed.”

According to OWASP

SSRF Discovery

SSRF can be discovered in multiple areas throughout applications. In this specific case, the web application had the functionality to export reports of data points within the application to a PDF. Early signs of potential SSRF were indicated by HTML being rendered within the PDF file. 

The following are some examples that indicated an injection within the PDF file:

Simple H1 HTML character rendering is shown in the SSRF example by white oak security.
Simple H1 HTML character rendering

THEN…

This screenshot shows the Masked link rendering by White Oak Security for Server-Side Request Forgery attacks
Masked link rendering

Escalation

With this engagement being part of Thick Client AND Web Application pentesting – I had access to the environment and the underlying filesystem to understand everything that was created and utilized by the application. There are numerous paths that could be attempted when trying to escalate privileges – which include loading cloud environment web pages, grabbing local files on the operating system, and potential remote code execution. A great resource for different attack avenues to try can be found here. 

In this particular case, there was a log file stored on the remote file system that would be beneficial to an attacker and as a proof-of-concept – the following SSRF request pulls the log file into the PDF generation:

Screen capture shows a log file stored on the remote file system that would be beneficial to an attacker and as a proof-of-concept - the following SSRF request pulls the log file into the PDF generation by White Oak Security's pentesters

With the successful rendering of the log file into the PDF file, an attacker can reveal the logging of web requests which contain cleartext passwords for an Administrator account that is logging into the application. Access to the Administrator account allows an attacker access to additional functionality within the application that would be considered sensitive.

SSRF Remediation

Simple guidelines to consider when trying to prevent Server-Side Request Forgery from occurring would be:

  • Sanitize user-supplied input
    • This is probably one of the easiest methods to start with. Sanitizing user-supplied input to prevent certain characters from execution / rendering would be a good start.
  • Create Allow List for network communication
    • Define which systems the application can talk to specifically to prevent exposure externally or access to systems internally.
  • Disable unused protocols and services
  • Deploy a Web Application Firewall (WAF)
    • Will not prevent all attacks but additional security layers will help.

SSRF Fix

This post reviewed a recent discovery of Server-Side Request Forgery during a Web Application / Thick Client penetration test. The discovery of SSRF can lead to a total compromise of an application and even the operating system. Corporations designing or developing their own applications should ensure that the OWASP Top 10 is followed to help prevent some of the most commonly found security issues nowadays.

 

Written By: Brett DeWall