Every day, thousands of new vulnerabilities emerge, creating new opportunities for hackers. The bad guys don’t take breaks or vacations! They are actively working to compromise your systems.
The importance of staying ahead of the latest vulnerabilities cannot be emphasized enough in the ever-evolving threatscape. This time, we are going to discuss server-side request forgery vulnerability. Without further ado, let’s explore how SSRF works, how to uncover SSRF vulnerabilities in your applications, and what steps should be taken to prevent them.
What is Server-Side Request Forgery?
The vulnerability, officially called Server-Side Request Forgery (SSRF), is listed in the OWASP Top 10 as a major application security risk. Hackers of various sorts pounce on SSRF vulnerability to abuse server functionality and send arbitrary outbound requests from a server.
By encoding a URL, manipulating HTTP headers, and tampering with URL path traversal, threat actors can make unauthorized requests to a specific URL. SSRF vulnerabilities can lead to service disruption and, in some cases, total system takeover.
Types of Server-Side Request Forgery Attack
If you’re scratching your head, wondering what various SSRF attacks are, we’re here to help clarify things for you. Based on how the server responds to the initial request, there are three types of SSR:
Blind SSRF
Blind SSRF occurs when the host server does not return any visible data to cyber actors. Ransomware criminals aim to change or delete critical files, modify server settings, and adjust user or file permissions, rather than just steal specific data from the server. There’s nothing sent from the server to the fraudster, which makes it a demanding task to detect these attacks until the damage is done.
In general, blind SSRF is the hardest to exploit, yet it can lead to a denial of service (DoS) and full remote code execution on the server or other back-end components.
Semi-blind SSRF
In this scenario, the semi-blind instance does return partial data about a resulting request. As a result, the attacker gains access to certain secret data but not the complete set. This could encompass information such as error messages or response times. Semi-blind SSRF is often enough to validate the vulnerability but it doesn`t expose any sensitive data.
Non-blind SSRF
Non-blind SSRF is usually the most detrimental of all because data from an arbitrary URL can be fetched and returned to malicious entities who made the query. After a successful non-blind SSRF attack, malicious operators walk away with access to restricted network resources that will help them launch further attacks.
How Can Threat Actors Leverage SSRF?
SSRF vulnerabilities can occur in various software types, programming languages, and platforms as long as the software operates in a networked environment. Simply put, if attackers can control the server-side request destination, it opens the door for a plethora of security holes, potentially allowing them to:
- Bypass IP whitelisting
- Inject malicious HTTP requests into the target system
- Bypass firewall controls
- Perform Remote Code Execution (RCE)
- Pivot throughout corporate networks to exploit other vulnerabilities
- Hijack and reroute legitimate HTTP requests to an attacker-controlled server
- Scan networks linked to the vulnerable server, internal or external
- Read configuration files or sensitive data from the web server
- Initiate a DDoS (Distributed Denial of Service) attack by sending requests to external resources
- Access status pages and interact with APIs as the web server
- Retrieve sensitive information, such as passwords or API keys
- Abuse the trust between the vulnerable server and other systems
SSRF attacks are especially tricky because they’re often chained with other vulnerabilities. This combination allows attackers to establish a foothold on the server that serves as a foundation for further exploitation.
Often the main purpose of a SSRF attack is to steal a trove of documents or a database of company records. This can result in the loss of customer trust, decline in revenue, legal liabilities, and financial penalties.
How to Detect SSRF?
What exactly can we do to uncover this vulnerability? In the context of SSRF, the following steps should be taken to detect such vulnerabilities:
- Identify potential inputs for constructing URLs or initiating requests to external servers, such as GET or POST parameters and headers.
- Test each input by trying out a range of different URLs or IP addresses as inputs. This should include internal resources, localhost, and other special values.
- Examine how the application responds to diverse inputs, specifically looking for signs of SSRF vulnerabilities. Check for indications like the ability to access internal resources or extract data.
- Record any discovered vulnerabilities, detailing the input that caused the vulnerability, the kind of vulnerability, and its potential impact.
Real-life examples
Now that we got the basics of SSRFs down, let’s explore some incidents of such attacks that took place in real life.
Capital One
A good example of SSRF attack was when Capital One was hacked and the data of approximately 106 million people in the United States and Canada was leaked online. So, how did the breach play out?
The hacker managed to receive a response containing credentials due to a misconfiguration of the web application firewall. That enabled the hacker to connect with the server where Capital One stored its data and access customer files.
Microsoft Exchange
More recently, the Hafnium threat group was discovered infecting Microsoft Exchange Server email software. The 2021 Microsoft Exchange breach involved four vulnerabilities, but specifically, the SSRF vulnerability allowed malicious entities to authenticate as an Exchange server and execute remote code via PowerShell. It’s another example of how a compromised trusted source can escalate the attacks.
The group, operating out of China, targeted email systems used by 30,000 US law firms, higher education institutions, infectious disease researchers, policy think tanks, defense contractors, and non-governmental organizations.
Microsoft Azure`s Services
On January 17, 2023, security issues exposing Microsoft Azure`s Services to SSRF attacks were found. Two vulnerabilities didn’t require authentication, enabling threat actors to exploit them without an Azure account. Upon identifying vulnerabilities in Azure API Management, Azure Functions, Azure Machine Learning, and Azure Digital Twins, Microsoft promptly addressed and resolved the issues.
Fortunately, in that instance, additional input validation for the vulnerable URLs was implemented in a timely manner, and vulnerabilities did not cause any damage to Azure services or infrastructure. Yet, the company has really caught onto the risk of server-side request forgery attacks.
SSRF Prevention & Mitigation
Without the right preventive processes in place, the safety of your applications is a big question mark. As with most vulnerabilities, prevention is the best approach in squashing SSRF flaws.
- Perform input validation. Do not blindly trust the input — always verify its authenticity.
- Whitelist the domain names or IP addresses that your application needs to access. Minimize the attack surface. In internal networks, this usually means that a server should allow through requests containing URLs on a prespecified list and reject all other requests.
- Use URL encoding. Proper user input encoding and decoding is an additional defense-in-depth mechanism that mitigates the risk of malicious URLs being processed by the server.
- Perform penetration testing that includes a human element to exploit vulnerabilities. You can also use security testing tools to run simulation tests.
- Disable unused URL schemes. This approach is leveraged to allow only those URL schemes used by your application to make requests, and in turn, limit the attacker to make requests using potentially dangerous schemes such as file://, phar://, gopher://, data://, or dict://.
- Enforce the principle of least privilege where the system grants access only to authorized users.
- Segregate the network. By segmenting internal networks from external networks, you reduce the attack surface and make it harder for hackers to access internal systems.
- As a security best practice, mitigate misconfigurations.
- Educate employees on the risks associated with SSRF and ways of eliminating them.
- Document and learn from SSRF vulnerabilities you’ve discovered to improve testing procedures and prevent future occurrences.
- Regularly updating software provides an additional level of prevention.
Practicing prevention is indeed smarter than waiting for the hostile attackers to strike first.
How Can QAwerk Help?
Penetration testing is an essential step in the vulnerability management lifecycle aimed at enhancing security of your systems. With the help of penetration testers at QAwerk, you can beat off sophisticated threats with ease and speed.
We are here to search through your networks, servers, and applications to find, analyze, and report hacking vulnerabilities. Our skilled testers conduct black, gray, and white box pen testing to reveal security flaws. Leveraging our broad expertise, we can identify even the most elusive vulnerabilities.
Wrapping Up
SSRF vulnerabilities can appear unexpectedly, potentially jeopardizing your business’s security. To prevent that from happening, penetration testing should be performed regularly. It will give threat actors trying to breach your systems a harder time.
Penetration testing is a proactive process that does not deserve to be neglected. Keep that in mind and stay safe with QAwerk!
Increase your web app security now
