CTF Writeup: tryhackme.com LazyAdmin
This is a write up of the LazyAdmin CTF at tryhackme.com. You can find the room here. Based on the name, it’s a safe bet that the “admin” is lazy. Therefore we may want to be on the lookout for outdated or unpatched software with a known vulnerability, weak passwords, or default credentials; as these are all hallmarks of a lazy admin.
After connecting to the tryhackme.com network over openvpn and starting up the machine, we are ready to go. Let’s ping the machine to verify our connection:
Starting out, we know nothing about the machine or what is running on it. Let’s begin with an nmap scan to see what services are running. We’ll tee that out to a file for later reference:
From the scan we can see that this machine is running an ssh server and a web server. The web server is running Apache with the default page. Let’s visit the page in our browser:
We get the default page, confirming the results of the nmap scan. There isn’t anything terribly interesting so far. Let’s brute force directories using gobuster and tee the results out to a log again for future reference:
It looks like there is a directory called content which we can access. Let’s see what’s there:
We’re presented with an “under construction” page for some type of content management system called SweetRice. Now we at least have something for which we could search for known vulnerabilites. It would be very hepful however if we could find a version number. There is a link on the page that takes us to the SweetRice website called “Tip for Basic CMS SweetRice installed”. Following the link takes us here. Looking over it quick, there is a reference to a “/inc” directory where it states that important information is stored. There was no “/inc” directory in our gobuster scan, so let’s do another gobuster scan of the /content directory”. To do so, we can just tack /content onto the end of the url:
Now the /inc directory shows up. I spent some time puttering around through these directories until I found something that might be a version number located in a file at /content/inc/lastest.txt. Perhaps this is a mispelling of “latest”?
Opening it, we are presented simply with the text “1.5.1”, which could be a version number. Maybe? With that in hand, let’s check exploit-db for any CVEs:
It turns out that 1.5.1 is a valid version number for SweetRice. There are 5 CVE’s for this version. One is an arbitrary file upload, which seems to be the most promising. There is a exploit already available in the form of a python script, but inspecting the code it appears to require authentication first. We don’t have any credentials at the moment, but let’s hold on to that in case we come across any.
Taking a look at the Backup Disclosure, we see that this version of SweetRice also has something called “mysql bakup” that can be downloaded from /content/inc/mysql_bakup. Let’s go see what’s there:
Sure enough there is a mysql script called mysql_bakup_20191129023059-1.5.1.sql. This confirms our version number again. Let’s go ahead and grab that:
Opening it up in a text editor and scanning though, there appears to be some credentials with a username of “manager” and a hashed password:
Let’s toss that hash into hash-id.py, which you can grab here.
Looks like md5. Knowing that, let’s try to crack it using john the ripper and the rockyou password list. Here, I’ve saved the hash from the sql script into a file called sqlhash:
Just like that we have the password (it’s been blacked out in the above image). There is just one problem. We haven’t actually found a login page yet. Let’s look for one. Revisiting our gobuster scan of the /content directory, we see that there is a directory /content/as. Here is our login page:
Let’s try those credentials we found. They allow us to succesfully login and we are greeted with an admin panel.
Great. Now that we’ve authenticated, we will attempt to use the arbitrary file upload python exploit that we got earlier to upload a php reverse shell script to the server and gain access. Let’s open it in a text editor to see how it works.
It looks like it does not accept command line arguments and instead prompts us for the information, which includes an IP address, username, password, and the file that we wish to upload. So, before we run this, we will need a reverse shell payload. I grabbed the one from here and pasted into a text editor, changing the IP address to the machine o which I will set up a netcat listener on port 8080:
Now we save that as php_reverse_shell.php5 (or whatever you want). Then we can run the python exploit script, passing in our victim IP, username, password, and payload:
The script informs us that the upload was a success and that our payload is now at /content/attachment/php_reverse_shell.php5. Let’s verify:
Great, it has indeed been uploaded. Now all we need to do is initialize a netcat listener on port 8080 on our machine:
Then click on that link to our uploaded script. Upon doing so, we should see a connection on our listener:
Now let’s look for that user flag. Checking /home we see that there is one regular user on the system named “itguy”. Let’s see if they have the flag in their home directory:
There is it. We can cat it out and there is our user flag:
Now let’s see if we can escalate our privileges to root and get the root flag. First, let’s see what commands we can run as root:
It appears that itguy can run a perl script located in his home directory as root. Let’s see what that script does.
It looks like it executes a bash script /etc/copy.sh. Ok, what does that do?
It appears to send a reverse shell to a machine at IP address 192.168.0.190. Not only that, it is writable and executable for everyone. Looks like our work has already been done for us. Let’s change that IP address to our own machine. Here I just cat the file out, copy it and echo it back into the file, replacing the IP address with my own:
Now if we run backup.pl, it will execute /etc/copy.sh and connect back to a listener on our machine. Let’s set up that listener now:
Finally, we will run the backup.pl script using sudo:
Checking back on our listener, we now have a reverse shell as root!
Let’s get that flag:
That’s it. We’ve fully compromised this machine. In order to prevent this, the administrator should have updated the CMS, assuming an update was available. The admin should also have changed the password to something stronger and more resistant to cracking. Finally, having a reverse shell script easily executed with sudo priviliges was certainly a mistake. It was also bizarre because it was unclear what its purpose was to begin with.
Anyway, this was a fun CTF. It was fairly easy, yet not so easy as to be trivial. I hope to do some more of these CTFs in the future.