CTF_WRITEUPS-TryHackMe-CVE-2021-41773-

CTF_WRITEUPS/TryHackMe /CVE-2021-41773/

CVE-2021-41773/42013

A small explanation of an Apache path traversal bug and an incomplete fix

Task 1: A Bit of Background...

A Brief History

On the 5th of October 2021, a CVE detailing a path traversal attack on Apache HTTP Server v2.4.49 was released. Assigned the number CVE-2021-41773, it was released with the following description:

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 (sic) 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.

Let's break this down and see what this actually means for us:

• From the first bit, we see that a recent change that exposed the flaw. Path normalization means that we transform a given path to some canonical form that the software can understand, and thus map to the actual filesystem. This already leads us to suspect a path traversal attack that can potentially read unintended files.
• The next part confirms our suspicions, and we are able to use a path traversal attack to read resources outside the intended scope.
• We see that we require a very particular configuration to be set. Files outside the document root must explicitly be granted permissions. This is not the default configuration and should thus render this exploit useless against a large percentage of the Apache hosts (thankfully).
• The next part talks about CGI scripts, which erroneously leads us to believe that CGI may need to be enabled for this attack to work or that the path involves CGI in some way.
• Even if our configuration is not directly affected by this bug, we'll still want to update the vulnerable versions ASAP.

Much Fixing Later...

So Apache fixed this bug and released v2.4.50. End of story, right? Well, not quite. Only 2 days later, on the 7th of October, a new CVE was released citing the prior. This one mentions that the fix for the earlier path traversal attack was incomplete, and we could still traverse if the path in question used an alias directive to map its URLs to the filesystem. The CVE was assigned number CVE-2021-42013, with the description as follows:

It was found that the fix for CVE-2021-41773 in Apache HTTP Server 2.4.50 was insufficient. An attacker could use a path traversal attack to map URLs to files outside the directories configured by Alias-like directives. If files outside of these directories are not protected by the usual default configuration "require all denied", these requests can succeed. If CGI scripts are also enabled for these aliased pathes (sic), this could allow for remote code execution. This issue only affects Apache 2.4.49 and Apache 2.4.50 and not earlier versions.

Much as before, we can learn a few things here:

• While the first exploit was supposedly fixed, there is another input for allowing the traversal to work (remember this for later).
• Now we're being limited to aliased path directives.
• Directories outside the usual paths still require explicit permissions to be granted.
• If CGI is enabled, then we can get RCE in addition to simple disclosure 😲

While we process this madness, we'll look into the required configuration in the next task.

Answer the questions below

1. What version of Apache httpd was initially vulnerable to this CVE?

• 2.4.49

2. This vulnerability requires an unusual misconfiguration for it to be exploitable (Yea/Nay)

• Yea

---

Task 2 What is Path Traversal anyways?

A Smidgen of Theory

A Path Traversal exploit is an attack that aims to access resources that are normally inaccessible by abusing flaws in path resolution and/or normalization. We'd usually exploit this type of attack by traveling (also known as traversing) backwards beyond the supposed root using the .. syntax.

Normalization? What?

Normally, when providing a path for some code to find a file, an absolute path is necessary. Let's call this the canonical path. When a relative path is instead given, it must be normalized to a canonical form so that the OS libraries which use that path can then find the resource in question. This is an oversimplification, of course, but the gist remains.

In general, there exist platform libraries to do this normalization for us, but in C/C++ we usually get to do everything ourselves. While this can offer some flexibility, it can also easily introduce flaws if our implementation isn't perfect.

Normalizing URLs

An HTTP server has to translate a URL into a canonical path on the file system in order to find the correct file to serve. While there are definitely some filters in place to avoid being able to traverse beyond the document root, some use cases may easily be missed. In this case, the exploit takes advantage not only of URL encoding (we'll get to that in a bit) but also a flaw in the path normalization of the Alias module (supposedly)

An Aside on URL Encoding

Defined in RFC 3986 Section 2, URL Encoding is a scheme used to encode special or reserved characters within a URL. For example, spaces in a URL are encoded as a + character (notably in query parameters). If we want to encode an actual plus, we must encode it using what is known a "percent-encoding". This simply involves prefixing the US-ASCII hexadecimal code for the character with a % sign. In our example, the + symbol can be encoded as %2B.

Any character can be URL-encoded, and URLs which are fully URL-encoded are functionally equivalent to the non-encoded version. From the RFC: If two URIs differ only in the case of hexadecimal digits used in percent-encoded octets, they are equivalent.

So What Happened with Apache?

A recent change in the path normalization module in the Apache server then allowed a specially crafted URL to bypass the filters and traverse beyond the document root, allowing arbitrary file read on the system if the configuration allowed it. Furthermore, if the CGI module was enabled, then arbitrary file execution is also possible!

Answer the questions below

1. A path traversal exploit will (choose the best answer):

A) Include arbitrary remote files to be processed on the server. B) Include arbitrary local files to be processed on the server. C) Allow arbitrary files to be exposed by the server. D) None of the above.

• C

2. URL-encode the . symbol

• %2E

3. What does this URL fragment decode to: %%32%65 ?

• %2E

---

Task 3 Ok, Ok; Gib Hax!

Hacking Apache for Fun

So now that the theory is over, let's get to exploiting this flaw. Firstly, we need a vulnerable version of Apache. Thankfully we have docker for this :)

user@machine$ docker pull httpd:2.4.49
2.4.49: Pulling from library/httpd
07aded7c29c6: Already exists
05bb40c8f148: Already exists
0827b74117da: Already exists
35a526fdcc7d: Pull complete
59fed288cd32: Pull complete
Digest: sha256:dcba0d12e2362fb0c50ec524ae8aa1cca4a4ba7216617a57e7bbca20767e79cc
Status: Downloaded newer image for httpd:2.4.49
docker.io/library/httpd:2.4.49

Configuration

For this exploit to work, we need to configure Apache to allow access to files outside the document root. We can be precise and specify a given directory, or we can go the YOLO route and give access to everything. For our purposes, everything will do nicely. To begin, let's run our container and poke at the configuration. Note that these modifications work for both vulnerable versions of Apache.

user@machine$ docker run --name vuln-httpd -p 8080:80 -d httpd:2.4.49
a4dfc0376d93dc62183982a527b0bef62543e7a91178116bb0480a42ecc0c8dd