Sunday, June 10, 2018

All Your SSH Are Belong to Me



During a recent network security assessment, a colleague of mine proposed a very simple yet brilliant idea: logging credentials from an SSH server in order to compromise network services. What?

Here's the simple part:

Grabbing credentials from SSH – a quick Google search turns up a few blog posts on this topic, and there seem to be two basic approaches. One is to modify the source code of the authentication library behind OpenSSH so that it will log each authentication attempt. This is great, and would certainly be the best approach if your goal was to set up a honeypot. The other approach, better suited to an attack scenario because it doesn't require you to modify any binaries, is to use strace to dump strings going in and out of the child processes spawned by sshd during authentication. This is really easy to do as long as you have root privileges on the box, and Ventz provides some nice POC code for us: https://blog.vpetkov.net/2013/01/29/sniffing-ssh-password-from-the-server-side/

I took this idea and expanded on it a bit, writing out a bash script that not only monitors for child processes and attaches strace to them automatically, but parses the output in order to log the username and password from each authentication attempt. The result is super handy and is available on my GitHub: https://github.com/braindead-sec/ssh-grabber

Now for the brilliant part:

At face value, a tool like this seems to have limited usefulness. After all, you have to be root in order to run strace, so at that point you can just dump passwords from the box and call it a day, right? Consider this scenario: you've socially engineered your way into a facility, like on a physical pen testing engagement. You're able to plant a rogue device on the network, and you suspect there are automated tools that regularly scan the network for various purposes – asset discovery, vulnerability scanning, network access control, etc. Many of these services do their job by testing various logins to determine how the device is configured. Suddenly this tool becomes a whole lot more valuable!

You start an SSH server on the device, run ssh-grabber to start harvesting credentials, and plug the device in to the network. With a little luck, bam! Network services begin probing the device, and you just harvested the usernames and passwords of the very services intended to secure the network, in cleartext. What's more, if you're lucky enough that these services were configured with password authentication in the first place, it is more likely than not you just scored credentials with access to a large number of endpoints within the network, the *nix equivalent of domain admin! Even if your rogue device ends up getting blocked by the NAC, it's already game over as long as you can retrieve logs from the device.

Have fun with this one. To the network admins – be careful with your security tools. To avoid getting owned by this attack, make sure those service accounts use private keys instead of passwords, and make sure they have minimal privileges within the network. It's one thing for a service to have the ability to authenticate to every device on the network to make sure it's legitimate. If that service also has the authority to administer every device on the network, however, you've got a disastrous vulnerability just waiting to be exploited. Take care, and lock it down!