[SANS ISC] Apache 2.4.49 Directory Traversal Vulnerability (CVE-2021-41773), (Wed, Oct 6th)

The Apache Software Foundation yesterday released version 2.4.50 of its flagship Apache webserver [1]. This release fixes an easily exploited directory traversal vulnerability.

BLOF: This directory traversal vulnerability only affects a specific Apache version, 2.4.49, which was downloadable after September 15th 2021 from the apache.org website. It is not included in any Linux distributions. The vulnerability can be used to read arbitrary files from the server as long as the user the webserver is running as has read access. Code execution may be possible if mod_cgi is enabled and configured. Windows is vulnerable just like Linux.

Web servers typically define a “Document Root” or “WebRoot.” All URLs are translated to files inside that directory. If your “Document Root” is “/html,” and a user accesses “example.com/index.html,” the webserver will translate this URI to “/html/index.html.” Directory traversal is a well-known problem. A user could specify “example.com/../etc/passwd” to retrieve the “/etc/passwd” file. And web servers have taken care of this with some success ever since early humans created web servers.

One reoccurring issue has been URL encoding. It is wonderful (and somewhat common) to encode characters in a URL using URL encoding. Instead of the character itself, the hexadecimal ASCII code is used and prefixed with a ‘%’ sign. For example, %2e will be interpreted as a ‘.’. 

In Apache 2.4.49, code to normalize and validate the URL was “simplified.” Likely, this caused the directory traversal issue to “sneak in.” Can’t blame the developers too much for it. It looks like the affected “util.c” file was last significantly updated in 1996, according to the header. That was around the last time I seriously touched C. So I am not qualified to blame anybody for this mistake. But using my limited C powers, this looks like the important section:

if (path[l + 1] == ‘.’ && IS_SLASH_OR_NUL(path[l + 2])) {
  /* Wind w back to remove the previous segment */
  if (w > 1) {
    do {
      w–;
    } while (w && !IS_SLASH(path[w – 1]));
  }
  else {
    /* Already at root, ignore and return a failure
     * if asked to.
     */
  if (flags & AP_NORMALIZE_NOT_ABOVE_ROOT) {
    ret = 0;
  }
}

/* Move l forward to the next segment */
l += 2;
if (path[l]) {
  l++;
}
continue;
}

Mostly showing this here to demonstrate that it isn’t that easy.

The end effect: As long as a “.” was URL encoded, it was not recognized as a. “,” and we got good old directory traversal back.

With this vulnerability, an attacker can read arbitrary files as long as the webserver has read access to the respective file. The vulnerability is easy enough to exploit and is already widely exploited. An attacker will typically first try to look for /etc/passwd on Unix systems. /etc/passwd is always present and readable (unless you have some additional restrictions enabled around it). The attacker will verify the vulnerability and figure out how many “..” are needed to get to the file system root.

A typical exploit attempt will look like this:

“GET /.%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd HTTP/1.1”

Now the big question: Can you do RCE by prefixing the URL with “cgi-bin.” This would be similar to the exploitation of a similar IIS 4/5 vulnerability [2]. 

The simple answer: yes… if mod-cgi is enabled. In this case, a URL prefixed with “/cgi-bin/” (or whatever directory is defined for mod_cgi) leads to code execution. For example:

curl –data “echo;id” ‘http://127.0.0.1/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh

(based on Twitter/snyff)

So what do you need to do?

Make sure you are not running Apache 2.4.49. Apache 2.4.49 was released on September 15th, 2021, and is not included in any Linux distribution I am aware of. You may be running this version if you download the Apache webserver directory from apache.org.
Double-check by attempting the exploit string shown above.
Maybe add some WAF rules for it if you feel like it.

 

[1] https://httpd.apache.org/security/vulnerabilities_24.html
[2] https://www.kb.cert.org/vuls/id/111677


Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Source: Read More (SANS Internet Storm Center, InfoCON: green)

You might be interested in …

[SecurityWeek] Glass and Metal Packaging Giant Ardagh Group Discloses Cyberattack

All posts, Security Week

Glass and metal packaging giant Ardagh Group this week disclosed a cyberattack that forced it to shut down certain systems and applications. The Luxembourg-based company, one of the largest producers of glass and metal packaging products, says it was able to safely continue operations at its facilities despite the incident. read more Source: Read More […]

Read More

[SANS ISC] Video: Cobalt Strike & DNS – Part 1, (Sun, May 30th)

All posts, Sans-ISC

One of the Cobalt Strike servers reported by Brad Duncan also communicates over DNS. This can be tested with a simple DNS TXT query: The content of this TXT record contains the start of a Cobalt Strike beacon, encoded with Netbios Name encoding. I recently published an update to my base64dump.py tool to handle this […]

Read More

[SecurityWeek] Query.AI Launches With Security Investigations Platform, $4.6 Million Seed Funding

All posts, Security Week

Query.AI officially launched on Thursday with a security investigations platform and $4.6 million in seed funding. The funding came from ClearSky Security, DNX Ventures, and South Dakota Equity Partners, and Query.AI says it will be used to accelerate adoption of its product. read more Source: Read More (SecurityWeek RSS Feed)

Read More

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.