A step by step guide to setting up a CTF box.

Practising on vulnerable boxes from the likes of Vulnhub and HackTheBox forms a significant part of any aspiring pentester's learning journey. They're a fun way to put into practice the tools and techniques needed for the job, and a good way to become familiar with the services, ports, and operating systems that are vulnerable to exploitation. A few of my recent favourites are: Temple of Doom, GoldenEye, and Skytower. However, as a learning professional, I also know that one of the best ways to gain understanding is to try to teach to others. So, I've set myself a challenge to create my own vulnerable box and write up a post on how I did it so that others can do the same.

Conceptualisation

Before jumping into VMs and vulnerable apps it's important to consider a few questions:

What do I want people to learn from this machine?

What steps should be taken from start to finish?

Which exploitation techniques could be used?

What knowledge is needed?

What kind of vulnerability should be used?

What OS is required?

How many methods for each phase should be possible?

How many users are there?

What passwords should I use?

Researching

Creating a vulnerable box can also be thought of like some stages of a penetration test, but reversed. Here, we are going to start with the local privilege exploit and use that to inform other practical decisions. As it's my first time building a box, I'm going to choose a relatively simple exploit. I used the 'searchsploit' tool built into Kali (you will need an 'attacking' machine running during the build process anyway for testing purposes), but you could also use exploit-db to find one that fits your brief.

This exploit runs on Ubuntu 12.04/14.04/14.10/15.04, meaning that we have answered our OS question too.

Installing

We need to download an older version of Ubuntu to run on our vulnerable box. Luckily, these are easily found online. We can also use the following command:

This image can then be used in whatever virtualisation software you are using. For this, I've set mine up in VirtualBox.

Name your virtual machine and choose a compatible type

Add the iso as an IDE controller

Create a Virtual Hard Disk so that files and settings can be saved once the boot iso has run

Now you're set and you can start the VM for the first time. I've called this one ButtonBox1 and have the following settings:

Hostname: ButtonBox1

Username: zipper

User password: zipzap305

This password is contained in the rockyou.txt that comes as standard on on the Kali OS. I wanted a password that linked to the username somewhat, so used the following command (in my attacking box) to output all the passwords that included the phrase 'zip':

As the installation continues, we need to check a few options to ensure the box continues to remain vulnerable, and to allow us to add the services we want running on it.

Do not allow automatic updates when configuring taskel.

Select the software you want to use. As you can see, I've chosen OpenSSH, LAMP, Mail, and Samba file servers, but feel free to choose whatever works best for your goals for the box.

Once the box is up and running we want to be able to login via SSH as root, so we need to alter the "/etc/ssh/sshd_config" file (open it using nano or vim). Change the “PermitRootLogin" line of the file to yes.

We also need to set a root password, I used the following command:

The sudo password I set is another one found using grep on rockyou.txt

Whilst we are logged in as root, it would be prudent to install a compiler to compile our local privilege escalation as it's written in C. I used the following command:

Again, whilst we are still logged in as root we can add a flag for our would be attackers to capture.

We can then add a user flag to the zipper user account. This gives our box two possible flags to capture.

Now the users, passwords, software, and flags are set, this would be a good time to take a snapshot of the machine before we start testing out our exploits. To take a snapshot in VirtualBox use the machine tab, then click 'take snapshot'. This will allow use to revert the machine if/when the exploit breaks it.

Privilege escalation

Now, we need to check that the privilege escalation exploit that we chose earlier actually works against the machine.

The exploit is easily found again using searchsploit

There are a couple of great guides for copying files out of searchsploit so that they can be transferred via netcat from the attacking machine to the vulnerable machine. I copied the files over using netcat for a couple of reasons: one; as it is a vector that is likely to be used by an attacker and 2; I really don't want a machine with all these vulnerabilities having any kind of access to and from the internet.

[Attacking Machine] Copying the file from searchsploit to root directory so that it can be easily transferred via netcat

SSH into vulnerable machine. Receiving the local privilege exploit via netcat.

Here is the local privilege escalation being compiled and then executed. I used the following command:

This shows that our local privilege escalation works exactly as predicted. Let's revert to the previous snapshot so that we can try another vector.

SMB Exploit

The next part of the build involves configuring the Samba server in a way that will allow for both the use of a Metasploit module or manual exploitation.

We've now created a shared folder in the zipper user home directory. Now, we need to configure the samba server to reflect this. I added this to the very bottom of the smb.conf file.

Once you've done this, restart the service using:

The testparm command will show the configuration changes we made to the smb.conf file.

Next, from our attacking machine we can enumerate the server and check that the Sharing folder is accessible. We can use a tool called 'enum4linux' that will allow us to check this easily.

If everything is working as it should, it will enumerate the box and get the sharelist (hence the -S flag).

Here we can see that the Sharing folder is accessible. Take another snapshot of the machine at this stage.

We can also check that this vulnerability can be exploited with a Metasploit module.

Selecting the is_known_pipename module and setting the targeting options.

Gaining root privilege using Metasploit.

As you can see, the Metasploit module works as expected against the box. This is the end of our testing phase. We can revert

Next steps and summing up

This is a simple build that demonstrates some common vulnerabilities and services. To sum up we have got:

An old release of Ubuntu Linux with the version 14.04

Weak password for zipper

Weak password for root

Vulnerable kernel version

SSH root login enabled

Poorly configured SMB

We could also configure MySQL, Mail Server, and Apache which we added during the installation process (I will write another post where we do just that). Furthermore, the complexity of the machine can be increased by using stronger passwords, locking down the types of commands that zipper can use or files they can access, not allowing root login via SSH, or hiding information in hidden processes or files.

You can use this guide as a starting point or template and use your imagination from there. Most of my favorite boxes might not have been the hardest to break, but have a cool twist or some kind of theme. The main thing is that you plan your box carefully, take snapshots at each stage, test all the way through the process and do not expose it to the internet.

Thanks for reading,

Jack