# Hacking Java-webapps for dummkopfs While PHP dominates the web development ecosystem, many competitors such as NodeJS, Ruby and Python have risen against it. One of the oldest competitors is Java, an enterprise grade OOP language, which can be run in many environments. Because of it's platform independent model and enterprise grade programming, it is used in many corporations and state driven projects as the language of choise. If you want to perform a run on Arasaka Inc. or any other megacorp, you need to know how to hack Java webapps. ## Java webapps for non-Java people Much like JAR files, Java webapps are contained in WAR files which contain all of the Java object code, static images, css, JSP pages and servlets. These WAR files can then be deployed on Java application servers, such as the popular Apache Tomcat or WildFly (previously known as JBoss). The application server handles the bootstrapping and parsing requests and forwards them to the code contained in the WAR archive. ### What's inside a WAR? In a nutshell, a WAR archive can be freeform, and there isn't an one standard place for different files. However, things that are usually in the WAR file are the directories WEB-INF and META-INF. These contain configuration files the application server, such as Tomcat uses to parse the archive and map the handlers. Example of a simple WAR file: .war/ WEB-INF/ ... web.xml ... struts-config.xml ... classes/ ... lib/ META-INF/ ... context.xml The WEB-INF can also contain precompiled classes (.class files) in a directory named "classes" and third party libraries in the directory called "lib". The most central file in the WEB-INF directory is the file called "web.xml". This configuration file contains basic information about the different settings, filters and servlets contained in the archive. The other important configuration file in WEB-INF is the struts-config.xml file which contains mappings of different requests (for example /hello) to different handlers (or servlets, such as com.company.application.class). It also has configuration to different login handlers, redirects and JavaBeans (more on that later). The META-INF directory may or may not exist in the WAR file. This directory usually contains a file called "context.xml" which is used to configure application wide settings, such as database connections, which can be used by any servlet as a datasource. This information can also reside in the application servers config directory, making the configuration options server wide and not just application wide. Static data, such as images and css can pretty much exist anywhere in the archive. ### Servlets, JSPs? Beans? Webapps written in Java usually try to emulate an OOP-approach to web development. While there are .jsp files, which can be thought as you basic .php files, mixing normal HTML with dynamic Java code, the salt of the application is servlets. Servlets are like normal Java classes, except that the take in HTTP requests and spit out HTTP responses. Usually they go even deeper and try to distinguish servlets which output HTML pages with the servlets that perform actions, such as database queries, with the virtual file extension of ".do". You can think of the .do files as getters and setters, if you know your OOP. Example mapping of servlets: index -> com.company.app.showIndex showNews.do -> com.company.app.getNews postNews.do -> com.company.app.postNews While the JSP pages are like php, mixing HTML with the actual serverside code, servlets usually use a library called JavaBeans. JavaBeans is a simple way to render, construct HTML code serverside,by telling it what you need, whether it is a HTML form or a static image. ## So how do we hack it? ### Application server A lot of information already exists of this, but I'll tell you the answer: You need to bruteforce the login, then upload your malicious backdoor WAR application. There is no silver bullet for this and you need to refer to the documentation of your application server. For example the Tomcat admin runs usually on port 8080, where you can try user/pass combinations such as: admin:admin admin:tomcat tomcat:tomcat tomcat:admin And so on an so forth. Metasploit has a modules for all of this. ### Servlets The most common (and destructive) Java webapp bugs in order are: 1. Access control 2. Local file/resource disclosure 3. SQL injection SQL injection is a bug that I won't be talking about in this article, as it is a common flaw and can be exploited in the same way as in PHP. ### Access control, or how I logged in as an admin While Java has it ways (JSESSID) to control logging in an out of an system, it's up to the developer to keep track of which parts of the webapp an user can and cannot enter. This can be either done in the servlets or as a filter which is applied in web.xml/struts-config.xml. Either way, you can never be too sure that the developer didn't leave something out. For example, if we see that the page: /adminPanel Is password protected, we should check and see if pages associated with it are. If you have the config files (more on that later), you can go and check every page for access control vulnerabilities. If not, you can generate a huge wordlist of blind tests, such as: adminDashboard adminDashboard.jsp adminDashboard.do userAdd userAdd.jsp userAdd.do And so on and so forth, and check if you can find anything interesting. One of the common mistakes developers make in this object oriented ecosystem is having access control in your basic servlets, but not your getters/setters (the .do mappings). If not, you can also test the found servlets for other vulnerabilities. ### Local file/resource disclosure This is a classic mistake, but in Java, it's so easy to make, especially on the resource side. If you see servlets like this: showPage.do?page=asd.jsp image.jsp?image=123.png userRegister?step=sendEmail.do You are bound to find one of these vulnerabilities. The difference between resource and file disclosure is that in a file disclosure, the code is using a filestream to open the file, meaning you can read any file there is, such as /etc/passwd. In a resource disclosure, the servlet is opening a resource inside of the WAR archive, and you are limited to browsing inside the archive. Try to use backhops like "../" and see what you find. Fimap may also work. #### File disclosure File disclosure is bad, real bad, if you know how to use it. In order to exploit it, you need to know the operating system/distribution the Java application is running on, because even in linux distributions, the system files may be kept in different directories. Try to: 1. Get system information: hostname, network configuration, anything in /proc/, bashrc... 2. Configuration files, sshd, apache, ftpd... 3. Password/gpg files, can be found using the configuration files 4. Log files, everything in /var/log/ You can find a lot of juicy information which will surely help you break into the megacorporation. #### Resource disclosure This one is a bit trickier, as you are limited to working in the current WAR file. Nevertheless, you can still find juicy information. Try to: 1. Get the configuration files WEB-INF/web.xml, WEB-INF/struts-config.xml 2. Possible database passwords in META-INF/context.xml 3. Static files, if you can find them These files contain information on how the webapp works from within and can contain useful information, such as FTP/database information, user accounts, test/debug servlets, logs and such. # More information Apache Tomcat documentation: https://tomcat.apache.org/tomcat-7.0-doc/ OWASP: https://www.owasp.org/index.php/Category:Java Metasploit: https://www.metasploit.com/ Fimap: http://www.fimap.com/ Google: https://google.com/