Building an Incident Response Process for SSRF Attacks by Gilad David Maayan
What is Server-Side Request Forgery (SSRF)?
It is quite common for web applications to perform requests between HTTP servers, also known as server-to-server requests. These might be requests for remote resources, such as software updates, or requests for metadata from remote URLs or other web applications. If application developers do not implement server-to-server requests correctly, the server can be vulnerable to server-side request forgery (SSRF) attacks.
Server-side request forgery (SSRF) is an attack that allows an attacker to send malicious requests to another system through a vulnerable web server. SSRF is a new listing in the OWASP Top 10 for 2021. It is a severe vulnerability that can lead to information disclosure and open the door to more dangerous attacks.
Why is SSRF Dangerous?
Here are several ways SSRF attacks can impact a web application.
Data Exposure
Hackers use SSRF to query internal services that are only accessible through trusted servers. An attacker can exploit an SSRF vulnerability to bypass regular access restrictions and gain access to sensitive information.
Reconnaissance
It is a common security practice to minimize the number of public-facing servers to reduce the attack surface of external networks. However, even if only one or two servers are public-facing and the rest are behind your firewall, attackers can use SSRF to scan your internal network. These scans provide valuable information that can help attackers perform additional attacks.
Port Scans or Cross Site Port Attack (XSPA)
In some cases, attackers attempt an SSRF attack and see that the server returns no data. However, the attacker can observe response times or metadata to determine if a request was successful. Attackers can also perform port scans on a server’s internal network. These tactics make it possible to fingerprint services on the network and launch protocol smuggling attacks.
Denial-of-Service (DoS) Attacks
Internal servers are not designed to accept a large volume of requests and typically have less bandwidth configured. Hackers can use SSRF to send multiple requests to internal servers, depleting their bandwidth and triggering DoS attacks.
What Is Incident Response?
Incident response is an organizational process that enables timely response to security breaches. The purpose of incident response is to identify the attack, limit damages, and eradicate the incident’s root cause. Security incidents can be defined as violations of laws, policies, or unacceptable behavior related to organizational IT assets or data.
When organizations respond quickly to incidents, they can reduce losses, rapidly restore business processes and services, and mitigate exploited vulnerabilities. Events that an organization fails to effectively control can lead to data breaches with catastrophic consequences. Incident response is the first line of defense against security incidents and helps establish a set of best practices to prevent long-term breaches.
Incident Response Process for Web Application Security
Here is an incident response process you can use to secure web applications, based on guidelines from the NIST and SANS frameworks. In each of the incident response stages, I’ll show how to adapt your process to address SSRF attacks.
Prepare
To prepare for security threats, you should first perform an inventory of your organization’s web assets. Many organizations are not aware of all the websites and web-based resources they expose to the Internet. This involves several stages:
- Use an automated tool to perform asset discovery
- Identify assets that are not needed or not adequately maintained and shut them down
- Identify weakness or vulnerabilities in remaining assets
- Perform risk assessment to identify which of these vulnerabilities constitute a threat to critical business processes or applications
Preparing for SSRF attacks
The best way to prepare for SSRF attacks is to identify SSRF vulnerabilities in your websites and web applications and try to remediate them. There are two general approaches:
- If the server only needs to communicate with known applications, use a whitelist approach to check user input and only enable communication between the server and a list of known resources.
- If the server needs to communicate with unknown target servers, use a blacklist to block known malicious destinations. Because this is a risky scenario, position your server in an isolated network segment.
Detect
Put in place comprehensive logging and monitoring of web applications. This can help you detect suspicious events, such as multiple login attempts, or the creation of new user accounts. Using a security information and event management (SIEM) system will help you coordinate data from applications with data from security tools and other parts of the network. Another important way to detect threats is to scan for web application vulnerabilities on a daily basis.
Detecting SSRF attacks
SSRF attacks most commonly exploit:
- APIs like urllib.urlopen() and urllib.request.urlopen(). These APIs accept a URI as their input, and access a remote network destination specified by the user’s URI.
- Methods that accept user inputs such as GET and POST, where the user inputs include a URI.
To detect SSRF attacks, you’ll need to monitor these types of requests, and identify if they contain a URI. If they do, resolve the URI to an IP address, identify if the IP is local or remote, and check it against a blacklist or whitelist.
Dynamic application security testing (DAST) tools can automate this process, both at the development stage and when applications are already running in production.
Contain and Remediate
When you identify an attack on a web application, the first step is to triage and investigate the incident, identify how severe it is, and find a course of action to minimize damage. It is to contain the incident and prevent it from becoming a major security breach.
Once the threat is under control, you’ll need to remediate the underlying issue or put controls in place to prevent attackers from exploiting it. In addition, you’ll need to communicate the incident and its impact to internal stakeholders, and possibly to external bodies such as law enforcement or compliance authorities.
Containing and remediating SSRF attacks
There are two general approaches to remediating SSRF attacks:
- Modify the application to prevent attacks, for example by performing stricter validation of user inputs.
- If there is no way to fix the vulnerability, deploy a security solution that can block exploitation. One option is a Web Application Firewall (WAF), which can identify malicious requests that include remote URIs and block them.
Recover
After a security incident is over, you’ll need to recover systems to normal operations. If you isolated the web application or the server from the network, you need to bring it back online and ensure that users can access it as usual. Make sure that remediation actions or new security measures do not have an impact on normal user operations.
Recovering from SSRF attacks
An important part of SSRF recovery is to ensure attackers did not perform follow-on attacks. Perform threat hunting to identify if attackers compromised internal servers. Look for malicious traffic, such as communication with Command and Control (C&C) servers, from within your network.
If you have a record of attacker activity during the SSRF attack, identify which internal systems they scanned or retrieved data from, and verify that they are clean. Reset passwords and remediate vulnerabilities, if any, on these internal servers.
Conclusion
In this article I explained the basics of SSRF attacks and incident response, and presented an incident response process for web application security, with a special focus on SSRF:
- Prepare—create an inventory of public-facing websites and scan them for SSRF vulnerabilities.
- Detect—put in place tools to detect the use of URIs in user requests or server-to-server communication.
- Contain and Remediate—when you identify an SSRF attack, remediate the vulnerability at source or put in place a security system that can block exploitation.
- Recover—ensure that attackers did not infect internal servers and there is no malicious communication within the network.
I hope this will be of help as you develop a robust process for application security incident response.
ABOUT THE AUTHOR:
Gilad David Maayan is a technology writer who has worked with over 150 technology companies including SAP, Imperva, Samsung NEXT, NetApp and Ixia, producing technical and thought leadership content that elucidates technical solutions for developers and IT leadership. Today he heads Agile SEO, the leading marketing agency in the technology industry.
LinkedIn: https://www.linkedin.com/in/giladdavidmaayan/
Twitter: https://twitter.com/gilad_maayan
FB: https://www.facebook.com/gilad.maayan
