CNIT 40: 3: DNS vulnerabilities
0 likes1,349 views
The document details various vulnerabilities in DNS, including configuration errors, architecture mistakes, and software weaknesses that can lead to denial of service and information leakage. It emphasizes the importance of proper server configuration, limiting recursive access, and using security features to mitigate attacks. Specific examples of vulnerabilities, such as DNS cache poisoning and the consequences of the Kaminsky attack, illustrate the risks associated with poorly secured DNS implementations.
CNIT 40: 3: DNS vulnerabilities
- 1. Ch 3: DNS Vulnerabilities Updated 9-27-16
- 2. Causes of Vulnerabilities • Configuration errors • Architecture mistakes • Vulnerable software implementations • Protocol weaknesses • Failure to use the security extensions in the protocol
- 4. Single Point of Failure • The SOA could be a single server at a single site – If the server crashes, clients would be unable to resolve any of the domains in the zone – Also Internet connection outage, power failure, fire, storm, etc. • If a single server is the recursive resolver for clients in an intranet – They'll all lose DNS service if it goes gown
- 5. Two Servers • Many hosting providers do not allow delegation of DNS service to a single DNS server name • End devices are typically provisioned with two DNS server addresses
- 7. Data Center or Single Site • If all DNS servers are at a single site or data center, a regional event could take them all down – Earthquake – Power failure • The more critical the DNS service is, the more distributed servers should be – Geographically and topologically – Like the 13 root servers
- 9. Exposure of Internal Information • Only public Web-facing servers should be in the external DNS zone files • Your DNS server is a target of attack and may be compromised
- 11. Leakage of Internal Queries to the Internet • Some Windows DHCP clients leak dynamic DNS updates to the Internet – Link Ch 3a
- 12. Windows Versions • These packets were sent from Windows 2000, Windows XP, and Server 2003 – When tested in 2006 • To prevent this, configure local DNS servers not to refer internal machines to external name servers – And block DNS requests directly to the Internet
- 13. Unnecessary Recursiveness • Not all name servers need to be recursive – Authoritative servers don't need to – Recursion is complex and burdens servers – Added function means more potential vulnerabilities • Recursion may be on by default – Thousands of open recursive resolvers on the Internet
- 14. Failure to Restrict Access • Recursive DNS servers should only accept queries from your own clients – Block outside addresses with access control lists
- 15. Open Resolver Project • Link Ch 3b
- 16. Testing CCSF's DNS Servers in 2016
- 17. Testing CCSF's DNS Servers • All are closed as of 9-27-16
- 18. Unprotected Zone Transfers • Data transfers from a master to a slave authoritative server – Update the zone files on the slave • Can be requested by any other host • Reveals information about all hosts in the zone – Information disclosure vulnerability
- 19. North Korea • Link Ch 3i
- 20. Running Server in Privileged Mode • root on Unix/Linux • Administrator on Windows – Makes any security flaws more dangerous – Attacker who owns DNS then owns the server
- 21. Weakness in Software Implementations • DNS servers have bugs and vulnerabilities – Buffer overflows – Other errors • Search CVE List for "ISC Bind"
- 23. Severe 2008 Bind Vulnerability • Attack used an IP address like – 1.2.3.4.xxxxxxxx-exploit-code-here-xxxx • Another list of DNS vulns at link Ch 3d
- 24. Source Port Randomization • Good video • Link Ch 3e
- 25. Randomness of Transaction ID • Each DNS query and response has a TXID field – 16 bits long (65,536 possible values) – Should be random • Bind 8 & 9 used predictable transaction IDs – So only ten guesses were needed to spoof the reply
- 26. Randomness of Transaction ID
- 27. Tricking a Target into Using Your DNS Server • Run a domain evil.com with a SOA you control ns1.evil.com – Send the target an email with a link to server.evil.com and hope someone clicks it – Send email from joe@evil.com to target email address • The server will automatically perform a reverse lookup to detect spam
- 28. Tricking a Target into Making Multiple DNS Queries • CNAME Chaining – www.evil.com is a CNAME for www1.evil.com – www1.evil.com is a CNAME for www2.evil.com – www2.evil.com is a CNAME for www3.evil.com – etc.
- 29. Tricking a Target into Making Multiple DNS Queries • NS Referral Chaining and NS Chains – a.a.a.a.evil.com has SOA ns.evil.com – ns.evil.com delegates to ns.a.evil.com – ns.a.evil.com delegates to ns.a.a.evil.com – etc.
- 31. Weak Authentication • DNS uses these elements to match a request and a response – Transaction ID (16 bits) – Question – Source and destination IP – Source and destination ports • But request destination port is known (53) • Client accepts the first response that meets these criteria, and caches the result
- 32. DNS Cache Poisoning • A false response that tricks the client puts a false entry into its cache
- 33. DNS Cache Poisoning Attacker 1.2.3.4 DNS Resolver Target Where is www.yahoo.com?www.yahoo.com is at 1.2.3.4 Where is www.yahoo.com? www.yahoo.com is at 1.2.3.4
- 34. • Link Ch 3f
- 35. • Link Ch 3g
- 36. Consequences of the Kaminsky Attack • Attack can be placed in a Web page – Many img tags – <img src=aaaa.paypal.com> – <img src=aaab.paypal.com> – <img src=aaac.paypal.com> – <img src=aaad.paypal.com> – etc. • If one Comcast customer views that page, all other Comcast customers will be sent to the fake paypal.com • Poisoning can take as few as 10 seconds
- 37. Man-in-the-Middle Attacks • Attacker in the middle has enough info to perfectly forge responses – Unless DNSSEC is used Attacker DNS ResolverTarget
- 38. DNS as a DoS Amplifier • Small requests lead to large responses • UDP allows spoofing the source IP address AttackerOpen DNS ResolverTarget