|
This summer we'll do less presenting, and more discussing Network topics. We'll talk about becoming root. Two recent methods I have used are:
Dirtypipe requires that the exploiter be on the same machine, and can copy an executable binary to that machine. Probably only useful in a shared hosting environment, where you have a login on a machine, but not root access.
dirtypipe
takes advantage of a kernel bug introduced in the linux kernel 5.8, and fixed in 5.16.11 (and backported to 5.15.25 and 5.10.102). Using a command line pipe is very useful, but it uses kernel memory to store the output of one command, and then pipe it to the second command. And example of a pipe is:
$ ps -ef | grep systemd
root 223 1 0 Mar01 ? 00:03:42 /lib/systemd/systemd-journald
systemd+ 465 1 0 Mar01 ? 00:00:25 /lib/systemd/systemd-timesyncd
message+ 507 1 0 Mar01 ? 00:27:44 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
root 515 1 0 Mar01 ? 00:00:30 /lib/systemd/systemd-logind
cvmiller 740 1 0 Mar01 ? 00:00:06 /lib/systemd/systemd --user
cvmiller 776 740 0 Mar01 ? 00:57:34 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
cvmiller 960 1 0 Mar01 ? 00:00:10 xscreensaver-systemd
root 518266 1 0 May02 ? 00:00:12 /lib/systemd/systemd-udevd
cvmiller 1116023 1116010 0 16:33 pts/10 00:00:00 grep systemd
$
Above the output of ps
is piped to grep
where the output is filtered to only show processes with systemd
dirtypipe
must be compiled for the correct architecture (e.g. x86_64, ARM64, ARM7), and placed on the target machine. The source can be found on github.
Once it is compiled, it is just a matter of running it from an unprivileged account. Below it is run on a Debian Bullseye machine.
$ uname -a
Linux hau 5.10.0-1-amd64 #1 SMP Debian 5.10.4-1 (2020-12-31) x86_64 GNU/Linux
cvmiller@hau:~$
cvmiller@hau:~$ ./dirtypipe /usr/bin/su
[+] hijacking suid binary..
[+] dropping suid shell..
[+] restoring suid binary..
[+] popping root shell.. (dont forget to clean up /tmp/sh ;))
#
#
# id
uid=0(root) gid=0(root)
#
dirtypipe
hijacks a SUID binary, one that becomes root while it is running. There are valid reasons why there are SUID programs on the system. sudo
is an excellent example, in order to get root, the program must be able to elevate its own privilages.
An incomplete list of SUID binaries are:
$ ls -l /usr/bin | grep rws
-rwsr-xr-x 1 root root 58416 Feb 7 2020 chfn
-rwsr-xr-x 1 root root 52880 Feb 7 2020 chsh
-rwsr-xr-x 1 root root 34896 Jan 16 2021 fusermount3
-rwsr-xr-x 1 root root 88304 Feb 7 2020 gpasswd
-rwsr-xr-x 1 root root 55528 Jan 17 2021 mount
-rwsr-xr-x 1 root root 18656 Dec 11 2020 ndisc6
...
Note that the permissions are rws
as the user, the s indicates that the binary is SUID and will have the privileges of the owner of the file (as you can see root.
A few months ago, I was helping a friend put OpenWrt on his Dlink router, or trying to. Turns out, Dlink has made this challenging, and the router GUI won't accept non-Dlink images.
Fortunately, I wasn't the first to try this, and I followed the footsteps of others on the internet, to exploit a SOAP bug in the Dlink router software, which allowed the starting of a telnet server on the router running as root which didn't ask for a password.
I wrote this up in an article, back in February 2022.
While it is good to have a good firewall between you and the internet (OpenWrt is a good start), don't assume that there aren't vulnerabilities which could cause you a problem. Keep an eye on the CSEs to see what might apply, and update your software as needed.
23 July 2022