Security for the Internet’s Domain Name System (DNS)

1. Security for the Internet’s Domain Name System (DNS) Briefing for BITS 24 June 2005

2. Introduction • Attacks via and against the DNS infrastructure are increasing • Attacks are becoming costly and difficult to remedy • Consumer confidence in Internet accuracy is decreasing • The National Strategy to Secure Cyberspace (2003) recognized the DNS as a critical weakness • It called for the Department of Homeland Security to coordinate public-private partnerships to encourage the adoption of improved security protocols • The DNSSEC Deployment Initiative is one of these partnerships

3. The Department of Homeland Security DNSSEC Deployment Initiative • DHS Science and Technology (S&T) Directorate sponsors several Internet security initiatives including • DNS Security Extensions • Secure Protocols for the Routing Infrastructure • Protected Repository for the Defense of Infrastructure against Cyber Threats • DHS cannot secure the Internet • But is taking a leadership role in facilitating public-private partnerships that will result in a more secure Internet

4. DNSSEC Initiative Activities • Roadmap published in February 2005 • http://www.dnssec-deployment.org/roadmap.php • Multiple workshops held world-wide • DNSSEC testbed developed by • http://www-x.antd.nist.gov/dnssec/ • Formal publicity and awareness plan under development • Civilian government (.gov) developing policy and technical guidance for secure DNS operations and beginning deployment activities at all levels. • The “.us” and “.mil” zones are also on track for DNSSEC compliance

5. Background: DNS Attacks • Financial/large enterprises are seeing a significant increase in online attacks for fraudulent purposes • Hijacking (virtual theft of domain names) • Phishing (look-alike fraudulent emails and web sites) • Pharming (phishing combined with DNS attacks) • Other attacks include DNS name mismatches or browser tricks aimed at careless users: • Names with international characters that look like Latin equivalents in browser URL windows, for example • http://www.paypаl.com • http://www.miсrоsоft.com • Name mismatch in e-commerce certificates

6. SSL Name Mismatch Attack

7. www.robecodirect.nl www.robecoadvies.nl User Easily Misses DNS Name Mismatch on the SSL Certificate, Clicks “OK”

8. Breaking the Back of the Internet • Forged DNS data breaks most web applications • Genuine web sites can appear to be replaced with a false site without ever touching the original site • E-mail, b2b, backend applications can be re-routed or mis-delivered • Logins can be compromised through man in the middle attacks leading to identity theft • DNS attack tools are readily available on the Internet (for example, dsniff, dnshijack, and many more) and they are all FREE! • We’ll look at some real attacks in a moment…

9. DNS Software is Part of the Problem • There are many bugs in software and other issues underlying each specific attack • A protocol/infrastructure approach to DNS security is best: • Because it is infrastructural, it detects and addresses attacks independent of software holes • New bugs and holes will always arise, but with the right upfront work, the system is catching the attacks (and the bugs) before the damage mounts

10. net. com. os.net. money.net. zone kids.net. corp.money.net. hi.kids.net. nt.os.net bye.kids.net. unix.os.net dilbert.corp.money.net. mac.os.net market.corp.money.net. DNS Tutorial . domain

11. DNS Name Resolution Root Server TLD Server Zone Server Other Servers • Important “Other” servers include: • ISP • Enterprise • Hotel/travel • Public WLAN "End" user Local DNS Server

12. A Simple DNS Attack Easy to observe UDP DNS query sent while working in Airport Lounge’s Wireless LAN First response wins. Second response is silently dropped on the floor.

13. Recent Attacks: Barclay Wildcard • In this attack, a version of pharming, a user is presented with an encoded URL for a destination, which looks correct on common browsers • Is that a bug or a feature? • Even if users become weaned from reacting to pharming email, this URL might show correctly in dynamic click-ads • URL resolves to a redirector site in Russia

14. URL with Encoded Redirector • http://barclays.co.uk|snc9d8ynusktl2wpqxzn1anes89gi8z.dvdlinKs.at/pgcgc3p/ • Possible solutions: • “Fix” all browsers and people against these attacks (and each new one that gets invented) • Make the infrastructure generally robust against all redirection attacks • The second option is best

15. Barclay Wildcard http://news.netcraft.com/archives/2005/03/07/ phishers_use_wildcard_dns_to_build_convincing_bait_urls.html

16. Recent Attacks: ISP Cache Poisoning • DNS cache poisoning is an old problem but seems to continue unabated • Symantec products found to be vulnerable in March 2005 • Microsoft and BIND cache poisoning attacks in April 2005 • DNS bots in May 2005 • Details on a recent large DNS cache poisoning attack at http://isc.sans.org/presentations/dnspoisoning.php

17. Cache Poisoning – One Method • Attacker floods local DNS server with hundreds of queries for www.cnn.com • Attacker then floods DNS server with hundreds of spoofed replies that appear to come from ns.cnn.com (CNN’s authoritative name server) • Local DNS server is now “poisoned” with false data

18. Cache Poisoning – Another Method • Attacker sends a request to your local DNS asking it to resolve www.attacker.net • Your local DNS server queries ns.attacker.net for the data • ns.attacker.net replies, but also includes false information on www.cnn.com • Your DNS server caches the false data on www.cnn.com

19. ISP Cache Poisoning - Impacts • In March 2005 hundreds of DNS names were poisoned in a large attack, including • americanexpress.com, citicards.com, dhl-usa.com, fedex.com, walmart.com, sabre.com, and many more • Any of these may have had man-in-the-middle attacks such as stolen passwords or intercepted traffic • Lucrative spam, spyware and pay-per-click outcomes appear to be the motive

20. One Defensive Solution: DNSSEC • The DNS Security Extensions (DNSSEC) protocol provides a key ingredient in the defense against these attacks • Understanding these attacks and the risk-benefits of DNSSEC is critical • Taking action is similar to the run-up to Y2K • Except that we don’t have a firm deadline like December 31, 1999 to fix it • Requires cooperation between and among Internet users and service providers

21. What Does DNSSEC Do? • Provides an approach so DNS users can: • Validate that data they receive came from the correct originator Source Authenticity • Validate that data they receive is the data the originator put into the DNS Data Integrity • This approach integrates with existing server infrastructure and user clients • Maximized benefit when application software can determine if DNS data was received with authenticity and integrity

22. DNSSEC Overview • Each DNS zone signs their data with their private key • Signing should be done with zone data preparation • User queries are answered with: • the requested information • DNSSEC data for the requested information • Users authenticate responses with trusted key(s) • At least one trusted public key is pre-configured • Validation done with pre-configured key or keys learned via a sequence of queries to the DNS hierarchy • Enables and supports other security technologies

23. DNSSEC Risk-Cost Points • Attackers use DNS vectors to make money • Both the loss from the attack and the cost to the infrastructure can be significant • Cost to attacker is low or nothing, gain is high • Security always has costs • What is the risk-benefit? • Costs will include software, training, performance, and administrative relationships to zone operators

24. Stages for Next Steps and Discussion • Risk (and cost) analysis CRITICAL! • Test and engineering • Discussions with many communities, including with the relevant Top Level Domain registries • Production • Including communication with zone providers, registrars, governing agencies, and software vendors • Leadership in the private and public sectors

25. Background Information and Contributors • For lots of detailed information: • www.dnssec-deployment.org • www.dnssec.net • Authors of materials in this presentation (all from dnssec-deployment working group) • Amy Friedlander (Shinkuro) • Allison Mankin (Shinkuro) • Marcus Sachs (SRI) • Ed Lewis (Neustar) • Olaf Kolkman (Netlabs.nl) • Russ Mundy (Sparta)