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.
|Do you explicitly filter routes announced to you by customers?|
|Other (please explain)||12.90%|
|Do you explicitly filter routes announced to you by peers (not customer peers)?|
|Other (please explain)||12.90%|
If folks don’t filter, of course you can advertise routes openly and assert reachability and/or ownership for pretty much any address space on the Internet you want. What you do from there, well, molest at will. Unfortunately, as noted in a recent NANOG panel, the state of filtering has done nothing but deteriorate over the past 15 years.
With any luck, the RPKI and SIDR efforts will take hold, as the Regional Internet Registry (RIR) development efforts are well under way and much needed. And unquestionably, until some formally verifiable source for who owns what address space exists on the Internet, verifying who is authorized to assert Internet routing reachability or provide transit services for that address space is going to be challenging at best. I applaud DHS efforts in seeding work in this area, and am thrilled several of the RIRs seem to working on RPKI infrastructure development. Now, it’s time for the ISPs to step up and be ready to employ this infrastructure for routing filtering. For that matter, use it for source address verification as well, and snuff most of those IP source address spoofing attacks while you’re at it (e.g., Kaminsky’s DNS cache poisoning stuff).
There’s no shortage of NANOG and other related papers and talks on these topics over the past 20 years, and I see nothing particularly new revealed in this talk – well, at least nothing new for the folks that were paying attention. The one clever bit that I did see from their work is how they used AS prepending not to selectively break connectivity to a given target AS, but instead, to preserve the native forwarding path inter-domain. There are many ways you could do this, but AS prepending didn’t come to mind when I was thinking about it, and I’ve not seen that method employed in practice (although perhaps because the other techniques are arguably simpler to implement).
This also should serve as a reminder for folks that if you have any expectations of transaction privacy on the Internet, you should be employing end-end encryption (e.g., IPSEC).
However, I do hope the flag waving garners more attention for the topic, as it, coupled with some DNS security issues and source address spoofing, are unquestionably, the largest vulnerabilities to the Internet infrastructure today.