Far be it from us to talk about offense without a corresponding defensive post. Cris’ post yesterday got some attention from a few other blogs (here, here, and here for starters), but it wasn’t the entire story. While we discover a lot of these methods in our penetration tests and application assessments, Neohapsis is, first and foremost, about protecting our customers. So, when you see us post something about cool new offensive methods (as I’m sure you will quite often), you can always expect someone to chime in with defense.
Today, that person is me.
Preventing the Connect-Back Shell
I’ll start with the obvious one: keep your device from being compromised. The connect-back bash trick will only work once the host is compromised as a method of allowing easy access. Thus, if the device isn’t compromised, this never happens.
Alright, that was too simple. Let’s talk about prevention once compromise happens.
What Cris wrote about isn’t new. This method of using bash to provide easy access to sockets has been known for quite some time – it’s easily discovered on the blogosphere in articles here and here for example. Since this is built-in to bash by default in most instances, the main method of prevention is the one that Cris hinted at in his article – if you’re on a system that you believe could be compromised or simply want to harden, you have to recompile bash to remove the /dev/tcp and /dev/udp redirects.
Come to think of it, though… if the box is worth hardening to that level, why have bash on the box at all? Or, at the very least, why not set all user’s shells to rbash and restrict them from accessing the redirection operators that make this possible?
Mitigation of the Issue
Since this trick lives in bash, it’s entirely within user-space. So, there are things we can do within the kernel to mitigate the attack. The first one that comes to mind is ensuring that the target host has a decent packet-filter on it – this probably should be part of most system hardening in the first place. If we’re talking about a system with a well-known service profile (e.g. a web-server), allowing all client-initiated outbound connections to the web probably isn’t the best of ideas. So, set up a packet filter on the box to allow only the connections that you know are required.
Okay… that’s just a couple of ideas. If you have other ideas, please post them in the comments section. We’d love to hear any discussion or thoughts on how to mitigate against this.