U-M EECS 588 - Risks and Security for the Domain Name System

Unformatted text preview:

Risks and Security for the DomainName SystemBOF for Joint Techs20 July [email protected]• Attacks via and against the DNS infrastructure areincreasing– Attacks are becoming costly and difficult to remedy– User confidence in Internet accuracy is decreasing• The U.S. National Strategy to Secure Cyberspace(2003) recognized the DNS as a critical weakness– It called for coordinated public-private partnerships toencourage the adoption of improved security protocols– The DNSSEC Deployment Initiative is one of thesepartnerships (not U.S. only)•Open to all ready to implement (details later)Breaking Network Trust• Forged DNS data breaks applications– Genuine web sites can be replaced with a false site withoutever touching the original site, but more insidiously theoriginal site can be reached after stopping at a site thatperforms a malicious act.– E-mail and every other application (trusted backend andsystem security, included) can be re-routed or mis-delivered– Logins including ssh can be compromised through man in themiddle attacks leading to identity theft• DNS attack tools are readily available on the Internet(for example, dsniff, dnshijack, and many more) andthey are all FREE!• We’ll look at recent real attack in a moment…DNS Software is Part of the Problem• There are many bugs in software and otherissues underlying each specific attack• A protocol/infrastructure approach to DNSsecurity is best:– Because it is infrastructural, it detects andaddresses attacks independent of software holes– New bugs and holes will always arise, but withthe right upfront work, the system is catchingthe attacks (and the bugs) before the damagemountszoneSample DNS Treemoney.net.kids.net.corp.money.net.market.corp.money.net.dilbert.corp.money.net.unix.os.netmac.os.netnt.os.netos.net.net. com.bye.kids.net.hi.kids.net..domainSOURCE: RUSS MUNDYWhat Does DNSSEC Do?• Provides an approach so DNS users can:– Validate that data they receive came from the correctoriginator Source Authenticity– Validate that data they receive is the data the originatorput into the DNS Data Integrity– Ensure that the absence of a record is validated• This approach integrates with existing serverinfrastructure and user clients.• Maximized benefit when application softwareintegrates (e.g. DNSSEC-aware DKIM), but dumbAPI also important.What Doesn’t DNSSEC Do?• It does not prevent attacks, it only detects, and it does notdo anything to affect most phishing, where the userchooses a valid site, just not one that makes sense for theirapplication.• Applications needing end user response need abreakthrough on human factors - DNSSEC-awareapplications have this need as well as certificate-basedapplications securityDNS Name ResolutionRoot Server TLD Server"End" userZone ServerLocal DNS ServerOther ServersImportant “Other”servers include:• ISP• Enterprise• Hotel/travel• Public WLANProcess-in-the-middle (aka Evil Twin)DNS query sent while working in AirportLounge’s Wireless LANFirst response wins. Second response is silently dropped on thefloor. Site may relay to true destination after malicious act.Recent Live Attack: ISPForwarder Cache Poisoning• DNS cache poisoning is an old problem but seemsto continue unabated– Symantec products found to be vulnerable in March2005– Microsoft and Linux BIND cache poisoning attacks inApril 2005– DNS bots in May 2005• Details on a recent widespread attack affecting manyconsumer ISP DNS servers athttp://isc.sans.org/presentations/dnspoisoning.phpCache Poisoning – Old Problem• Attacker floods local DNS server with hundreds of queriesfor www.cnn.com• Attacker then floods DNS server with hundreds of spoofedreplies that appear to come from ns.cnn.com (CNN’sauthoritative name server)• Local DNS server is now “poisoned” with false dataCache Poisoning – Another Method• Attacker sends a request to your local DNS asking it to resolvewww.attacker.net• Your local DNS server queries ns.attacker.net for the data• ns.attacker.net replies, but also includes false information onwww.cnn.com• Your DNS server caches the false data on www.cnn.comCache Poisoning – New Hybrid• Attacker devised spam with a “bait” address.• The record at the zone for this contained asadditional material a false domain name for the.com server.• Large numbers of small ISPs with susceptibleconsumers and not highly active DNS operationshad .com lookups spoofed through man-in-the-middle (MITM).• MITM was used in at least three ways: click-to-pay fraud, spyware installation, and spam sendinginstallation.• DNSSEC would have detected the attack in usefor all of this (and what else)?–The DNS attack was meant to go undetected.March-April ISP Attack -Impacts• Many of the ISP users had specific spyware, orspam and pay-per-click trojans, from redirectionsites (the apparent motivations for the attacks).• Hundreds of DNS names were found spoofed inthe ISP caches where data was recovered,including– americanexpress.com, citicards.com, dhl-usa.com,fedex.com, walmart.com, sabre.com, and many more– Any of these could have had man-in-the-middle attackssuch as stolen passwords or intercepted traffic (no data)DNS Software Bugs• DNS implementations have fixed many bugs that canlead to cache poisoning, including (supposedly)exploiting the additional information field. But…• Possible solutions:– “Fix” all software releases against these and future attacks or :– Make the infrastructure generally robust against redirection• Because old software will be out there• And new vulnerabilities will be discovered• The second option is best•The same point applies to browsers and user behaviorExample SSL Attack: Dutch WebsiteCREDIT: OLAF KOLKMANCREDIT: OLAF KOLKMANCREDIT: OLAF KOLKMANwww.robecodirect.nlwww.robecoadvies.nlUser Easily Misses DNS Name Mismatch onthe SSL Certificate, Clicks “OK”CREDIT: OLAF KOLKMANDNSSEC Status• The DNS Security Extensions (DNSSEC) protocol isnow mature.– IETF RFCs 4033, 4034 and 4035 represent thorough testing ofa simplified deployable protocol• Implementations are up-to-date with those RFCs inBIND 9.3 (9.4 soon) and NSD 2• Discussions with Microsoft will probably lead to a client-side (dumb API) in near-term.• IETF DNSSEC operations guideline has been finished byits working group.• A protocol addition may come: a new record to avoidzone-walking. Does not


View Full Document

U-M EECS 588 - Risks and Security for the Domain Name System

Download Risks and Security for the Domain Name System
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Risks and Security for the Domain Name System and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Risks and Security for the Domain Name System 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?