Many months ago, we started looking around for a platform on which to build our new Persistence™ service. We were looking for something that had scanning appliances which connect back over a secure tunnel (SSL/SSH, certificate-based) and have no listening ports. With this scheme, there would be no listening ports, and no obvious way to attack the boxes we deploy to client networks. These appliances would also need to have multiple interfaces (VLAN and physical), because the appliances aren't exactly cheap, and I think it's just dumb to have redundant hardware sucking electricity where it's not necessary.
So, as many in the IT and security fields know, it's bad practice to have any one device touching more than one network. The exceptions to this rule are usually security devices like firewalls and IDS sensors, all of which need to be specially hardened as any one vulnerability would go against the point of having multiple networks to separate groups of devices. In the process of evaluating devices from all the top vendors in the arena, I set up a test network on which to run each of the platforms. As part of this testing, I wanted to be sure that straddling a firewall and connecting to several network segments wouldn't be an issue. As it turns out, one of the boxes I tested had an issue. (As I'm under NDAs with pretty much every company I dealt with, I'm not going to comment on which product had the issue. I have been told that a patch is on its way and will hit in several weeks.)
The device in which I found an issue did meet all of my criteria. It had almost zero footprint on the network. It communicated only in encrypted tunnels, which were outbound from the appliance only. It had no listening ports. However, what I did find is that the device responded to ICMP pings (standard echo request/reply). I can see where this functionality would be useful for the end users, but from the standpoint of super-hardening, it should be disabled, or at least have an option to be disabled.
The specific flaw I found was that the OS's kernel didn't perform proper source checking on packets. For example, if interface 1 is on 10.1.1.0/24, and interface 2 is on 10.2.2.0/24, it should drop packets claiming to come from 10.2.2.2 which arrive on interface 1, and vice versa. Failing to do this, the device I was testing happily replies back out the other interface. Spoofing packets from both directions allows us to set up an ICMP tunnel, over which we can move just about anything. Unless the backbone is set up to detect excessive ICMP traffic (monitor port + IDS, or switch-based IDS), or if the traffic needs to pass over standard security devices (an upstream firewall/IDS/IPS/router), this would be pretty difficult to track down. Most organizations I've been in do not have the infrastructure to watch for this kind of tunneling when it is used specifically to bypass the firewall.
This attack isn't exactly l33t or hardcore, it's quite basic. It's unfortunate that some of the basics do get missed when most attention is paid to higher level attacks and other threats, but it does happen quite often. Fortunately, the vendor had an excellent response in terms of time and quality, and hopefully will give me many discounts in the future for doing some QA work for them ;-).
Leave a comment