The Apache Software Foundation yesterday released version 2.4.50 of its flagship Apache webserver . This release fixes an easily exploited directory traversal vulnerability.
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:
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 .
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?
Oct 6th 2021
|Thread locked Subscribe||
Oct 6th 2021
2 months ago
An updated Fedora 34 server has Apache v2.4.9, at least the two I have checked both have it
Oct 7th 2021
1 month ago