Preventing SSRF: Apache CVE-2021-40438 | Fastly

What you need to know:

• This vulnerability in Apache HTTP Server (httpd) version 2.4.48 can result in Server Side Request Forgery and can be exploited remotely if a specific module is enabled (mod_proxy).

• There is already a patch available in version 2.4.51 and cloud-hosted Apache HTTP server instances are safe (if relatively up to date).

• Our next-gen WAF customers are protected from this vulnerability by a templated rule.

CVE-2021-40438 is a Server Side Request Forgery (SSRF) vulnerability in Apache HTTP Server version 2.4.48 and earlier. By sending a specially crafted request, attackers can force the mod_proxy module (if enabled) to route connections to an origin server of their choice — thereby allowing attackers to exfiltrate secrets (like infrastructure metadata or keys) or access other internal servers (which may be less protected than externally facing ones). 

What’s the impact

This vulnerability impacts Apache HTTP Server (aka httpd) version 2.4.48 and versions earlier than 2.4.48. However, the mod_proxy module must be enabled for the server to be vulnerable — so attackers must find servers matching those specific conditions to exploit the vulnerability. 

Unfortunately, data from Shodan suggests that there are more than 500,000 servers matching this version, making it likely that attackers could find some fertile ground for leveraging this vulnerability in their attacks.

Why it’s interesting

As an attack method, SSRF (which we’ve written about before) gained popularity in the past few years, likely due to the compounding factors of its effectiveness, difficulty in detecting it, and an increase in vulnerable endpoints (the downside of software eating the world). SSRF’s rise to fame included making it into the OWASP Top 10 list and seizing the limelight in notable breaches. You can think of SSRF as enabling a kind of evil reverse proxy for attackers to use in their operations.

We also noticed a fair amount of users running cPanel on CentOS downgraded their Apache installations back to version 2.4.48 from the newer versions 2.4.49 and 2.4.50 due to another recent vulnerability in Apache HTTP Server, CVE-2021-41773. Unfortunately, this version downgrade means those users are now vulnerable to this attack; trading path traversal for SSRF isn’t the best deal. 

Yes, but…

While this is pretty bad for organizations running an older version of Apache HTTP Server, the most lucrative vector for attackers would be the cloud (more spoils for the victor). However, cloud providers, including Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP), have built in protections against this. 

Therefore, the impact of this vulnerability is likely limited to organizations operating httpd servers on their own. Organizations with self-hosted Apache HTTP Server instances should include any applications the Apache server can access (with GET requests) in the potential incident impact. 

Digging deeper

The mod_proxy module implements a proxy that can be used to redirect connections in Apache HTTP servers. It’s often used as a gateway to application servers, offering the typical benefits proxies provide (like load balancing). 

The relevant commit that fixes this issue is r1892814. On a patched Apache server, the code that parses the URL (the proxy destination) will only trigger if the unix: string is at the start of the proxy URL (as in [proxy:]unix:path|url). On an unpatched server, the parsing function would search through the whole URL provided by the user for unix:, rather than just looking at the beginning of the string.

It also seems that the attacker can control variables being passed to the ap_runtime_dir_relative function and, drawing from ancient C code wisdom, this introduces the possibility of buffer overflows or to send the function into unexpected states. Security and ops teams alike suffer any time there is a possibility of a crash or an attacker taking control, so this is a quite undesirable behavior.  

We can make this exploitation possibility reality by forcing the APR_PATH_MAX to return an error code due to maximum length (which is 7701 characters). You can execute the following command, in which we force the server to scream a prolonged 'AAAAA' into the void, to test this (credit to @_mattata):

curl "http://localhost/?unix:$(python3 -c 'print("A"*7701, end="")')|http://backend_server1:8080/"

For a step-by-step walkthrough on how to exploit this vulnerability, we recommend reading this blog post describing a proof of concept exploit.

What you should do

Anyone running Apache HTTP Server to 2.4.48 (or earlier) should patch their servers to version 2.4.51 and either disable your mod_proxy path or ensure it’s already disabled until you do patch.

If you’re a customer with an Apache HTTP server, you can follow the steps below to enable the new templated rule for CVE-2021-40438 to protect yourself.

If you are a customer of our next-gen WAF and running your Apache server in AWS, you can also enable the AWS SSRF templated rule to gain additional protection against all types of SSRF attacks specific to AWS.

Select Site and Site Rules -> Templated Rules

Navigate to the CVE-2021-40438, select it and select configure. Enable the rule to block requests from an IP.

Confirm the rule has been enabled on the templated rules page.