TryHackMe - LazyAdmin Room
Before I get into the room, there's a couple of things. It's November currently, which means NanoWrimo. I'm working on a TTRPG campaign and improving my DM-ing skills for this year's Nano, so I'm less focused on these rooms which is part of why this room took so long. But for those of you learning (like me), I want to clarify. This room was hard for me. It would have taken a few days for my brain to understand it without the additional distractions this month. I'll try to clarify some of the dead-ends I ran into and talk about them, but I do these based solely on my notes to improve my ability to document as well (an important part of the skill). With that said, let's move into the box.
This was TryHackMe's LazyAdmin Room. The premise here is that the administrator of the box was far too lazy to take basic security precautions. I think I may have done things a bit incorrectly, but follow me and see how I got in.
When we check the ip, we get a default Apache page.
As usual, we check the version info in the dev tools in our browser.
Alright, looks like the usual--Ubuntu running Apache 2. Given that we can't find anything else from this, it's time to move on from Recon.
Let's start with nmap.
That port 7512 is odd. It could be a glitch. It's blocked by a firewall at least, so let's see if there's anything that runs on that port.
No common software runs on that port. If it is anything, it's something we probably don't care about given the firewall. Let's move on to gobuster.
What's up with /real_estate?
Ok, that was just a legitimate error. Let's see what /content has to offer.
Hey! We found the website! Let's see what's at that link. Maybe this lazy admin didn't correctly configure security settings.
Let's see if we can access the /inc directory.
We sure can. In this file list I found something interesting, and there the rabbit hole begins.
Looks like there's a folder where one could backup the database. I bet that has usernames! I wonder if there's been a backup.
There sure has. Let's download this and take a look.
I wonder if there are passwords in here?
Sure enough, we have a username for the admin account: "manager" and a password in this backup. Now, I'm not going to take you down the rabbit hole I went down here, but I facepalmed when I realized that the password was hashed. Of course it was!
Once I found that out, it was just a matter of running hashcat.
and the results...
Well, that's definitely a lazy admin's password. Let's see if we can ssh in with these credentials.
Well, I suppose that would've been too easy eh? Let's run gobuster again and see if we can find any other subdirectories under /content.
This looks neat. The /attachment directory probably coincides with that attachment.php that we saw earlier. I guess this blog allows uploads. I wonder if that is our path to exploitation? We'll need to login though. What's this /as directory?
Haha! We found the login! Let's see if our credentials work.
Yup. We're in! Now here's another point I went down a rabbit hole. I had made a dumb mistake trying to setup a remote shell. I thought "huh, this doesn't work" and tried to find alternative methods to get in. Ultimately I found my mistake and fixed it, but in the meantime I learned a lot about how this app functions which was entirely unnecessary to complete the CTF. I tried connecting to the mysql server unsuccessfully. I turned on the blog (notice in the screenshot above). I fiddled with post creation...And ultimately that related to the remote shell that I eventually used.
You click on the post count and there, you can create a post.
When you create a post, you can upload an attachment. You just have to scroll down to the bottom where you can do that. Cool, let's create our reverse shell. We know this is a php server, so let's try the last payload on PayloadsAllTheThings https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Reverse%20Shell%20Cheatsheet.md#php
Now, what I forgot the first time was to convert this script so that it's actually a php webpage.
You'll notice that in my screenshot I used the .phtml extension instead of .php. That's because when I tried to upload the .php version, there was no error message, the server just didn't accept it and there was nothing at /contents/attachments.
Interestingly, in all my fiddling I did figure out that you didn't even have to create a post to do this. Just go to the create page and upload the attachment, then go to the attachments page.
Sweet, we can just click on it to trigger it, but first we need to listen on our machine.
Now we can click on our file and the server should try to process it as a webpage, thus activating our script.
Cool, what user are we?
Sweet. We're the server user. In order to su, we'll need to upgrade our shell. Let's follow the instructions at
https://blog.ropnop.com/upgrading-simple-shells-to-fully-interactive-ttys. For the record, I screwed this up a dozen or so times before I got it right enough to actually be able to use it. The shell was still a bit finicky, but it worked ok. One of the biggest tricks is that the default kali terminal is not running bash, so you have to start by running bash before you start netcat listening.
To reiterate the steps, you first run this script once the reverse shell works.
Then you should have a better terminal. You should then press CTRL+Z to background your netcat connected terminal and get back to your local shell. You use that to determine what values to fill in for later by running echo $TERM and stty -a. You will use that data later, so then we run the last few steps:
And with a proper shell, we can move on to the next phase.
I want to see what the admin's username is. Maybe he used that password from earlier, but with a different username.
Let's try logging in.
Hrmpf. No dice. Ok, so that's not going to work. I felt like I was supposed to login to the itguy account for a long time here, which also held me up. Ultimately, I did what we should always do first, and checked my sudo privileges.
We have sudo privileges to perl, but only for a specific perl script. Let's see what that script is.
It called another script, so I checked out that script as well. Interesting that he's running a system command. That looks like it might be running as root. I hunted around and found that the user flag is in itguy's folder, so I feel like I must've gone the wrong route with all of this, but meh, we get there in the end.
So looking at the second script, it's running netcat like we did. I wonder if we have write permissions.
We can't write to the backup.pl file, but this file our lazy admin clearly copied from another server has write permissions to everyone! Yay! Now this is why we needed an upgraded shell. Vim, vi, and other tools don't exist on this server. But nano does! So I edited the file with nano to change the ip address of the netcat to mine.
Now above I ran it too. I want to note that I ran it once before it changed by accident, which locked itguy out from editing /tmp/f so I couldn't run it with sudo -u itguy anymore. Since I had sensed it ran as root anyway, I tried that above after starting a local netcat listener on 5554. So once we did, it connected and...
As root user it was no problem to grab the flags. On to the next box!