DailyDave had a thread recently about defending against 0day. Carnal0wnage had a follow up on it. I meant to follow up more on the thought but I’m slow.
I’ve used generic 0days on pen tests before. By “generic” I mean 0day for popular software with high reliability. Generally speaking if that ends up in a report I hear “you cheated” or “Only someone with xyz background could do that”. Both are true. I’ll get to the “you cheated” in a moment, but you either need a highly specialized background or good security friends to get good 0days. Most organizations aren’t targeted by that sort of advesary. The exception is any organization in Fortune 100, Energy, Defense, or Finance. So when testing with 0day I think it’s important to understand your business and your threat. It simply doesn’t make sense to protect $100 of assets with $1000 of security.
Now is 0day “cheating”? Sometimes. I think it really depends. Ron Gula, head of Tenable (maker of Nessus) stated that simplicity is key. Indeed, complexity inevitably introduces security flaws. However, defense in depth is certainly more complicated than a flat network and is generally considered more secure. Yet even that can introduce new attacks. There have previously been exploits against Snort that an attacker could blindy attack to bypass the network perimeter. Snort is adding a best practice and defense in depth (by detecting attacks that made it into the network) but because of complexity (adding something) the network was made vulnerable. You can add more complexity to mitigate the attack such as cutting the Tx wires on the ethernet, ensure the promiscuous card has no IP address, that the management interface is on a private well monitored and hardened network, certs aren’t stored on the device, good egress rules, and standard hardening guidelines are followed. That’s pushing fairly paranoid though.
I haven’t answered is this cheating. The answer is, in this case, yes. The administrator followed best practice, the attacker basically sent the attack blind. The attacker leveraged a nasty exploit and won in a manner that most organizations couldn’t defend. The counter example is a friend who had an OWA 0day. He could pop through an OWA login and gain access to an account. I’d argue this isn’t cheating! Why the difference? In this case, there’s a clear high value target (corporate email) that an attacker is motivated to invest signifigant time to building an exploit. This matters, in my opinion, because it has a reasonable mitigation that the defender should have in place (restricting email to IPs, VPN, or using multi-stage authentication).
This is a complicated issue that’s in an extreme grey area. Balancing complexity with defense-in-depth to protect ungainst an unknown threat (0day) has no simple solution and the above case is only my particular view on this one case. But it goes to my overall solution, to protecting against 0day. Pen test continually and implement the recommendations. There’s always the one off case where there’s nothing reasonable (cost/business effective) you can do to mitigate a risk. In those cases you’ll simply have to choose to accept the risk. If you get burned in a pen test or by a hacker, that’s unfortunate but if you did your analysis and mitigation correctly you’re still ahead. There’s no way to protect against all unknown threats. Use pen testers (not just vuln scanners) to get into your network and figure out how a real-world attacker will compromise your network. In almost all cases buying or writing a 0day isn’t necessary so you have plenty to worry about before you worry about the unknown. Additionally, if the pen tester simply can’t get in otherwise they’ll probably go look for a 0day – if you want put that in the Statement of Work. Otherwise don’t worry too much about the unknown. The major exception to this is in-house and niche software that you suspect might be a problem but no one wants to touch.
So to recap:
- Don’t overly worry about the unknown
- Complexity is bad. Reduce it whenever possible
- Reduce your attack surface with defense-in-depth (this has to be balanced with 2)
- Pen test whenever possible. Make sure you understand what enabled the attacks and mitigate those factors.
- Accept (and document) risk that doesn’t make sense to mitigate