SSRF attacks can have serious consequences, such as unauthorized actions on third-party applications and remote command execution on vulnerable internal applications. Additionally, attackers can use SSRF to bypass network security measures such as firewalls and gain access to sensitive resources.
Detection techniques for pen-testing with different types of application scenarios
One of the most commonly used methods to detect SSRF vulnerabilities is to set up a dedicated server that can receive both DNS and HTTP requests. The idea is to identify requests made by the user-agent or originating from the IP address of the vulnerable application server. If the server receives a request from the application, it indicates that there might be an SSRF vulnerability present. This method can help in identifying SSRF attacks in real-time and is used extensively by security professionals and researchers.
Another method of detecting SSRF attacks is based on response timing. In such cases, the attacker learns whether or not a specific resource exists based on the time it takes to receive a response. If the response time is significantly different from what is expected, it may indicate that the attacker is trying to access a resource that does not exist or is not accessible.
URL/domain/path as a part query string or request body - One common scenario where SSRF can occur is when an application takes any URL, domain name, or file path as an input as part of the query string or request body, and the values of these parameters are used in backend processing. SSRF can happen when an attacker is able to control the input parameters and can inject malicious URL/domain/path. For instance, an attacker could use an image URL or a link URL as input in template generation, or use a file/directory path or an image URL in system/device configuration. In such cases, the attacker could trick the application into sending requests to internal resources or third-party services without the application's knowledge. The most common consequence of such attacks is unauthorized access to sensitive data or resources.
The Referrer header - This header can be manipulated by an attacker to exploit an SSRF vulnerability. If the application uses the referrer header for business logic or analytics purposes, the attacker can modify it to point to a target server they control. The vulnerable application will then make requests to the internal network, allowing them to potentially gain access to internal resources. This can also lead to data exfiltration or unauthorized actions on third-party applications.
PDF Rendering/Preview Functionality - If the application provides the ability to generate PDF files or preview their content based on user input data, there may be a risk of SSRF. This is because the application's code or libraries could render the user-supplied JavaScript content on the backend, potentially leading to SSRF vulnerabilities. Attackers could exploit this vulnerability by injecting a malicious URL or IP address in the PDF file or the preview content, resulting in unauthorized access to internal systems or sensitive data. Therefore, it's important for developers to thoroughly sanitize user input data and restrict access to internal resources to prevent SSRF attacks.
File uploads – If an application includes a file upload feature and the uploaded file is parsed or processed in any way, it may be vulnerable to SSRF attacks. This is because URLs or file paths embedded in uploaded files such as SVG, XML, or PDF files may be used to make unauthorized requests to external resources. Attackers can leverage this vulnerability to perform actions such as gaining unauthorized access to internal applications, leaking sensitive data, or executing commands on third-party applications through vulnerable application’s origin.
Bypassing Whitelisted Domain/URL/Path – An attacker can use various encoding mechanisms and supply malformed URL formats with binary characters for the localhost URL, including techniques like CIDR bypass, dot bypass, decimal/octal/hexadecimal bypass, and domain parser confusion, to evade an application's whitelisted URL/domain/file path configuration. This can allow the attacker to inject a malicious URL or domain name, potentially leading to an SSRF vulnerability.
Checking with different protocols/IP/Methods - An attacker may attempt to exploit an SSRF vulnerability by sending requests with different protocols (e.g. file, dict, sftp, gopher, LDAP, etc.), IP addresses, and HTTP methods (e.g. PUT, DELETE, etc.) to see if the application is vulnerable. For instance, an attacker may try to access internal resources using the file protocol, which can allow them to read files on the server or execute arbitrary code. Similarly, an attacker may try to access resources using less common protocols like dict or gopher, which are not typically used and may not be blocked by firewalls.
The upcoming section of the blog will delve deeper into the topic of SSRF exploitation in the context of cloud-based applications. We will also explore platform-oriented attacks on internal apps and examine various migration strategies to prevent SSRF attacks.
Article by Amish Shah