SANS ISC: Apache 2.4.49 Directory Traversal Vulnerability (CVE-2021-41773) - SANS Internet Storm Center

• SANS Site Network
  • Current Site
  • SANS Internet Storm Center
  • Other SANS Sites Help
  • Graduate Degree Programs
  • Security Training
  • Security Certification
  • Security Awareness Training
  • Penetration Testing
  • Industrial Control Systems
  • Cyber Defense Foundations
  • DFIR
  • Software Security
  • Government OnSite Training

SANS ISC InfoSec Forums

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?

1. 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.
2. Double-check by attempting the exploit string shown above.
3. 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|