Home > Security > The Emergence Of A Theme

The Emergence Of A Theme

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.


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 exterior routing protocol attack, then the authoritative servers your recursive servers depend on.  Something like this actually happened recently — witness the curious case of the Unauthorized L Roots, and note the astonishingly familiar potential attacks being described.  Yes, that’s precisely the scenario of BGP used to hijack root DNS servers — with such hijacking actually being noticed.

More importantly, much of my talk, in which I discuss the impacts of MITM attacks, applies to Kapela and Pilosov’s work as well.  It’s 2008, we still don’t have secure email, and that’s just as much of a problem in the face of BGP attacks as it is in the face of DNS attacks.

So, in summary, it’s an interesting side discussion regarding the similarities, differences, and overlaps between DNS and BGP attacks.   BGP has far fewer potential attackers, fewer necessary defenders, is a much less agile attack, and is way easier to monitor forensically (and indeed, with companies like Renesys, is being monitored forensically).  But so what?  It can work, and when it does, it can do much of the same damage we were afraid of via DNS.

We have now had three attacks, in one year, that underscore the fundamentally untrustworthy nature of routing.  DNS, BGP, and SNMPv3 all underscore the fact that the network should only be trusted as a best-effort data transmission system — that if you want to make sure everything’s OK, you can’t just assume — you need to cryptographically authenticate, you need to cryptographically encrypt, and you need to do these things to a level of security beyond “secure unless there’s an attacker.”

A lot of us — myself included, when I first started really looking at SSL — thought we were already distrusting the network.  We weren’t.  That’s what Mike Perry’s telling us, that’s what Mike Zusman’s telling us, and that’s what I’m telling you.

There are some real discussions to be had.  It’s 2008.  Where’s secure email?  Why is almost every autoupdater not from Microsoft thoroughly broken?  What is going on with non-browser network clients that can’t handle traffic from an untrusted server?  How are we going to migrate the web, and indeed all commercial network activity, to authenticated and encrypted protocols that respect the fundamentally untrustworthy nature of the network?

DNS vs. BGP vs. SNMPv3 is inside baseball.  The reality is as follows:

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.

The question is what to do about it.

(That all being said, I’ll be writing shortly with an update on defenses against DNS.  There be news.)

Categories: Security
  1. August 27, 2008 at 2:27 pm

    I really like the way you tie all of these together, and I think something will have to build this way before the masses see it as an issue. The bury our head in the sand routine is never the right way to deal with security, but it’s how I still see things occurring. No wonder so much personal data is being lost by companies trusted to store/share it.

    I’ll be reading your next post on DNS defenses, thanks.

  2. August 27, 2008 at 3:19 pm

    why you say: “almost every autoupdater not from Microsoft thoroughly broken?”, in which way is MS superior in this subject?

  3. August 27, 2008 at 5:53 pm

    There are a ton of security issues facing the internet today. It is especially true when there are multiple vulnerabilities that work together to produce a combined risk that is greater than the sum of all of the vulnerabilities. Unfortunately there are a lot of things aligned for a perfect storm. This article is definitely on target.

  4. S
    August 28, 2008 at 2:38 am

    Those Pirate Bay guys have a nice idea, trying to get all IP traffic encrypted from the net stack up.

  5. neill
    August 29, 2008 at 7:08 am

    one could also argue that implementing security always costs money, and breaking that even more (if possible), and the DOD/ARPA/DHS/NSA and else had no benefit from changing the (non)existing security … and the ISP tried to max profits and not spend more $ either, kept quite and their fingers crossed that no whistleblower would speak up

  6. August 31, 2008 at 2:34 am

    I just had a quick look at the windows update service, it only makes calls on port 80, how is that secure. Even if they are signing there packages, how hard is it to push out an update to look for a new signing key that is owned by the attacker?

  7. August 31, 2008 at 3:02 am


    Welcome to why Windows Update is impressive. It’s correctly difficult for an attacker to gin up a signing key, or even signed packages, that’ll work in the wrong context.

  8. Ryan Duff
    September 4, 2008 at 1:52 pm


    I think the answer is to treat data the same way the government does with their classified systems. Have all data encrypted before it hits the “outside world” and then decrypted at its destination. The most logical place to do this would be at the ISP level (but could even be done at the users home router, their cable/dsl modem, or even built in to the users system). However, the setup for this would be astronomical (but I think any true fix is going to be). It would require global participation (just like filtering to fix the BGP issue) and would be very costly.

    The problem with all of these bugs is that they are in protocols that are heavily relied on to work the way they do (almost like you NEED the bug to be there to function how it was intended). All of these issues would require a massive overhaul to fix.

  9. September 5, 2008 at 7:12 am

    Exactly, Ryan a massive amount of funding will be needed to complete this project but it is worth keeping the ‘Net more safe and secure. The combination approach is the only way in my view. It must be the government’s job, it must be the isp’s job and finally it must be the consumer’s job to help keep the internet safe and secure. I would really even like some kind of requirement like a driver’s license for people to even use computers these days so that complete idiots could be weeded out from the mix and then a simple test or 2 or 3 could determine if the user is safe enough to use the computer. I do not know how this could be implemented well but it would be nice to have some sort of requirement like this so at least the computer users would have some clue as to how computers are used.

  10. Lennie
    September 15, 2008 at 1:33 pm

    Easiest way to attack windows update is with a trojan on the PC, add an extra root-cert or similair and then spoof DNS. Maybe it’s even enough for the user to click on OK when visiting a website that asks the user if they want to trust it anyway even though it’s not trusted (to install that new root-certificate).

  11. September 18, 2008 at 12:21 pm

    In reply to Morgan Storey’s post: “Even if they are signing there packages, how hard is it to push out an update to look for a new signing key that is owned by the attacker”

    … its a chicken-and-the-egg problem. If the update packages are signed then you can’t send an update that changes the signature detection code as it would have to pass the signature validation in the first place.

  12. September 23, 2008 at 11:59 am

    How do we as computer users work as a team or even many teams to be able to overcome the compromised computers on the ‘Net that work as one in a spybot network and spybot networks that are trying and in some cases succeeding in breaking into banks, credit card companies, other private businesses and even some government web sites. Is there some way that decent and good computer users can work as one to bring all of our computing power against the spybot networks to bring them down and bring education to the people to let them be more aware and able to see threats coming but not overwhelm them with information. Would including booklets and or cds with good and safe free-ware programs like Mozilla Firefox, web browser and or Ubuntu Linux, a free open source operating system and or Spywareblaster a good free anti-spyware program with manual updating program help users to make better and more informed decisions or would it just lead them to be more overwhelmed?

  13. scoperchiatore
    September 26, 2008 at 2:45 am

    I really appreciated this post; it is a precious and remarkable analysis. Apart from security considerations, you depicted a complex situation withouth forgetting any important issue. Many compliments.

    A little contribution: you said BGP events are more logged/traced than DNS events. This is definitely true, and the existence of many analyzers like
    remarks your consideration. I worked much time over one of those tool, and then I became and eth-hack.

    I think that even if some sort of “serious” BGP attack could really have and enourmus impact, it will be localized (and perhaps resolved) in some way. On the other hand, i am not aware of any tool capable to observe a serious DNS/SNMP/key based compromission of many hosts/routers in a world perspective like BGP-tools do. To spot those kind of attacks we need to rely on organizations logging and filtering policies/procedures/processes.

  1. August 29, 2008 at 4:34 am
  2. August 30, 2008 at 4:12 am
  3. August 30, 2008 at 12:05 pm
  4. August 31, 2008 at 11:11 am
  5. September 1, 2008 at 3:53 am

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: