Thursday, April 14, 2016

Rooting Linux Servers for Fun & Prophit

Rooting a machine is incredibly easy these days. Give me five minutes, a bash shell, and a shodan api key, and I will get you root access to some system, somewhere. But while anyone can root a box, maintaining access is another art altogether, and one that is not always straight forward. Here are some common techniques and their caveats.

If the host is not behind NAT, than you may be able to use a bindshell. This method is nice because the attacker doesn't have to leave an IP address anywhere on the system, and can initiate the connection only when needed. However, even if the victim host is not behind NAT, it may have it's own firewall rules which will block incoming connections. Even if there is no firewall, adding a rogue listening service will show up in ss and netstat output, and that could lead to discovery. To get around that problem, you could attempt to compromise an existing service, which can be less conspicuous.

For instance, you could enable root ssh access (if it's not already enabled), and add a pub key to /root/.ssh/authorized_keys, but even the most incompetent system administrator is bound to notice that. You could also add a root equivalent account to /etc/passwd under a different username, but that also is easy to spot. Another popular tactic is to find a way to get limited shell access to the system, perhaps through some legitimate service, or perhaps by installing a hidden webshell somewhere deep within the serving directory. Next, a setuid binary is placed somewhere, so that when executed, it always executes as root. This works well, and if hidden correctly, it may be a long time before discovered. However, suid files are often searched for by security programs and administrators alike, and when found will probably be further examined and removed.

Than we have reverse shells, which except in strict environments, tend to get around iptables rules and NAT setups, because firewalls tend to allow outgoing connections. The main caveat to this method is that you either need to leave the reverse shell constantly trying to connect back to an IP that you control, or you need to find a way to remotely trigger it, which leads us back to our firewall problem... So, what else can we do?

We can use ICMP to trigger our reverse shell! "Pings", or ICMP echo requests are more often that not, allowed for diagnostic purposes. They also are somewhat inconspicuous, as they don't show up in netstat output like tcp and udp connections do, and are easy to overlook in tcpdump output as well. Suffice to say, most of the time, a couple of echo request packets will go unnoticed. We can even encode messages in ICMP packets, which we can use to both password protect our backdoor, and to tell the victim system where to send our reverse shell. Actually, we can run pretty much any command we want with a cleverly baked raw packet, but triggering a proper shell is much nicer.

I found this unix backdoor called Prism a while ago on Github and forked it (original author andreafabrizi). It daemonizes itself and waits for the ICMP trigger, which contains a password and ip:port to send a reverse shell back to. It also offers all the usual things one would expect a backdoor to do, like changing it's process name after forking, and also offers a 'static' mode that operates like a standard reverse shell and reconnects every 15 second or whatever interval you set for situations where you can't use ICMP.

It's a great solution for the times when you have a host with a public ip that does not block incoming echo requests that you just obtained root on. While running some tests, I also noticed that when installed as an Ubuntu upstart job, for some reason it is difficult to spot the daemon by simple running ps... Actually, that's kind of scary. It also does not need to listen on any ip ports, making it a very stealthy userspace backdoor. Another bonus is the option to flush iptables before sending the reverse shell, which could ensure you keep access on systems that block outgoing traffic.

Armed with this knowledge and a shodan account, you should be able to take over the world. Good luck.

No comments:

Post a Comment