# Presentation: 530379

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

- Briefing for BITS
- 24 June 2005

## 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

## 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

## 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

## 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&#1072;l.com
- http://www.mi&#1089;r&#1086;s&#1086;ft.com
- Name mismatch in e-commerce certificates

## SSL Name Mismatch Attack

## User Easily Misses DNS Name Mismatch on the SSL Certificate, Clicks “OK”

## 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...

## 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

## DNS Tutorial

**.**

**domain**

## DNS Name Resolution

- Root Server

- TLD Server

- "End" user

- Zone Server

- Local DNS Server

- Other Servers

- Important  “Other” servers include:
-   ISP
-   Enterprise
-   Hotel/travel
-   Public WLAN

## 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.   **

## 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

## 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

## Barclay Wildcard

- http://news.netcraft.com/archives/2005/03/07/
- phishers_use_wildcard_dns_to_build_convincing_bait_urls.html

## 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

## 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

## 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**

## 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

## 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

## 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

## 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

## 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

## 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

## 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)