Causes of Vulnerabilities Configuration errors Architecture mistakes Vulnerable software implementations Protocol weaknesses Failure to use the security extensions in the protocol DNS Architecture Mistakes ID: 1045631
Download Presentation The PPT/PDF document "Ch 3: DNS Vulnerabilities" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
1. Ch 3: DNS Vulnerabilities
2. Causes of VulnerabilitiesConfiguration errorsArchitecture mistakesVulnerable software implementationsProtocol weaknessesFailure to use the security extensions in the protocol
3. DNS Architecture Mistakes
4. Single Point of FailureThe SOA could be a single server at a single siteIf the server crashes, clients would be unable to resolve any of the domains in the zoneAlso Internet connection outage, power failure, fire, storm, etc.If a single server is the recursive resolver for clients in an intranetThey'll all lose DNS service if it goes gown
5. Two ServersMany hosting providers do not allow delegation of DNS service to a single DNS server nameEnd devices are typically provisioned with two DNS server addresses
6. Router or Link
7. Data Center or Single SiteIf all DNS servers are at a single site or data center, a regional event could take them all downEarthquakePower failureThe more critical the DNS service is, the more distributed servers should beGeographically and topologicallyLike the 13 root servers
8. Common Configuration Errors
9. Exposure of Internal InformationOnly public Web-facing servers should be in the external DNS zone filesYour DNS server is a target of attack and may be compromised
10.
11. Leakage of Internal Queriesto the InternetSome Windows DHCP clients leak dynamic DNS updates to the InternetLink Ch 3a
12. Windows VersionsThese packets were sent from Windows 2000, Windows XP, and Server 2003 When tested in 2006To prevent this, configure local DNS servers not to refer internal machines to external name serversAnd block DNS requests directly to the Internet
13. Unnecessary RecursivenessNot all name servers need to be recursiveAuthoritative servers don't need toRecursion is complex and burdens serversAdded function means more potential vulnerabilitiesRecursion may be on by defaultThousands of open recursive resolvers on the Internet
14. Failure to Restrict AccessRecursive DNS servers should only accept queries from your own clientsBlock outside addresses with access control lists
15. Open Resolver ProjectLink Ch 3b
16. Testing CCSF's DNS Serversdig ns ccsf.edu shows 6 serversns5.cenic.org 137.164.29.69 CLOSEDns4.cenic.org 137.164.29.67 CLOSEDrudra3.ccsf.cc.ca.us 147.144.3.238 CLOSEDns6.cenic.org 198.188.255.193 CLOSEDns1.csu.net 130.150.102.100 OPENns3.csu.net 137.145.204.10 OPEN
17. Unprotected Zone TransfersData transfers from a master to a slave authoritative serverUpdate the zone files on the slaveCan be requested by any other hostReveals information about all hosts in the zoneInformation disclosure vulnerability
18. Running Server in Privileged Moderoot on Unix/LinuxAdministrator on WindowsMakes any security flaws more dangerousAttacker who owns DNS then owns the server
19. Weakness in Software ImplementationsDNS servers have bugs and vulnerabilitiesBuffer overflowsOther errorsSearch CVE List for "ISC Bind"
20.
21. Severe 2008 Bind VulnerabilityAttack used an IP address like 1.2.3.4.xxxxxxxx-exploit-code-here-xxxxAnother list of DNS vulns at link Ch 3d
22. Source Port RandomizationGood videoLink Ch 3e
23. Randomness of Transaction IDEach DNS query and response has a TXID field16 bits long (65,536 possible values)Should be randomBind 8 & 9 used predictable transaction IDsSo only ten guesses were needed to spoof the reply
24. Randomness of Transaction ID
25. Tricking a Target into Using Your DNS ServerRun a domain evil.com with a SOA you control ns1.evil.comSend the target an email with a link to server.evil.com and hope someone clicks itSend email from joe@evil.com to target email addressThe server will automatically perform a reverse lookup to detect spam
26. Tricking a Target into Making Multiple DNS QueriesCNAME Chainingwww.evil.com is a CNAME for www1.evil.comwww1.evil.com is a CNAME for www2.evil.comwww2.evil.com is a CNAME for www3.evil.cometc.
27. Tricking a Target into Making Multiple DNS QueriesNS Referral Chaining and NS Chainsa.a.a.a.evil.com has SOA ns.evil.comns.evil.com delegates to ns.a.evil.comns.a.evil.com delegates to ns.a.a.evil.cometc.
28. Protocol Design Weaknesses
29. Weak AuthenticationDNS uses these elements to match a request and a responseTransaction ID (16 bits)QuestionSource and destination IPSource and destination portsBut request destination port is known (53)Client accepts the first response that meets these criteria, and caches the result
30. DNS Cache PoisoningA false response that tricks the client puts a false entry into its cache
31. DNS Cache PoisoningAttacker1.2.3.4DNS ResolverTargetWhere is www.yahoo.com?www.yahoo.com is at 1.2.3.4Where is www.yahoo.com?www.yahoo.com is at 1.2.3.4
32. Link Ch 3f
33. Link Ch 3g
34. Consequences of the Kaminsky AttackAttack can be placed in a Web pageMany 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.comPoisoning can take as few as 10 seconds
35. Man-in-the-Middle AttacksAttacker in the middle has enough info to perfectly forge responsesUnless DNSSEC is usedAttackerDNS ResolverTarget
36. DNS as a DoS AmplifierSmall requests lead to large responsesUDP allows spoofing the source IP addressAttackerOpen DNS ResolverTarget