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

Path traversal/directory traversal the vulnerabilities allow malicious hackers to abuse user input to access files on the web server or application server and obtain sensitive information. The most common examples of directory traversal involve using a dot-dot-slash combination as a relative path to navigate 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’re not directly traversing directories on a server and leaving the web root, path traversal can still be dangerous. This is especially true for Java applications, as Principal Security Researcher Bogdan Calin demonstrated in Invicti’s latest technical article. 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 access to the file system is inherently more secure than, for example, that of a PHP application running on Apache. Since Java applications are typically 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 filesystem unless it is explicitly done in application code using absolute paths and a appropriate access control.

However, it’s easy to be caught off guard by this security-by-design feature of Java. Many developers assume that since you can’t access files in the underlying operating system, there’s no need to clean up code or use input validation to protect against potential attacks from path crossing. 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 knew what to look for. If you manage to access the root of the application context and access arbitrary files, you can exploit this Java path traversal vulnerability to access sensitive files in the application environment.

Finding sample 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 of these environments. If you are targeting Windows, you know that system.ini should always exist. Similarly, attackers targeting a Java application can search for a path traversal vulnerability by guessing the names and locations of potentially valuable files. These files can come 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. Although these files often contain no sensitive information on their own, they are a great starting point for escalation. Common targets also include files such as WEB-INF/web-jetty.xml. While these files aren’t part of every Java application, they come from popular components that many applications will use – in this case, 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 handy. For example, you can easily detect the Spring framework by looking at the class names in WEB-INF/web.xml – if they start with org.springframework, the application uses Spring. Once this is established, you can try accessing files such as WEB-INF/applicationContext.xml and WEB-INF/-servlet.xml and continue to search for sensitive information, such as referenced configuration files. In the case of Struts, you can obtain the same type of information from the WEB-INF/classes/struts.xml, WEB-INF/classes/default.propertiesand WEB-INF/struts-config.xml files.

Go deeper inside by decompiling and guessing

In addition to finding sensitive information such as logins and passwords of 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 to exploit the path traversal vulnerability to download compiled files using loop then simply decompile the classes using tools like Java Decompiler Project or Jadx. With decompiled classes, you can find sensitive parameter values ​​and imports from other classes. Repeat this to download more classes, decompile them – and keep going until you find something interesting, like a configuration file that contains sensitive data.

Another method attackers and testers can use is to simply blindly guess common filenames and filepaths based on the servlet name. This is possible because many developers will use the same file locations and extensions, such as .Properties, changing only the name of the file. For example, if you have a servlet named sampleit is worth checking for the existence of files such as sample.xml and sample.propertiesalso looking for them in common subdirectories such as configuration, conf, Classes, ResourcesWhere library.

Put yourself in the attacker’s seat

Of course, the most effective way to detect path traversal vulnerabilities in Java for mitigation purposes is to perform penetration testing and think like a hacker. However, as you can see, once you get to blindly guessing multiple path combinations, manually testing all the 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 these tedious activities. Our technical note is accompanied by a 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 testing for Java path traversal vulnerabilities in general, see the full technical document Exploiting Path Traversal Vulnerabilities in Java Web Applications.

The post office Path traversal in Java web applications – announcing the Invicti technical paper appeared first on Invicti.

*** This is a syndicated blog from the Security Bloggers Network of Invicti Written by Tomasz Andrzej Nidecki. Read the original post at: