Arbor Networks: Security to the Core

While I didn’t make it to the NANOG 45 meeting this week in sunny Santo Domingo (bum knee on the mend), I did listen to quite a few of the talks remotely, and pulled most of the presentations for a cursory look.  I found one talk in particular, a lightning talk on Tuesday afternoon titled “BGP Spoofing in the Episode: Stealing Your (cc)TLD” given by Berislav Todorovic of KPN, quite interesting.

In a nutshell, Todorovic outlines:

1. An attack that first employs BGP route hijacking to hijack a DNS Top Level Domain (TLD) server prefix by advertising a more specific route (e.g., a prefix/24, versus legit_prefix/16) than currently exists for the legitimate TLD servers.  Because routing on the Internet always prefers the most specific prefix, all the traffic destined for hosts with prefix/24 is now forwarded towards the malicious destination.  Nothing new just yet…  Note: currently, /24 is pretty much the longest IPv4 prefix length you can propagate on the Internet and expect decent reachability; most of the Internet DNS roots are advertised as /24s.  Anything longer (i.e., /25 – /32) is usually filtered by most providers inter-domain.  Routing always prefers the most specific route, and if multiple sources are announcing, say, /24s, then other BGP metrics such as AS path length are considered, and traffic is usually distributed in some manner between the set of announcements.

2. In addition, you set up a DNS server responding to queries for the TLD and begin serving malicious records for queries, accomplishing essentially the same thing that your off the shelf poisoned DNS cache or rogue DNS resolvers would enable.  OK, simple enough.

3. The interesting twist is that those malicious records you’re serving have a few clever modifications, for example:

• Increase the Start of Authority (SOA) to a really high number.  The SOA is essentially a zone file revision number.  Normally, it’s incremented each time the contents of the zone change.  This lets secondary DNS servers know the zone has been updated and they need to pick up a new copy.
• Increase the TTL of all the Resource Records (RRs), which will ensure they’re held longer when cached, increasing cache pollution durations.
• Set all the other SOA timers (e.g., refresh, retry, expire) to a really large number, e.g., 100 years.  This will ensure that all the secondaries for the TLD don’t try to pickup another copy of the zone for a very long time, and they’ll need to be manually kicked to fix the problem.
• Serve the zones for a while and get the secondaries updated, and then you could kill the fake primary DNS server if you choose.
• After a while, the route hijack will be mitigated, but to prolong the impact and force folks to use the poisoned secondary servers, you could DDoS the primary server for a bit
• The cache pollution takes a REALLY long time to subside, and remains LONG after the route hijack itself has been mitigated.

Certainly, this would work for roots or (g|cc)TLDs, but it would also be a fine targeted attack against ANY authoritative name servers.  And the topological dependencies and targeted attack capabilities a cleverly crafted BGP advertisement would make detection by the legitimate domain owners extremely difficult.

As for fixes:

• DNSSEC will mitigate this threat, once _fully deployed, as poisoned records would be invalidated – though a DoS could still occur.  Until then…
• You’d better be watching for anomalous route announcements within your address blocks, and particularly those that contain your authoritative DNS zone servers, using any of a growing set of tools to help with this.  As the recent CTBC incident proves, the more perspectives you get, the better.  I suspect you’ve heard about most of the other route monitoring tools here in the past, so I’ll just plug New & Improved Cyclops this go round.
• External monitoring of zone file contents might be a good thing in the event that this were to occur, as it could aid in detecting and resolving poisoning sooner rather than later.  However, I’m not aware of any folks that do this at the moment.
• Todorovic recommends announcing more specific routes (e.g., /24s) for all the TLDs authoritative server prefixes, this really doesn’t fix the problem, it only makes route hijack-based attacks more fragmented, and arguably, more difficult to detect.  He makes a statement regarding routing table growth from this never being a real issues, and follows with “But will we ever have so that many TLD’s [that the routing table growth will be an issues]? Come on … “.  Well, if ICANN has anything to do with it, you might be seeing a slew of new gTLDs, some even later this year!  As such, I’m not a huge fan of this particular recommendation.
• Some other recommendations are made in the presentation as well, such as suggestions to protect zone transfers between primary and secondary servers, all of which seem prudent.
• Encourage more route filtering on the Internet, be sure to do it yourself and tighten up what you’ve got control of – or at least have a conversation with your ISPs on what you believe they should be doing here.  Coincidentally, Sandra Murphy (SPARTA & SIDR WG co-Chair) gave a lightning talk on Secure Inter-Domain Routing (SIDR) work in the IETF, something IP network operators SHOULD be providing feedback on at this stage.
• Be sure your incident response planning accommodates these types of threats – before they occur.  Having out-of-band contact information for your ISPs, and your national CERTs, can assist as well when issues such as this occur.

Anyway, I quite liked this presentation, and thought it was worth sharing here.  Thanks to Todorovic for doing this lightning talk..

This entry was posted on Friday, January 30th, 2009 at 12:36 am and is filed under Arbor Networks, Attacks, Critical Infrastructure, 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.