---

TryHackMe Challenge Link: https://tryhackme.com/room/yearoftherabbit

---

---

Year of the Rabbit is the second box I built; and was originally designed to accompany my workshop on CTF creation, first presented on the 11th of March 2020 to the UAD Ethical Hacking society. Now that Year of the Rabbit has been made public, I am also releasing this post as the official write-up.

Let’s get started!

---

Enumeration:

As always, we first need to perform some initial enumeration on the box. Get nmap up and we’ll see if there are any services open to us:

nmap -sV -p- -vv <remote-ip>

Looks like we’ve got a webserver running on port 80, SSH running on port 22 and an FTP server on port 21. Nothing out of the ordinary here. We would need credentials in order to attack SSH, so let’s leave this aside for now. That leaves the web and FTP servers; we’ll try an anonymous login to the FTP server first:

Nope.
Ah well, worth a shot.

Head over to the website to get an idea of what we’re dealing with here.

Just the default Apache2 landing page. Nothing we can do with the front-end, so let’s take a look at the source code:

At first glance this looks completely normal too, but there is something abnormal about it. The default landing page is usually entirely self-contained in that it has an inline stylesheet, rather than linking to an external stylesheet like this one does:

That, to me, indicates that there’s something “off” about this section. Click the link and take a look at assets/style.css:

Bingo. There’s something for us on /sup3r_s3cr3t_fl4g.php. A flag, perhaps?..

Sup3r_S3cr3t_Fl4g

Uh, no.
A message telling us to turn off our Javascript, followed by a redirection to a Rick Astley video.

Right, well, before we try that again, we’d better turn off Javascript. I’m using Firefox, so to do that I’m going to navigate to about:config then search for “javascript.” Where it says javascript.enabled I’m going to change the Value to “false”:

Other browsers have different ways of doing this, so you may need to search up how to do it for your own browser, or just use an extension to do it for you.

Right, we should now be safe to head back to /sup3r_s3cr3t_fl4g.php now:

*sigh*
Wonderful. Looks like we’re watching this then…

56 seconds in we’re given a hint in the audio:

“I’ll put you out of your misery **burp** you’re looking in the wrong place”

Yep, you read that right. We’re not even close to finding the flag.

On the plus side, that conspicuous burp in the middle of the audio sounds like it could be a clue. Perhaps Burpsuite?

If you’ve not used Burpsuite before, take a look at this post from TryHackMe on how to set it up. Otherwise get an instance of Burp up and running and let’s break this process down step by step. At this point you can also turn your Javascript back on.

Once you’ve got Burp set up to capture requests, let’s try heading back to the /sup3r_s3cr3t_fl4g.php page once again:

We get the request to the page we were expecting. Click “Forward” and see what comes next:

Aha! The redirect makes a stop at a page called /intermediary.php, with a parameter of hidden_directory. This looks like the way forward!

Kill Burp then head over to the hidden directory and let’s take a gander:

It’s indexable and contains only one file — an image: Hot_Babe.png

Click on it and we see that it’s the classic picture of Lena frequently used as a test image for processing techniques. Further enumeration is evidently required.

Lena

If I didn’t already know exactly where to go from here, I would probably spend some time messing around with binwalk to see if there was anything hidden in this image. As it is, I know that the solution is a lot simpler.

If you use strings or even cat on the file, you’ll notice that the last 80 odd lines are all the same length. On lines 1790 and 1791 there’s a message telling us that everything subsequent is a potential password for the FTP server, and that the username is “ftpuser.” In other words, we’ve been given a wordlist:

Let’s save that wordlist in a new file, then we can set Hydra at the FTP server:

sed -n '1792,$p' Hot_Babe.png > wordlist.txt

---

Exploitation:

FTP

Using Hydra:

hydra -l ftpuser -P <path-to-copied-wordlist> <remote-ip> ftp

Aaand we got it! We now have creds to login over FTP — let’s put ’em to good use!

Login with the creds that we found and you’ll see that there’s only one file in the directory:

Any attempts to escape the current directory fail, so we’d be as well downloading Eli's_Creds.txt and seeing what we can do with them:

Use exit to close the ftp connection then open up the file and let’s see what we’ve got:

That looks a lot like the esoteric language, Brainfuck. Copy the gibberish and put it into a brainfuck decoder:

And there we have it: credentials for a user called Eli. Let’s try ’em on SSH!

Eli

Success! We now have RCE as Eli. Of additional interest is the message that greeted us when we logged in: Root has left a message somewhere for a user called Gwendoline.

Regardless, it looks like we’re going to have to work for our User flag, as it’s not in Eli’s home directory:

A quick find search shows us that the flag is in Gwendoline’s home directory. The plot thickens.

Right then, we might as well get to work on the only clue we’ve got: the message from Root. He’s told us that there’s a message stored in a “leet s3cr3t hiding place,” that Gwendoline supposedly knows about. Let’s try to find it:

That looks promising. There’s a directory called “s3cr3t” at /usr/games/s3cr3t. Head over there and take a look:

Empty, at first glance, but a little perseverance goes a long way. There’s a hidden message in this directory:

The message is for Gwendoline only? Oops…

Oh the irony: the guy harping on about security forgets to restrict the permissions on the file. What a jerk.

Anyway, we’ve got Gwendoline’s password now, so let’s borrow her account and grab that flag!

---

Privilege Escalation:

We’ve migrated to Gwendoline’s account and grabbed the user flag. Now let’s go for root!

The first thing, as ever, that we’re going to check is whether we can run anything as sudo, using sudo -l:

Oh ho! Now that is interesting. We’re allowed to execute a single command with sudo as Gwendoline: specifically, we can use the vi text editor to open the user flag. Now, usually this would be an easy privesc — open the file using sudo vi then execute /bin/bash from inside the environment; hey presto, instant root shell.

In this instance, however, root is the only account we can’t run sudo as. Notice that instead of having (ALL, ALL) inside the brackets of who we can run commands as, we have (ALL, !root) meaning that we can’t use sudo as root, but we can use it as anyone else (eli, or www-data, for example).

Now, if it weren’t for one thing, that would be this path of privesc entirely down the gutter. Fortunately for us, there’s a vulnerability (CVE-2019-14287) in bash itself that allows us to get around this specific sudo configuration and execute the command as root regardless. White Source Software has a really good explanation of this vulnerability, but in summary, if you select a user with an id of -1, sudo can’t cope with it and just reverts back to 0 (i.e. the id of the root user). What this means is that, whilst we can’t execute commands as the user with id 0 (root), we can execute commands as any other user, including -1, which reverts back to root, thus bypassing the restriction. Now, the big question: is this box vulnerable?

sudo -u#-1 /usr/bin/vi /home/gwendoline/user.txt
:!whoami

Yep, looks like it!

All that’s left to do now is execute /bin/bash from inside vi and we’ve got a root shell!

:!/bin/bash

Would you look at that? A full root shell! Now all we need to do is grab /root/root.txt:

And we’re finished. A job well done I would say!

If you enjoyed this box, please let me know in the comments. It was great fun to build, and I’ve got a list of ideas as long as my arm — so keep an eye out for more in the future!