Linux privilege escalation lab: a setuid binary, a sudo rule and a cron job to break

Each student gets an Ubuntu VM of their own with a second, low-privilege account on it, intern, given in the README along with its password. Root has left behind three ordinary administrator mistakes: a helper program carrying a bit it should not, a sudo rule that was never narrowed down, and a maintenance script root’s own cron runs that anybody can edit. The task is to use one of the three to reach root and write up what they used.

The VM is the student’s own, with no route to any other student’s machine and no route to the internet beyond Ubuntu’s own package archive, PyPI, npm and GitHub, so the only machine there is to attack is the one the lab gave them. The rule is said at the top of the lab, and is the law’s as much as ours: attack your own VM only, never one you do not own, under the Computer Misuse Act 1990.

What students learn

How an ordinary, small administrative shortcut becomes a way to root: a program given more privilege than its job needs, a sudo rule written for one command and never revisited, and a scheduled job that trusts a file anybody can change. Finding each one means looking at a machine the way an administrator should before handing an account to somebody else, not running a scanner. It suits a first course in Linux security, system hardening or an introduction to penetration testing.

The weaknesses

A helper program that is a copy of an ordinary system tool, with the setuid bit set so it always runs as root. A line in sudo’s configuration letting the low-privilege account run one ordinary program as root with no password. A script root’s own cron job runs every minute, left writable by anybody on the machine. The README the lab leaves in the home folder names the second account and gives none of the three away.

Run it in your browser

VM labs are set as a lab task in a module, and the sample is on the lab’s page. The machine is small: one CPU, 1 GB of memory and 6 GB of disk.

  1. Add the lab. In a module you teach, add a task and choose the Ubuntu VM lab card. The page shows a short description of the machine instead of a compose file.
  2. Start from the sample. The page offers ready-made labs to start from. Choose Linux privilege escalation. Using a sample replaces the text, and Undo brings yours back.
  3. Publish and start your own copy. Publish, then Start. The lab’s own setup script creates the second account, writes the flag and seeds the three weaknesses from Ubuntu’s archive the first time the VM starts, in about ten seconds.
  4. Open the terminal. Open its terminal and read README.md in the home folder: it says the second account’s name and password and gives none of the answers.

A basic lesson on this lab

Privilege Escalation Basics is a small lesson worked in this lab, which is an Ubuntu VM: each step is explained and has a Run button that types its command into the machine’s terminal and shows what it printed. A student meets the second account, looks at what it is and is not allowed to run, and reads the three places root left something behind, without using any of them.

The lesson looks around and leaves the lab’s own task, reaching root, to the student, so it hands out no answers. It is deliberately small: it shows a teacher what a lesson worked in a lab is, and the lab does the rest. Copy it into a module of your own to change it.

How it is handed in and read

This lab has no marking script, on purpose. A student on the machine already has its own administrator rights, so any file a script could read as proof, the student could write in one line without reaching root through the lab’s own weaknesses. A mark that is easy to fake is worse than none, so the work is a written account that you read. The flag is the student’s own goal and a prompt for that account, not evidence. Fixing the weaknesses afterwards is not asked here, and you can set it as further work.

  1. Hand it out. Assign the lab like any task, with a due date if you want one. Each student gets a VM of their own, kept between sessions. In the task’s hand-in settings choose Documents, so a student can hand in a written account.
  2. Read the write-up. The student hands in a short account of which weakness they used, the commands that did it and what the flag said. Nothing on the machine marks it, so you read it.
  3. Mark it. Mark it like any hand-in, and send the work back with a reason if it needs more.

The definition on GitHub

The file is the whole lab definition, the same text the platform runs: size, setup script and README. Copy it and change which program carries the setuid bit, which command the sudo rule allows, or what the writable script does, to make a lab of your own.

Questions people ask

Can students use this against a real server?
No, and the lab says so before anything else. The VM has no route to any other machine, and the README and this page both state the rule: attack your own copy only, which the Computer Misuse Act 1990 makes a condition of doing this at all.
Can a student fake it without reaching root?
Yes, and the lab does not pretend otherwise: a student on the machine has administrator rights of their own and could read the flag in one line. That is why nothing marks it automatically. The write-up, in the student’s own words and commands, is what you read.
Do students have to fix the weaknesses afterwards?
No, not in this lab. Fixing them is left as separate, further work a teacher can set.