I'm not sure what it is, but there continues to be some sort of "competition" for "who can find the biggest bug" -- as if attackers had to choose, and more importantly, as if any bug was so big that it could not be made even better by combined use with its "competition". Before my DNS talk, my old friend FX from Recurity Labs was comparing DNS issues to the Debian Non-Random Number Generator issue that caused all sorts of SSL certificates to offer no security value, and the SNMPv3 flaws that allowed infrastructure devices to be remotely administered by people who happened not to know the password.
Of course, after the talk, it became clear that the DNS hack and the Debian NRNG combined rather destructively -- DNS allowed you to finally play MITM with all the SSL private keys you could trivially compute, and as Ben Laurie found, this included the keys for Sun's OpenID authentication provider. And, since the DNS hack turns Java back into a universal UDP and TCP gateway, we end up being able to log into SNMPv3 devices that would otherwise be protected behind firewalls.
So there's no sense making a competition out of it. There's just an ever growing toolchest, growing from a single emerging theme:
Weaknesses in authentication and encryption, some which have been known to at least some degree for quite some time and many of which are sourced in the core design of the system, continue to pose a threat to the Internet infrastructure at large, both by corrupting routing, and making those corrupted routes problematic.
Back in July, the genuinely brilliant Halvar Flake posted the following regarding the entire DNS issue:
"I fail to understand the seriousness with which this bug is handled though. Anybody who uses the Internet has to assume that his gateway is owned."
And thus, why 75% of my Black Hat talk was on the real-world effectiveness of Man-In-The-Middle attacks: Most people aren't as smart as Halvar. I'm certainly not :) Almost nobody assumes that their gateway is owned -- and even those that do, and try to engineer around it, deploy ineffective protections that are only "secure unless there's an attacker".
I say this is a theme, because it is the unifying element between some of the year's most high profile flaws. There are two subclasses -- some involve weak authentication migrating traffic from one location to another, while others involve weak authentication allowing an attacker to read or modify traffic migrated to him -- but you'd have to have some pretty serious blinders to not see the unifying theme of weak authentication leads to pwnage.
Consider:
Luciano Bello's Debian NRNG: This involves a core design requiring the generation of random numbers, but the random number generator required a random seed, but alas, the seed was made insufficiently random. It's an implementation flaw, but barely -- and the effect was catastrophic failure against members of the X.509 PKI authentication system that had used the Debian NRNG, and thus by extension SSL's encryption logic and OpenID (for Sun's) authentication gateway.
Wes Hardakar's SNMPv3 Bug: Here, we have an authentication protocol that allows an attacker to declare how many bytes he wants to have to correctly provide. Now, the attacker can claim "just 1 please" -- and he gets into any router suffering this bug within seconds. That, by extension, allows control over all traffic traversing that router.
Mike Zusman's Insecure SSL-VPN's: SSL is supposed to protect us, but there's no sense creating a secure session to someone if you don't actually know who they are. Don't worry though, by design anything that isn't a web browser is terrifyingly likely to only to skip authentication entirely and just create an encrypted link to whoever's responding. One would think that SSL-VPN's, whose sole purpose is to prevent attackers from accessing network traffic, would be immune. But with 42% of certificates on the Internet being self-signed, and a lot of them being for SSL-VPN's, one would be wrong. By extension this auth failure exposes all traffic routed over these SSL-VPN's.
Mike Perry's Insecure Cookies: This gets interesting. Here we have two different authentication protocols in place -- one, from server to client, based on X.509. The other, from client to server, based on a plaintext password (delivered, at least, over an encrypted session authenticated by the server-to-client cert). But to prevent the user from needing to repeatedly type in their plaintext password, a password-equivalent token (or cookie) is handed to the user's browser, which will be attached to every request within the securely encrypted channel. Unfortunately, it'll also be attached to every request which does not traverse the securely encrypted channel, because the cookies aren't marked for secure-only. Once the cookie leaks, of course, it'll authenticate a bad guy who creates an encrypted session to that server. So by extension bad guys get to play in any number of interesting sites.
My DNS flaw: Here we have a protocol that directly controls routing decisions, ultimately designed to authenticate its messages via a random number between 0 and 65535. Guess the number, and change routing. This was supposed to be OK, because you could only guess a certain number of times per day. There was even an RFC entirely based around this time limit. It turns out there's a good dozen ways around that limit, allowing anonymous and even almost 100% packet spoofed compromise of routing decisions. This, by extension, allowed exploitation of all traffic that was weakly authenticating.
It's the same story, again and again. And now, everyone talking about BGP. So lets do the same sort of analysis on BGP:
Kapela and Pilosov's BGP flaw: In BGP, only the nearest neighbor is authenticated. The concept is that all "members of the club" authenticate all other members, while the actual data they provide and distribute is trusted. If it's not actually trusted, anyone can hijack traffic from anyone else's routes.
Pilosov's done some cool work here. It's not the sort of devastating surprise some people seem to want it to be. Indeed, that's what makes it so interesting. BGP was actually supposed to be broken, in this precise manner. Literally, in every day use, any BGP administrator has always had the ability to hijack anyone else's traffic. Pilosov has a new, even beautiful MITM attack, but as mine was not the first DNS attack, his is not the first BGP MITM. Tales of using BGP to force traffic through a compromised router (possibly compromised through SNMPv3) are legion, and Javascript and the browser DOM blur things pretty fiercely in terms of the relevance of being able to pass through to the legitimate endpoint anyway.
That's not to take away from the work. It's an interesting trick. But we need to level set here:
First, if you're not part of the BGP club, you're just not running this attack. Pakistan took out YouTube with BGP -- but some random kid with the ability to spoof IP packets couldn't. In other words, we're just not going to see a Metasploit module anyone can run to complete these sorts of attacks. Now, there are some entertaining combinatorics that could be played -- DNS to enable Java's SNMPv3 access to internal routers at an ISP, and then from that internal router running the sort of BGP tricks Pilosov's talking about. This goes back to the utter folly of trying to rank these bugs independently from one another. But these sort of combinatorics are at a fundamentally different level than the fire-and-forget antics that DNS allowed, and on a fundamental level, the number of potential attackers (and the number of involved defenders) on BGP is a lot lower.
Second, we have far better logging -- and thus accountability -- in the BGP realm than we do perhaps for any other protocol on the Internet. Consider the archives at APNIC -- yes, that's route history going back to 1999 -- and Renesys has even more. That sort of forensic data is unimaginable for anything else, least of all DNS. BGP may have its fair share of bad actors -- consider spammers who advertise temporary ranges in unused space for mail delivery purposes, thus getting around blackholes -- but any of the really nasty stuff leaves a paper trail unmatched by any other attack.
Third, BGP is something of a sledgehammer. Yes, you're grabbing traffic -- but your control over exactly what traffic you grab is fairly limited. Contrast that with DNS, which allows astonishingly fine grained targeting over exactly what you grab -- indeed, you don't even need to know in advance what traffic you want. The victim network will simply offer you interesting names, and you get to choose on the fly which ones you'll take. These names may even be internal names, offering the impossible-with-BGP attack of hijacking traffic between two hosts on the exact same network segment.
Finally, BGP suffers some limitations in visibility. Simply grabbing traffic is nice, but bidirectional flows are better than unidirectional flows, and when you pull something off via DNS, you're pretty much guaranteed to grab all the traffic from that TCP session even if you stop any further poisoning attempts. Contrast that with BGP, which operates at Layer 3 and thus may cause the IP packets to reroute at any point when the TCP socket is still active.
So, does that mean its always better to attack DNS than BGP? Oh, you competitive people would like things to be so simple, wouldn't you
Pilosov and I talked for about a half hour at Defcon, and I've got nothing but respect for his work. Lets look at the other side of things for a moment. First, BGP controls how you route to your name server -- if not your recursive server, which may be inside your organization and thus immune to ext