DNS security

How DNS works Ask local resolver first about name->IP mapping – It returns info from cache if any If info not in cache, resolver asks servers in DNS hierarchy that are authoritative for a given domain – Start from root, root sends it to the next point in hierarchy – End at authoritative server for the domain you are asking about (auth) – Resolver caches the replies

DNS hijacking Wait for resolver (target) to ask about a name from the victim’s domain – Provide your own reply faster than auth server – Provide some extra information (IP of auth server) This poisons the cache at that resolver, not globally – But if the resolver is at the important/large network the victim can lose a lot of traffic to the attacker Attacker’s goal: impersonate the victim (phishing)

Shortcircuiting waiting Ask the target resolver about some name from the victim’s domain – Doesn’t have to be the name you intend to hijack since DNS will take extra info in the reply – Asking about non-existing names guarantees they are not in resolver’s cache already Can ask about different domains too

Cache poisoning 2 IP for (attacker asks target, target asks attackNS) Don’t know, ns.victim.com is auth for victim.com, its IP is (attackNS’s reply) Target stores ns.victim.com-> in cache Victim attacker attackN S target Hijack entire domain

Defenses Only accept auth if its domain is same about the domain you asked for Don’t accept extra info in the reply if you did not ask for it

Cache poisoning 3 IP for (attacker asks target, target asks victimNS).victim.com Attacker replies faster than the victimNS – … -> (attacker’s reply) Target stores in cache Victim attacker attackN S target Hijack one name

Cache poisoning 4 IP for madeup.victim.com (attacker asks target, target asks victimNS)madeup.victim.com Attacker replies faster than the victimNS – … ns.victim.com is auth for victim.com, its IP is (attacker’s reply) Target stores ns.victim.com-> in cache Hijack entire domain Victim attacker attackN S target

Being faster is not enough Target will only accept replies that – Come to the specific port from which requests are sent – Come with the replyID same as the requestID – Attacker doesn’t get the requests directly Can try to sniff the info Can try to guess the info If the resolver accepts the reply it will accept extra info in reply too even if it has a different version in cache

Hijacking with sniffing If on the same network as the target, attacker can try to ARP spoof the next hop – Position itself on the path of target’s requests – DNS traffic uses UDP and is not encrypted, easy to see port and request ID and provide appropriate reply

Hijacking with guessing If target uses predictable numbers for source port and request ID attacker can perform many attacks, each time trying to guess the right port/replyID combination – Having randomness in one is not enough (2 16 tries) – Kaminsky attack (cache poisoning 4 + no randomness in source port)

Defenses Randomize source port – Makes guessing harder but not impossible Use DNSSEC – Replies must be signed by auth – Everyone can check signatures – Auth servers for zones sign certificates when they delegate a sub-zone (e.g..com for example.com) – Requires clients to implement DNSSEC to verify replies

DNSSEC Auth stores two more record types – RRSIG – signature for each A record – DNSKEY – public key to verify the signature Auth inserts one record into parent in DNS hierarchy – DS – says who is authoritative for a given subdomain and gives a hash of the public key (DNSKEY of auth) Resolver sets a bit asking for DNSSEC replies – Verifies each DNSKEY using DS from the level higher in hierarchy – Verifies RRSIG of the record

DNSSEC If no record exists auth returns a long reply to prove this fact – Intent was to just provide “does not exist” reply that is specific to a given query (otherwise it could be replayed to deny existence of real names) –.. and to provide it without online signing – Thus DNSSEC provides a list of all records (in a range) that would house such record if it existed This can be misused for reflector DDoS attacks – Large amplification factor This can be misused to map a network

BGP security some slides borrowed from Jen Rexford (Princeton U)

How does BGP work AS-level (autonomous system, collection of networks under single administrative org) Relationships (usually private info) – Customer/provider (customers pay to providers) – Peer-to-peer (peers do not pay each other) Each AS announces routes it knows including entire AS path to the destination – All routes announced to customers and providers – Customer routes announced to peers Each AS can choose which routes to adopt – Preference given to customer routes, then peer, then provider – Preference given to short routes

How does BGP work Routers from neighbor ASes exchange periodic updates using TCP sessions – If TCP session dies (e.g., RST) or HELLO messages are absent assume all routes announced by neighbor are not valid anymore Withdraw your announcements of those routes Creates a rippling effect in the Internet

BGP prefix hijacking An AS announces itself – As origin of a prefix it doesn’t own – As being close to the origin of a prefix Attracts the prefix’s traffic – Can drop it (blackholing) – Can reroute it to prefix (interception)

19 Prefix Hijacking /16 Originating someone else’s prefix –What fraction of the Internet believes it?

Sub-Prefix Hijacking Originating a more-specific prefix –Every AS picks the bogus route for that prefix –Traffic follows the longest matching prefix / /24

Why is BGP hijacking hard to handle Malicious routes do not propagate to source –Source cannot observe the problem easily Even if source can observe the problem it is hard to fix –No automatic fix – source’s announcements count as much as anyone else’s once they leave the source –Must go through human channels Interception attacks are very hard to detect Source of attacks is not just maliciousness – often it is misconfiguration 21

February 24, 2008, YouTube Outage YouTube (AS 36561) –Web site –Address block /22 Pakistan Telecom (AS 17557) –Receives government order to block access to YouTube –Starts announcing /24 to provider (AS 3491) –All packets directed to YouTube get dropped on the floor Mistakes were made –AS 17557: announcing to everyone, not just customers –AS 3491: not filtering routes announced by AS (will come back to this later) Lasted 100 minutes for some, 2 hours for others 22

23 Timeline (UTC Time) 18:47:45 – First evidence of hijacked /24 route propagating in Asia 18:48:00 –Several big trans-Pacific providers carrying the route 18:49:30 –Bogus route fully propagated 20:07:25 –YouTube starts advertising the /24 to attract traffic back 20:08:30 –Many (but not all) providers are using the valid route

24 Timeline (UTC Time) 20:18:43 –YouTube starts announcing two more-specific /25 routes 20:19:37 –Some more providers start using the /25 routes 20:50:59 –AS starts prepending (“ ”) –Prepending makes routes longer, less desirable 20:59:39 –AS 3491 disconnects AS :00:00 –All is well, videos of cats flushing toilets are available

25 Lessons From the Example BGP is incredibly vulnerable –Local actions have serious global consequences –Propagating misinformation is surprisingly easy Fixing the problem required vigilance –Monitoring to detect and diagnose the problem –Immediate action to (try to) attract the traffic back –Longer-term cooperation to block/disable the attack Preventing these problems is even harder –Require all ASes to perform defensive filtering? –Automatically detect and stop bogus route? –Require proof of ownership of the address block?

Solution Techniques Protective filtering –Know your neighbors Anomaly detection –Suspect the unexpected Checking against registries –Establish ground truth for prefix origination –May not be up to date Signing and verifying –Prevent bogus AS PATHs Data-plane verification –Ensure the path is actually followed 26

27 Defensive Filtering Filter announcements from customers that are not for customer prefixes Filter announcements from customers that have a large AS on the path Keep history of prefix origins and prefer bindings that are long-lived –Could do the same for adjacencies in AS paths –This violates the basic idea of routing – resiliency –Doesn’t work on closeness attacks Not everyone does this

28 BGP session runs over TCP – TCP connection between neighboring routers – BGP messages sent over TCP connection – Makes BGP vulnerable to attacks on TCP Main kinds of attacks – Against confidentiality: eavesdropping – Against integrity: tampering – Against performance: denial-of-service Main defenses – Message authentication or encryption – Limiting access to physical path between routers – Defensive filtering to block unexpected packets Attacking BGP Sessions

29 Denial-of-Service Attacks, Part 1 Overload the link between the routers – To cause packet loss and delay – … disrupting the performance of the BGP session Relatively easy to do – Can send traffic between end hosts – As long as the packets traverse the link – (which you can figure out from traceroute) Easy to defend – Give higher priority to BGP packets – E.g., by putting packets in separate queue BGP session physical link

30 Denial-of-Service Attacks, Part 2 Third party sends bogus TCP packets – FIN/RST to close the session – SYN flooding to overload the router Leads to disruptions in BGP – Session reset, causing transient routing changes – Route-flapping, changing routes back and forth Reasons why it may be hard – Spoofing TCP packets the right way is hard Difficult to send FIN/RST with the right TCP header – Packet filters may block the SYN flooding Filter packets to BGP port from unexpected source … or destined to router from unexpected source Turn on SYN cookies

31 Exploiting the IP TTL Field BGP speakers are usually one hop apart – To thwart an attacker, can check that the packets carrying the BGP message have not traveled far IP Time-to-Live (TTL) field – Decremented once per hop – Avoids packets staying in network forever Generalized TTL Security Mechanism (RFC 3682) – Send BGP packets with initial TTL of 255 – Receiving BGP speaker checks that TTL is 254 – … and flags and/or discards the packet others Hard for third-party to inject packets remotely