Year Of The Rabbit Walkthrough
We enumerate this server using Nmap, and Gobuster to find an MP4 file in the assets folder(Rabbit hole), then in the style.css file, we find the first hint that will lead us to a png image. We do basic steganography on that image to extract the FTP user and bunch of passwords, when we log in to the FTP we find SSH credentials, after we login to the SSH we find a welcome message from the server admin and this message contains the location to the user password.
Finally, we escalate our privileges to root by exploiting sudo, vi and a vulnerability in the shell(CVE-2019–14287)
As usual, we start with Nmap scan to check open ports and the services that are running on the server
nmap -sT -sV -sC 10.10.173.136
Note that in TryHackMe machines IPs are not static, and they change every time you start the machine after termination or after the allowed time of using the machine is expired, so if you want to do the machine, you might get a different machine IP.
Port 21/ tcp open ftp vsftpd 3.0.2
Port 22/tcp open ssh OpenSSH 6.7p1 Debian 5 (protocol 2.0)
port 80/tcp open http Apache httpd 2.4.10 ((Debian))
We check searchsploit for any possible vulunrabilities for vsftpd 3.0.2 but we don’t find anything.
We navigate to http://10.10.173.136/ using the web browser, and we get the Apache main page
We check the page source, but we find nothing, so we run Gobuster
gobuster dir -u 10.10.173.136 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt
We get the /assets folder, we navigate to this folder in the web browser, and we find the style.css file, and an MP4 file containing Rick Astley song Never Gonna Give You Up
The MP4 file was there just to disturb us(Rabbit hole) and in the middle of the song we hear an over recorded voice telling us that we are looking in the wrong place, but in the style.css file we find a hint to a secret page “/sup3r_s3cr3t_fl4g.php”
I intercepted the request with Burp to check what’s going on, and when we send the request to the repeater and we receive a response we see that there is a hidden directory /WExYY3Cv-qU
This location contains a png image of a beautiful girl
we download the file to our machine using wget then we read it using the strings command, and we find the FTP user name with a bunch of passwords
we know now that the FTP username is “ftpuser”, but we need to create a list of password and brute force the FTP password, so we save all these passwords to a file and we use a tool named ncrack to brute force the FTP protocols
ncrack --user ftpuser -P /root/Desktop/ctf/rabbit/ftppass ftp://10.10.173.136
This will give us that the password for the “ftpuser” is “5iez1wGXKfPKQ”
We login to the FTP using this credentials, and we find a file named “Eli’s_Creds.txt” we download this file to our machine using the get command.
We read it using the cat command.
I know this type of encryption from a previous CTF, it’s Brainfuck (it’s actually a programing language)
We use this website to decode it(execute it)
and it will give us
We use these creds to login to the machine using the SSH
As soon as we login we see that the sysadmin has left a message for us and this message contains information about a directory containing s3cr3t the password of the second user, which is really weird thing from the machine creator, because I logging in as Eli why I am getting a message for Gwendoline, maybe that is a mistake that might occur in real-life scenarios
We don’t find the user flag in Eli’s directory but instead, we find it in Gwendoline home directory, and we don’t have permissions to read it
Privilige Escalation to gwendoline:
We need to elevate our privileges to gwendoline so we navigate to the s3cr3t using the locate command directory and we find a file containing the password for gwendoline
So we try to elevate our privileges to wendoline using su command, and the password that we got MniVCQVhQHUNI
Privilige Escalation to root:
Now we need to escalate our privilege to root, and the first thing that I like to do when I own the user is checking if this user can execute anything as root using sudo, and I check this using sudo -l command
We can see that this user can run vi as root on the home/gwendoline/user.txt so I check if there is anything for vi in GTFOBins and I find vi is vulnerable and we can spawn a root shell using it.
I tried to run
sudo -uroot /usr/bin/vi /home/gwendoline/user.txt
But I got “Sorry, user gwendoline is not allowed to execute ‘/usr/bin/vi /home/gwendoline/user.txt’ as root on year-of-the-rabbit”
I researched to find why, and I find this article “That’s the scary version, and when we think about how powerful and popular Sudo is, CVE-2019–14287 should not be ignored. That said, it’s also important to note that the vulnerability is relevant in a specific configuration in the Sudo security policy, called “sudoers”, which helps ensure that privileges are limited only to specific users.”
This means that the user gwendoline may run /usr/bin/vi as any user except the root user.
A security researcher from APPLE called Joe Vennix from found that the function fails to parse all values correctly and when giving the parameter user id “-1” or its unsigned number “4294967295”, the command will run as root(CVE-2019–14287)
So I ran the following command
sudo -u#-1 /usr/bin/vi /home/gwendoline/user.txt
Then I root in vi !/bin/bash and I became root