Path traversal in Java web applications – announcing the Invicti technical paper

Path traversal/directory traversal vulnerabilities allow malicious hackers to abuse user input to access files on the web server or the application server and obtain sensitive information. The most common examples of directory traversal involve using a typical dot-dot-slash combination as a relative path to go first to the parent directory and then outside the web root directory. This can allow attackers to access operating system files and other data.

But even if you are not directly traversing directories on a server and not leaving the web root, path traversal can still be dangerous. This is especially true for Java applications, as demonstrated by Bogdan Calin, Principal Security Researcher, in the latest Invicti technical paper Exploiting path traversal vulnerabilities in Java web applications.

The two faces of Java file security

Due to their architecture, Java web applications have a significant security advantage: their file system access is inherently more secure than, say, that of a PHP application running on Apache. Since Java applications are usually packaged as servlets, the application treats the application context root as the only file system it can access. In most cases, there is simply no way for an attacker to reach the underlying file system unless this is explicitly done in application code by using absolute paths and suitable access control.

However, it is easy to be blindsided by this secure-by-design characteristic of Java. Many developers assume that since you cannot reach files in the underlying operating system, there is no need to sanitize code or use input validation to protect against potential path traversal attacks. In his research, Bogdan Calin shows that there are, in fact, many sensitive files that could fall prey to a path traversal attack if only the attacker knows what to look for. If you are able to get to the application context root and access arbitrary files, you can exploit that Java path traversal vulnerability to access sensitive files in the application environment.

Finding typical files for escalation

Attacks often start by trying well-known resources. An attacker targeting a Linux/UNIX system knows that the /etc/passwd file exists in all such environments. If you’re targeting Windows, you know that system.ini should always exist. By the same token, attackers targeting a Java application can check for a path traversal vulnerability by guessing the names and locations of potentially valuable files. These files can come either from Java itself or from common third-party components used by Java applications.

There are a few typical files that you can expect to find in most Java application servlets, the most common being WEB-INF/web.xml and META-INF/MANIFEST.MF. While these files often won’t hold any sensitive information on their own, they are an excellent starting point for escalation. Common targets also include files such as WEB-INF/web-jetty.xml. While such files are not part of every Java application, they come from popular components that many apps will use – in this instance, the Eclipse Jetty Java servlet container.

Another typical class of targets includes files specific to popular Java frameworks, such as Spring and Struts. This is where escalation comes in useful. For example, you can easily detect the Spring framework by looking at the names of classes in WEB-INF/web.xml – if they begin with org.springframework, the app uses Spring. Once this is established, you can try to access files such as WEB-INF/applicationContext.xml and WEB-INF/<servlet-name>-servlet.xml and keep looking for sensitive information, such as referenced configuration files. In the case of Struts, you can get the same kind of information from the WEB-INF/classes/struts.xml, WEB-INF/classes/default.properties, and WEB-INF/struts-config.xml files.

Getting deeper inside through decompiling and guessing

In addition to searching for sensitive information such as logins and passwords to other services, servers, or APIs, you can learn a lot by accessing the actual source code of a Java application. To do this, you can continue exploiting the path traversal vulnerability to download the compiled files using curl and then simply decompile classes using tools such as the Java Decompiler Project or Jadx. With the classes decompiled, you can look for sensitive parameter values and imports of other classes. Repeat this to download more classes, decompile them – and keep going until you find something interesting, such as a configuration file with sensitive data.

Yet another method that attackers and testers can use is simply blind-guessing common filenames and file paths based on the servlet name. This is possible because many developers will use the same locations and file extensions, such as .properties, changing only the filename. For example, if you have a servlet named sample, it’s worth checking for the existence of files such as sample.xml and sample.properties, also looking for them in common subdirectories such as config, conf, classes, resources, or lib.

Get into the attacker’s seat

Of course, the most effective way to detect path traversal vulnerabilities in Java for mitigation purposes is through penetration testing and thinking like a hacker. However, as you can see, once you get to blindly guessing multiple path combinations, manually testing all possibilities becomes very tedious and time-consuming.

As one of the original creators of the Acunetix by Invicti web vulnerability scanner, Bogdan Calin naturally prefers to build a tool to automate such tedious activities. Our technical paper is accompanied by an open-source testing tool developed by Bogdan that you can use in your penetration testing to automate directory traversal attacks on Java applications. To learn more about using the tool and about testing for Java path traversal vulnerabilities in general, see the full technical paper Exploiting path traversal vulnerabilities in Java web applications.