|
| 1 | +--- |
| 2 | +title: "OverTheWire Bandit: Level 19 to Level 20" |
| 3 | +date: 2026-06-30 03:00:00 +0500 |
| 4 | +categories: [CTF, Bandit] |
| 5 | +tags: [linux, setuid, permissions, privilege-escalation, overthewire, beginner] |
| 6 | +--- |
| 7 | + |
| 8 | +## The Goal |
| 9 | + |
| 10 | +Use a setuid binary in the home directory to read the password file for bandit20 — a file that bandit19 cannot access directly. |
| 11 | + |
| 12 | +## What I Did |
| 13 | + |
| 14 | +Listed the home directory and found a binary called `bandit20-do`. Ran it without arguments first as the level suggested: |
| 15 | + |
| 16 | +```bash |
| 17 | +bandit19@bandit:~$ ./bandit20-do |
| 18 | +Run a command as another user. |
| 19 | + Example: ./bandit20-do whoami |
| 20 | +``` |
| 21 | + |
| 22 | +Tested it with `whoami` to confirm who it runs as: |
| 23 | + |
| 24 | +```bash |
| 25 | +bandit19@bandit:~$ ./bandit20-do whoami |
| 26 | +bandit20 |
| 27 | +``` |
| 28 | + |
| 29 | +Confirmed — the binary runs commands as bandit20. Tried a few wrong approaches first: |
| 30 | + |
| 31 | +```bash |
| 32 | +./bandit20-do bandit20 # tried passing username as argument — wrong |
| 33 | +./bandit20-do whoami | cat # piping doesn't help here |
| 34 | +./bandit20-do whoami "cat bandit20" # passing multiple commands as one string — wrong |
| 35 | +``` |
| 36 | + |
| 37 | +Then used the full path to the password file: |
| 38 | + |
| 39 | +```bash |
| 40 | +bandit19@bandit:~$ ./bandit20-do cat /etc/bandit_pass/bandit20 |
| 41 | +4pIjcunZ0fK2vmp3IwfG8Vf7VhxD6pOA |
| 42 | +``` |
| 43 | + |
| 44 | +Verified the setuid bit with `ls -l`: |
| 45 | + |
| 46 | +```bash |
| 47 | +bandit19@bandit:~$ ls -l bandit20-do |
| 48 | +-rwsr-x--- 1 bandit20 bandit19 14880 Jun 24 14:59 bandit20-do |
| 49 | +``` |
| 50 | + |
| 51 | +The `s` in position 4 (`rws`) where the execute `x` would normally be confirms the setuid bit is set. |
| 52 | + |
| 53 | +## What the setuid Bit Does |
| 54 | + |
| 55 | +Normally when you run a program, it runs with your own user's privileges. The setuid bit changes this — if set on a binary, the program runs with the privileges of the **file's owner**, not the user who executed it. |
| 56 | + |
| 57 | +In this case: |
| 58 | +- The binary is owned by `bandit20` |
| 59 | +- The setuid bit is set |
| 60 | +- So when bandit19 runs `./bandit20-do`, the process runs as bandit20 |
| 61 | + |
| 62 | +This means any command passed to `bandit20-do` executes with bandit20's privileges — including reading `/etc/bandit_pass/bandit20`, which bandit19 cannot access directly. |
| 63 | + |
| 64 | +## How to Identify setuid Binaries |
| 65 | + |
| 66 | +**Using `ls -l`:** |
| 67 | +```bash |
| 68 | +ls -l bandit20-do |
| 69 | +-rwsr-x--- 1 bandit20 bandit19 14880 Jun 24 14:59 bandit20-do |
| 70 | +``` |
| 71 | +The `s` in the owner execute position (`rws`) indicates setuid is set. If the owner doesn't have execute permission, it shows as `S` (uppercase) instead. |
| 72 | + |
| 73 | +**Using `find` to locate all setuid binaries on a system:** |
| 74 | +```bash |
| 75 | +find / -perm -4000 2>/dev/null |
| 76 | +``` |
| 77 | +This is one of the first commands run during penetration testing after gaining initial access — looking for setuid binaries that might be exploitable to escalate privileges. |
| 78 | + |
| 79 | +## Real World Significance |
| 80 | + |
| 81 | +setuid is how Linux allows specific programs to do things regular users can't. The `ping` command needs to send raw network packets — a root-only privilege — so it has the setuid bit set with root as owner. Any user can run ping but the process briefly runs as root just long enough to do its job. |
| 82 | + |
| 83 | +The security risk: if a setuid binary has a vulnerability like a buffer overflow, an attacker who can exploit it inherits the owner's privileges. A vulnerable setuid root binary means full root compromise from a normal user account. This is one of the most common privilege escalation vectors in real penetration tests and CTF challenges. |
| 84 | + |
| 85 | +## What I Learned |
| 86 | + |
| 87 | +**setuid lets a binary run as its owner regardless of who executes it.** The binary acts as a bridge between privilege levels. |
| 88 | + |
| 89 | +**The `s` in `ls -l` output identifies setuid.** Lowercase `s` means setuid is set and the owner has execute permission. Uppercase `S` means setuid is set but the owner does not have execute — which is usually a misconfiguration. |
| 90 | + |
| 91 | +**Full paths avoid ambiguity.** Instead of navigating to `/etc/bandit_pass/` and then running `cat`, passing the full path as a single argument to the binary is cleaner and works regardless of your current directory. |
| 92 | + |
| 93 | +## Commands Used |
| 94 | + |
| 95 | +| Command | What it did | |
| 96 | +|---|---| |
| 97 | +| `./bandit20-do` | Showed usage — runs commands as another user | |
| 98 | +| `./bandit20-do whoami` | Confirmed the binary runs as bandit20 | |
| 99 | +| `./bandit20-do cat /etc/bandit_pass/bandit20` | Read the password file as bandit20 | |
| 100 | +| `ls -l bandit20-do` | Confirmed the setuid bit with the `s` in permissions | |
0 commit comments