What you will do
This machine has a second, low-privilege account on it, intern, and an administrator has left three ordinary mistakes behind for it to find: a program with more privilege than it needs, a sudo rule that was never narrowed down, and a scheduled job that trusts a file anybody can change. You will look at the three from your own account, student, without using any of them: finding and using one is the lab's own task.
Before you start
Note
Press Start the lab on the bar at the top of this lesson. This lab is a whole Ubuntu machine of your own, so it takes a little longer to come up than a container. Each Run button below types its command into the machine's terminal, one after another. If one says the machine is still starting, wait a few seconds and press it again. To watch them, or to type your own, press Open terminal on the bar.
The one rule
Warning
This machine is yours alone, with no route to any other student's machine and no route to the internet beyond a few package archives. Attack only this machine: the Computer Misuse Act 1990 makes doing this to a machine that is not yours a criminal offence.
1. Meet the second account
This machine has a second account that the lab's setup made, with none of your own account's privilege. getent passwd reads the system's account list and prints one line for intern: its own home folder and its own shell, nothing more.
getent passwd internShown here, not run. Create a free account to press Run and type it into your own lab’s terminal.
2. Look at the setuid helper
A setuid program always runs as the user who owns it, whoever starts it. ls -l shows an s where the owner's execute bit would be: -rwsr-xr-x, owned by root. So anybody who runs it is root while it runs.
ls -l /usr/local/bin/sysfindShown here, not run. Create a free account to press Run and type it into your own lab’s terminal.
3. Look at the sudo rule
sudo's own configuration says who may run what as somebody else. Your account can already read it with sudo. This line lets intern run one program as root with no password at all.
sudo cat /etc/sudoers.d/90-lab-internShown here, not run. Create a free account to press Run and type it into your own lab’s terminal.
4. Look at the writable script
root's own cron runs this script every minute. ls -l shows rwxrwxrwx: every bit set, so anybody on the machine, intern included, can change what it does before root next runs it.
ls -l /opt/maintenance/cleanup.shShown here, not run. Create a free account to press Run and type it into your own lab’s terminal.
5. Confirm root runs it
This reads root's own scheduled jobs the same way sudo cat read the sudo rule: one line, the script from the step before, run every minute as root.
sudo crontab -l -u rootShown here, not run. Create a free account to press Run and type it into your own lab’s terminal.
Now do the lab
Tip
You have seen the three weaknesses. Using one of them to reach root is the task of this lab: switch to the low-privilege account with su - intern (its password is in README.md, read it with cat README.md), find out which weakness gets you to root, and prove it the way the README asks.
For teachers
Tip
This lesson is a small example of a lesson worked in a lab: the steps and the Run buttons are the lesson, and the lab is each student's own copy. This lesson is worked in a VM lab: each student has an Ubuntu machine of their own with a second account and three weaknesses already on it. The lab has no marking script, because a student on this machine can write any file a script could read: the student hands in a write-up of the weakness they used and the commands that did it, and you read it. Copy it into your own module and change it, or build one from scratch with the Lab menu in the lesson builder.