Behind the Firewall: Bypassing AWS WAF’s SSRF Managed Rules
With over 49 million live websites, Amazon Web Services (AWS) hosts a staggering 6% of all sites on the internet.* While it’s challenging to know exactly how many of these utilize the AWS Web Application Firewall (WAF), the integration with key AWS offerings suggest that a significant majority likely employ this security measure. The AWS WAF is a service that defends against common and sophisticated web exploits, making it an essential component in the security infrastructure of many organisations, from burgeoning startups to Fortune 100 and Fortune 500 companies.
*Source: https://kinsta.com/aws-market-share/
In this blog post, I will be sharing the discovery of vulnerabilities that permitted the bypass of AWS WAF’s Managed SSRF Rules. This issue was responsibly reported to AWS, and it has now been fixed in AWS WAF version 1.10 of the Common Rule Set.
SSRF Attacks and their implication for AWS
Server-Side Request Forgery (SSRF) vulnerabilities allow attackers to abuse a server’s capability to access internal systems. Essentially, attackers use the server as a gateway to send requests to off-limits areas, potentially accessing sensitive data and operations within an organisation’s internal network.
Server-Side Request Forgery poses a particular threat in most cloud environments due to the presence of metadata services, which provides a gateway to sensitive internal data. The first version of the AWS Instance Metadata Service (IMDSv1) does not require a secret token, making it more susceptible to SSRF attacks. An attacker exploiting SSRF could illicitly query this service to obtain credentials and configuration details, leading to a potentially severe security breach. Despite the availability of IMDSv2, which requires a session token, the continued default use of IMDSv1 in many AWS setups remains a high-risk factor.
The vulnerabilities revealed in this blog post allowed attackers to circumvent AWS WAF’s SSRF-specific rules. Despite the WAF being in place, the bypass meant that applications vulnerable to SSRF attacks could still be tricked into making unauthorised requests to AWS’s internal metadata service. This gap in the WAF’s protection created a false sense of security among users, who might have assumed their applications were fully shielded from such exploits.
It is important to note that for an SSRF attack to be successful there must first be a vulnerable application or website that the attacker can exploit. This vulnerability arises when the application incorrectly processes user-supplied URLs, allowing the attacker to craft malicious requests. The prevalence of this vulnerability has earned it a spot on the OWASP Top 10.
Discovering the Vulnerability
While troubleshooting a problem caused by an AWS WAF’s SSRF rule (quickly flagged as a false positive), I found myself drawn into further exploration. After resolving the problem, I began to experiment with various ways of formatting IP addresses to test the rules. It was this security research that led to the discovery of the bypass. To confirm my findings, I used OWASP CloudGOAT, a purposely vulnerable web application, in a controlled environment.
Reporting to AWS
Upon finding and confirming the flaw, I adhered to an industry-accepted responsible disclosure process (see following section) and informed AWS on September 1st, 2023.
AWS responded within 3 hours (on a Friday afternoon!) committing to a review and a follow-up within five business days. True to their word, a few days later they confirmed that they were developing a fix and aimed to mitigate the vulnerability within a 90-day period. Throughout the process, AWS maintained clear communication, providing weekly updates on their progress. On November 3rd, 2023 AWS confirmed they had successfully rolled out the fix globally.
Zero Days and the importance of Responsible Disclosure
Responsible disclosure is when security flaws are reported privately, allowing companies to fix problems before they become publicly known. You may have heard the term zero-day: this refers to a security flaw in software that is unknown to the people who should be interested in fixing the vulnerability, like the software vendor. Since the vendor is unaware of the existence of the vulnerability, they have “zero days” to fix the issue or advise on mitigations before the flaw can potentially be exploited by attackers. These vulnerabilities are highly valuable to attackers because there is no known defence against them when they are first discovered, which can lead to widespread and unpreventable attacks until the vulnerability is patched.
Not All Responses Are Created Equal
In my experience with responsible disclosure, AWS’s handling of the vulnerability report was exceptional. I’ve reported security issues to various organisations in the past, and the responses have ranged widely. In one case, my disclosure was met with legal threats instead of cooperation (stay tuned for more details in a future blog post), a reminder that not every company is prepared to deal with such reports constructively.
I like to think of ethical hackers as the immune system of the internet, we find and fix security gaps before they turn into serious problems. Organisations should value and support these efforts, recognizing the crucial role good-faith security researchers play in maintaining a secure internet for all.
Acknowledgment
I would like to extend my gratitude to AWS for their quick and professional response. Their timely communication, consistent updates, and ultimately, the effective deployment of the fix, reflect their commitment to security and customer service. This experience reinforces the importance of collaboration between security researchers and organisations in creating a safer internet.
Technical Deep-Dive and IoCs
The following alternate formats for IP Addresses were ignored by the WAF rules, and allowed me to query the metadata service:
● 0xA9.0xFE.0xA9.0xFE
● 0251.0376.0251.0376
● 0251.00376.000251.0000376
● 0251.254.169.254
Logs should be queried for these patterns as they are Indicators of Compromise (IoCs). Any other sensitive internal IP addresses unique to your infrastructure should also be translated into the alternative formats and the resulting patterns queried in logs.
Note that I tested the EC2MetaDataSSRF_QUERYARGUMENTS rule, but AWS confirmed that the following rules were also affected by this vulnerability (these have also been fixed):
● EC2MetaDataSSRF_BODY
● EC2MetaDataSSRF_COOKIE
● EC2MetaDataSSRF_URIPATH
● EC2MetaDataSSRF_QUERYARGUMENTS
The following screenshot shows that the firewall rule acted as intended when using classic IP notation (169.254.169.254):
The logs show that the request was stopped by the AWS WAF’s Managed Rule:
Using the alternate IP Address formats (listed above) to query the IMDSv1 endpoint at /metadata/iam/security-credentials/XXXXX, we see that we can bypass the WAF rule and steal access keys. The log confirm that the request was allowed through:
