Tomcat application arbitrary file read exploitation

Question

In recent black-box pen-test of a webapp hosted on CentOS, I found a vulnerability that allowed me to grab contents of files (kind of file inclusion) located within the home path of Tomcat.

In classic scenario, I tried to read /etc/passwd but failed to retrieve contents. It seems, Apache Tomcat forbids web server from reading outside of web app path. Vulnerable parameter located in GET request and application appends .jsp to that and tries to read it.

For example, if we navigate to http://site.com/abc.jsp?param=en then application will try to load /some/folder/somefile_en.jsp file from filesystem. If it fails, it returns HTTP status code 500 with java.io.IOException stack-trace.

For bypassing .jsp restriction, I added ? at the end of vulnerable parameter like this http://site.com/abc.jsp?param=asdasd_asdasd/../../../../META-INF/MANIFEST.MF?. I was only able to read these files:

• /META-INF/context.xml
• /META-INF/MANIFEST.MF
• /WEB-INF/web.xml

I do not know what other files I can read (because I do not have fuzz list for java apps).

Q: Could you give me fuzz list for finding other sensitive files in filesystem or could you suggest me other attack vectors?

P.S. I could enumerate file and directory names based on HTTP response. If file does not exist, this kind of error message appears:

Answer 1

The fact that you're already able to read from web.xml in the /WEB-INF/ directory should be more than enough to give you an idea of which other files you can read. The purpose of web.xml is to have path mappings for Tomcat to understand where to pull specific documents from, so you should be able to take advantage of those path mappings within web.xml to read additional files. Essentially, you should be able to parse the contents of web.xml in order to get the locations for Java source/.class files, and from there you should be able to include those via the bug, and decompile the java bytecode (if they're .class files that you're pulling from the web.xml mappings) in order to pull potentially sensitive data such as SQL/LDAP credentials.

If I'm doing a bad job at explaining this, check an old HackerOne report from my security team. We are exploiting a very similar bug in this instance, and we included the contents of web.xml, appended a ? to the end of the URL to prevent an extension from being added, and then wrote a script to parse the contents of web.xml to get the path mappings for various sensitive .class files containing java bytecode: https://hackerone.com/reports/413193

I'd suggest doing a directory bruteforce on /WEB-INF/CLASSES/* if you (for some reason) cannot pull the mappings for files from web.xml, although you should be able to do that no problem. Check our HackerOne report that I linked. It's a step-by-step guide of how we exploited an almost identical security flaw to what you are currently describing. If you find that report useful, be sure to thank Dominik Penner and Manny Mand, former members of a security group I operated which was responsible for finding those vulns (Dom aka zer0pwn and Manny found this, I'm just the guy who ran the group).

tl;dr - Essentially, this is a file disclosure bug but without the ability to traverse back to the root/home directories. You're limited to the directories you already mentioned, although these directories often contain java bytecode in the form of .class files, and such files often contain credentials for stuff like SQL or LDAP... so despite your directory traversal attempts being limited, you should be able to use web.xml to map out the paths for .class files containing bytecode, then if you're lucky you can include those files and grab potentially sensitive info after decompiling the bytecode.

Answer 2

Could you give me fuzz list for finding other sensitive files in filesystem ..

As you already mention, It seems, Apache Tomcat forbids web server from reading outside of web app path., and that's pretty common. You could probably try other default files of Tomcat as described in the fuzz list provided my SecList.

I'll mention some:

• /conf/server.xml/
• /WEB-INF/web.xml
• /manager/deploy?path=foo
• /webdav (check this)

Also, some useful articles to help you with LFI:

• Total OSCP Guide: Local File Inclusion
• LFI Cheat Sheet
• NetSec: File Inclusion

After that, and if possible, you should consider to look for the most common files of Linux distros, as described in this article.

.. or could you suggest me other attack vectors?

For Apache Tomcat you could try the latest CVEs that exists and for CentOS here, but you should really continue the information gathering, because, the OS and web server isn't a complete investigation (at least, it's a starting point, ¯\_(ツ)_/¯ ).

Be aware, that the information gathering in penetration testing is the most valuable step to continue further.