Build Your First Practical Lab - Part 2

This is the second of two articles on building a custom practical lab from scratch. Part 1 covered launching an Elastic Compute Cloud (EC2) instance in your Amazon Web Services (AWS) account and configuring it as a lab machine.

Here you'll build a simple Linux privilege escalation scenario on that machine, turn it into an image, and import it into Lab Builder. By the end you'll have a working lab you can copy for scenarios of your own.

Important: Run the steps below as the ubuntu user, not as lab-user. If you're still in the lab-user session you opened at the end of part 1, log out and reconnect as ubuntu.

Set the lab objective

The objective of this lab is to read a token file. To get to it, the learner has to escalate privileges through a misconfiguration. Start by creating a flag.txt file inside /root/ holding the string the learner has to find.

sudo nano /root/flag.txt

Add some content to the file. This is the flag that completes the lab.

w3ll_don3_h4ck3r

Save the file.

Build the lab challenge

Now set up the challenge. The goal is for lab-user to find a way to read /root/flag.txt, which is owned by root and out of reach by default. They'll get there by exploiting a world-writable script that root runs from a cron job.

Create a directory to hold the script that lab-user can exploit. In this example it's a simple script that writes the current time to a file.

sudo mkdir /opt/date_printer

Root runs this script, but lab-user can write to it. The script itself does nothing interesting. The point of the lab is for the learner to spot the misconfiguration that lets them change it, and then use it to read /root/flag.txt.

Create a file for the script:

sudo nano /opt/date_printer/printer.sh

Add the following content:

#!/bin/bash
echo "Running date_printer: $(date '+%Y-%m-%d %H:%M:%S')" >> /var/log/date.log

Save the file.

Next, set the misconfigured permissions that let lab-user write to the script, which is what makes the privilege escalation possible.

sudo chmod +x /opt/date_printer/printer.sh
sudo chown root:root /opt/date_printer/printer.sh
sudo chmod 666 /opt/date_printer/printer.sh

Set the folder up the same way, so root owns it but other users on the machine can still get into it.

sudo chown root:root /opt/date_printer
sudo chmod 777 /opt/date_printer

Note: These permissions are deliberately weak, because they're the vulnerability the learner exploits. Only use this image as a lab machine, and don't reuse it for anything else.

Now add a cron job to run the script you just created. This scenario uses /etc/crontab, which holds system-wide cron tasks and is readable by anyone. That's useful, because it leaves a breadcrumb. Reading that file is a common early check when you're looking for privilege escalation on Linux, and the learner will see a script running every minute and go and investigate it.

Edit the file:

sudo nano /etc/crontab

Add the following line at the end. It tells cron to run /opt/date_printer/printer.sh every minute as root.

* * * * * root /opt/date_printer/printer.sh

Save the file.

You now have a configured image with a low-privilege lab-user account to connect with, and a cron job vulnerability for your learners to exploit. All they have to do is find the script that the cron job runs and edit it to print the token from /root/flag.txt.

One way to do that is to replace the contents of /opt/date_printer/printer.sh with this:

#!/bin/bash
cat /root/flag.txt >> /var/log/date.log

That one-liner copies the contents of /root/flag.txt into /var/log/date.log, which the learner can read to get the token. There are other routes to the flag, but this one keeps the example simple.

Image and share the lab AMI

Go back to the EC2 dashboard and find the instance you just configured. Right-click the EC2 machine, select Image and templates, then Create image.

Leave the other settings at their defaults and click Create image. AWS creates an Amazon Machine Image (AMI) from your configured EC2 lab machine.

Add your custom AMI to your lab

Go to Lab Builder and open your custom lab by clicking Manage > Create Lab. If you haven't created one yet, select Create a new custom lab.

On the Lab details page, name your lab and fill in the rest of the information so your learners know what they're picking up. This example is called Linux CTF Challenge.

Next, fill in the briefing panel. The briefing panel is the learning material that tells your learners about the topic and anything else they need to answer the questions. This is a CTF, so give them very little:

Linux CTF

This is a CTF lab scenario designed to test your ability to exploit a common misconfiguration in Linux that could result in privilege escalation. Your task in this lab is to read a flag located at /root/flag.txt.

Good luck!

Now add a Task. Tasks are what the learner has to solve to complete the lab. This lab needs one question, to check they've read the flag in /root/flag.txt.

Select Add task to open the library of task types, then select Question. That adds a question to the lab task list, which you can then change by selecting Edit.

Update the question settings to the following:

Now import your custom image. Select Systems, then click Add under the Virtual machine – EC2 type. That adds a new machine to your lab.

Once the machine is added, configure it. Select Edit at the top right to open the machine's configuration editor.

The blue information box tells you which region to use and, most importantly, which AWS account to share your image with so the platform can use it in a lab.

In the AWS account where you created the AMI, click the AMI, then find Permissions at the bottom of the screen.

Select Edit AMI permissions, then Add account ID, and enter the account ID that Lab Builder showed you.

Click Share AMI. Then copy the AMI ID of the machine you just shared and paste it into the AMI ID field in the Lab Builder machine configuration editor.

Set the rest of the configuration in the editor:

Once your system is configured, try it out by selecting Preview System in the system view.

If you've built everything correctly, you'll get a preview of your newly configured machine. Run through your lab scenario now to check it works.

That's it. Congratulations on building your first practical lab. From here you can add more questions, fill out the briefing panel further, and publish the lab to your organization.

You can build anything this way, from a single privilege escalation machine like this one to a multi-machine attack simulation. If you want more ideas or support, see the Lab Builder articles below.