Arbor Networks: Security to the Core

The folks at Wired published a story earlier today titled Revealed: The Internet’s Biggest Security Hole.  I recall seeing a pointer posted to the NANOG mailing list a few weeks back with some slides that were presumably the DEFCON presentation associated with the talk.  After a terse look at the slides, I quickly moved on believing nothing new was being presented.  Well, given the Wired article, and some other coverage of the talk, this was apparently news to some folks.

In a nutshell, the work they present explains not only how to hijack some arbitrary chunk of address space in the global routing system (e.g., YouTube, or AFOL-KE), but also, how to “intercept” traffic bound for that address space, and then get it back to the intended recipient, presumably in a manner that’s largely transparent to the recipient (i.e., a MITM attack enabled by BGP route hijacking).

So, I’ll preface the following comments with this: If this work helps get more folks concerned about the overwhelming insecurities that exist in the Internet routing system, that’s fantastic and I’m happy about that.  That said, let’s take a bit of a deeper look at what they’re presenting and discuss how novel each component, or such a system actually is.

I suppose there are about four things one could do when hijacking Internet address space:

• Basic route hijack – announce someone else’s address space and drop the traffic on the floor when it enters your network.  This is what appears to have occurred with Pakistan Telecom’s hijacking of YouTube space earlier this year, triggered by a more-specific (/24) route announcement.  This result is essentially a denial of service, and could result from either misconfiguration or intentional malice.  If you’re announcing a more-specific or most folks are preferring a hijacked route that’s of the same size space, then the victim will likely be able to identify the attack as a considerable drop in traffic occurs.  This could possibly be a partial hijack as well, if route announcements of the same length were advertised from the attacker and the rightful address owner.
• Partial route hijack with termination – here, you’d see something a bit more sinister, perhaps. Basically, you’d announce some address space and start serving web pages, or DNS queries, or similar content from the space, likely in a manner much akin to that of the original victim, either to intercept transactions, or inject malware, or analyze data for market reasons, or perhaps something fancy like to violate a “cyber cease fire”.  Those queries may be the same, or may be falsified.  Optimizations such as Anycasting lend themselves to better obscured partial route hijacks, and they’re much more difficult to detect than full more-specific route hijacks.  Ohh, but who’d do this you ask?  Well, ask the L-root Internet root DNS server operators.  That’s right, just a few months ago some folks starting announcing Internet L-root name server address space AND responding authoritatively as a root DNS name server.  [sarcasm]Fortunately, this only happened for six months or so before it was remedied.[/sarcasm]  Another common use for this model is termination of known botnet command and control (C&C) IPs to detect, contain, and possibly instrument compromised end systems.  
• Full route hijack with proxy or snooping – this is sorta what Alex and Tony presented at DEFCON, although it wasn’t quite what I’d consider “full” since some networks necessarily discarded the hijack route announcement as a result of their AS intentionally being contained in the AS path of the hijack BGP announcements (a root operator was said to have “blocked” access to one of their address blocks from a particular network in just this manner several years ago).  If you didn’t read the slides, the reason for this is so that you can use those networks to “on-ramp” the traffic back to the legitimate destination once you’re done molesting it, without introducing some forwarding loop in the network.  This isn’t new, however, as inter-provider botnet C&C infiltration was performed in just this manner by large ISPs years ago – it’s just that no one published a paper on it – for obvious reasons.  Furthermore, many intelligent filtering or “scrubbing” solutions (e.g., Arbor’s TMS) for DDoS attacks have used route diversion (I suppose you could call it hijacking, but it’s typically done with the consent of the address owner) and any of an array of “on-ramping” techniques to get traffic back to the target systems for over 5 years now.  Detection techniques would involve route table monitoring for new origin AS numbers, the introduction of more specific routes in the routing system, the existence of new paths in the routing system, ingress traffic shifts, and perhaps additional transaction latency or increased one-way propagation delay.
• Targeted route hijack with proxy or snooping – I suppose if you were going to do this and attempt to go undetected, you’d need to be very targeted yet not introduce significant new traffic flows or detectable shifts, minimize latency, and not introduce more-specific route announcements into the routing system, all of which may well be easily detected IF folks are paying attention.  The most effective way to do this would likely be to employ a dual-homed attacker AS that has one connection to the network from which you would like to intercept traffic (AS a), and the other to the network from which you’d like to receive (AS b).  You could easily forge an origin AS in a route announcement, and since most providers, if they filter at all, do so based on prefixes and NOT AS path, you’d be OK if you registered the route, and origin detection systems would likely not pick up the change. Furthermore, you could easily scope the announcement to the AS a network, either with a NO_EXPORT style technique, or perhaps community mechanisms akin to those outlined in RFC 1998.  Furthermore, because ISPs usually prefer routes from customers over routes from peers (e.g., via BGP LOCAL_PREF) you don’t need to announce one or several more-specific routes for the target network, you could announce the same prefix length.  You could also use their routing policy capabilities to send the routes only to their customers, or keep it just within that AS, or whatever you’d like.  Or, considering most providers filter customers explicitly and peers implicitly (i.e., not at all), you could do this at an Internet exchange point (IXP) as a peer towards target networks.  I’d venture to say that so long as the adjacent AS accepts the route announcement, there are an array of ways you could scope it’s propagation.

This entry was posted on Wednesday, August 27th, 2008 at 1:22 am and is filed under Arbor Networks, Botnets, Critical Infrastructure, Interesting Research, Vulnerabilities. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.