Active Exploits against CVE-2021-41773 (Apache Web Server Exploit)

The NOC platform offers its customers a global CDN / WAF. This technology runs on an anycast network that has points of presence around the world. This network design allows us to give our customers exceptional performance, but also gives us the ability to glean insights about what is happening on the web. Today we began seeing an increase attacks that are looking to exploit the newly released Apache Security Patch.

 

If you're unfamiliar, on October 6th, 2021, Apache released a patch for the Apache Web Server, version 2.4.5.1. This patch fixed issues identified in CVE-2021-41773 effecting Apache 2.4.50 and 2.4.49.

 

All NOC customers using our Web Application Firewall (WAF) were patched against this vulnerability by default.

 

This attack could potentially allow attackers to gain access to unprotected files on the server via a path traversal attack. NIST describes the issue as the following:

A flaw was found in a change made to path normalization in Apache HTTP Server 2.4.49. An attacker could use a path traversal attack to map URLs to files outside the expected document root. If files outside of the document root are not protected by "require all denied" these requests can succeed. Additionally this flaw could leak the source of interpreted files like CGI scripts. This issue is known to be exploited in the wild. This issue only affects Apache 2.4.49 and not earlier versions.

Over the past 48 hours we have seen an increase in the number of attacks to our network. Below you can see what the attackers are doing:

 

cdn-edge-europe-london1 88.168.206.87 400 129 - waf: 
08/Oct/2021:05:26:09 +0000 "GET /cgi-bin/.%2E/%2E%2E
/%2E%2E/%2E%2E/%2E%2E/%2E%2E/%2E%2E/%2E%2E/%2E%2E/etc/passwd 
HTTP/1.1" "-" "-"
cdn-edge-europe-london1 88.168.206.87 400 129 - waf: 
08/Oct/2021:05:26:35 +0000 "GET /cgi-bin/.%2E/%2E%2E
/%2E%2E/%2E%2E/%2E%2E/%2E%2E/%2E%2E/%2E%2E/%2E%2E/etc/passwd 
HTTP/1.1" "-" "-"

 

Each request demonstrates an attackers attempt to "access a file" outside of the webroot directory. In this instance, they are targeting the passwd file, which is where all the system usernames and passwords are stored.

 

If you're curious what this exploit is doing you have to understand that every %eE translates to ../. This is basic encoding using the HEX values.

 

So the you read the line like this:

 

cdn-edge-europe-london1 88.168.206.87 400 129 - waf: 
08/Oct/2021:05:26:35 +0000 "GET /cgi-bin/../../../ 
../../../../../../../../../../../../../../etc/passwd 
HTTP/1.1" "-" "-"

 

And if you're wondering, every "../" is going up a directory in Linux.

 

This example looks to be trying to leverage the Exploit DB example that talks to a Path Traversal and Remote Code Execution (RCE).

 

From a different perspective, here is a really cool thread on Twitter sharing what the attackers were doing post compromise by Tyler Hudak @SecShoggoth:

NOC-Twitter-TylerHudak

Attacks in The Wild

Below is an illustration of the attacks specifically targeting this CVE over the past 24 hours.

NOC-CVE-2021-41773

On the 7th we saw what looked to be some cursory recon attempts, then this morning it picked up exponentially.

Benefits of Cloud-based WAF Technology

There is never a better example of the benefits of cloud-based WAF technologies than vulnerabilities that can be exploited remotely via your web applications. Technologies like the ones we have built here at NOC offer organizations peace of mind when they need it most (i.e., when a new vulnerability is released, and exploits start).

 

Most modern organizations, including the hosts that you rely on, have a process for patching their web servers. For some, it can happen within hours, and for others it happens according to their change management process (which can take days, if not weeks, depending on the organization).

 

Cloud-based technologies, like the NOC WAF, allow an organization to virtually harden and virtually patch with no impact to product environments and no human interaction.

 

If your are running Apache, we encourage you to update to the latest version of Apache. Another possible hardening step is to deploy traditional "require all denied" configurations across any alias-like directives.