cnt 5410 - computer and network security: dns security · southeastern security for enterprise and...

Southeastern Security for Enterprise and Infrastructure (SENSEI) Center

CNT 5410 - Computer and Network Security:

DNS Security

Professor Kevin Butler Fall 2015


Reminders• Related Works are due today.

• Remember, quality matters in everything that you do, from matters technical to presentation!

• Midterm next week! : - /

2


Address Translation• The Internet relies on IP addresses for routing and delivering traffic.

• Efficient encoding makes the job of routers easy, and keeps routing tables small due to aggregation.

• When the Internet consisted of only a small number of hosts, such a solution was sufficient.

• Anyone could memorize the addresses of the 8 machines that could possibly talk to each other.

• Unfortunately, IP addresses are not memorable at scale.

• Very quickly, it was realized that some mechanism would be required to manage the translation from easy to remember namesto routing-optimized IPv4 addresses.

3


hosts.conf• The first mechanism was, HOSTS.TXT (a.k.a. hosts.conf),

a file stored on every Internet connected computer.

• Once in a while, that file would need to be updated with a current list of all of the hosts on the Internet.

• Network administrators would often have to physically deliver this update to every machine in their domain.

• Scalability quickly made this approach obsolete.

• That said, your machines still have hosts.conf, which you can use to statically configure any domain to IP pair you wish.

4


DNS - The Domain Name System

Host

cise.ufl.root ufl.e.edu

thunder.cise.ufl.edu 128.227.205.

• DNS maps between IP address (128.227.205.227) and domain and host names (thunder.cise.ufl.edu) • How it works: the “root” servers redirect you to the

top level domains (TLD) DNS servers, which redirect you to the appropriate sub-domain, and recursively ….

• Note: there are 13 “root” servers that contain the TLDs for .org, .edu, and country specific registries (.fr, .ch)

5


DNS Scalability• DNS is one of the most scalable subsystems deployed

today. How does it do that?

• The protocol is simple, running over UDP.

• Iterative execution and stub-resolvers limit the duties of core nodes.

• Caching, caching and more caching.

• DNS is so robust that botnet administratorssometimes attempt to DDoS it to demonstrate the overwhelming power of their malicious infrastructure.

6


DNS Vulnerabilities• Nothing is authenticated, so really the game is over

• You can not really trust what you hear … • But, many applications are doing just that. • Spoofing of DNS is really dangerous

• Moreover, DNS is a catalog of resources • Zone-transfers allow bulk acquisition of DNS data • … and hence provide a map for attacking the network

• Lots of opportunity to abuse the system • Relies heavily on caching for efficiency -- cache poisoning • Once something is wrong, it can remain that way in caches

for a long time (e.g., it takes a long time flush) • Data may be corrupted before it gets to authoritative

server

7


DNS Cache Poisoning

8

Victim nameserver

Root Servers

evil.net

neighborhoodbank.com

1 Q

ID=

599

IP fo

r w

ww

.nei

ghbo

rhoo

dban

k.co

m

2 Q

ID=

599 referral to neighborhoodbank.com

ns.neighborhoodbank.com

www.neighborhoodbank.com

www.neighborhoodbank.comfake!

evil client

3 QID=600

IP for www.neighborhoodbank.com

4 QID=600

IP: 192.168.1.100

QID=600QID=601

QID=5991a) IP: 192.188.42.18

Client

0

IP for www.neighborhoodbank.com5

Transaction


Limitations• DNS Cache poisoning has been known and

understood since almost as long as DNS has been deployed.

• Ok, then why was virtually nothing done to fix the problem?

• At the end of the day, the practicality of actually achieving this attack was judged to be too low to justify the expense of fixing it in any principled manner.

9


Kaminsky Variant

10

Victim nameserver

Root Servers

evil.net


1 Q

ID=

599

IP fo

r 98

765.

neig

hbor

hood

bank

.com

2 Q

ID=

599 referral to neighborhoodbank.com

ns.neighborhoodbank.com

www.neighborhoodbank.com

ns1.badguy.comfake!

evil client

3 QID=600

IP for 98765.neighborhoodbank.com

4 QID=600

Ad: 192.168.1.10

QID=600QID=601

QID=5991a) Authoritative for neighborhoodbank.com: 10.0.1.10

Client

0

IP for 98765.neighborhoodbank.com5

All subsequent transactions with neighborhoodbank.com


Kaminsky - It’s in the Details...• That’s all well and good, but how do you get

such a request from inside a target network?

• What can you do to prevent such attacks?

11


Kaminsky - The Aftermath• The community (operations, research, and

government) took this vulnerability very seriously.

• Disclosure was withheld for many months, to ensure that the majority of vendors could provide some sort of working solution.

• Large-scale patching took place over the course of about a month, with interesting results.

12


Source Port Randomization• DNS query ID guessing attacks are “easy” given

the very limited space allocated for QID (16 bits).

• Why can’t we just expand this field?

• Some have proposed the use of a random source port to expand the effective QID of each query.

• Potentially adds another 16 bits if enforced.

• What are the limitations of this proposed solution?

13


DNS Cookies• Server and resolver use a new option field to

include random “cookies” for each other.

• Cookie generation suggested using HMAC-SHA1

14

Resolver Server Query: RC:123, SC:???,E:0

ErrReply: RC:123, SC:789, E:BadC

Query: RC:123, SC:789,E:0

AnsReply: RC:123, SC:789,E:0

SC:789 RC:123

RC:123

ForgedReply: RC:???, SC:???,E:0

ForgedQuery: RC:XYZ, SC:???,E:0

ErrReply: RC:XYZ, SC:789, E:BadC RC:XYZ

Source: IETF Draft Presentation


0x20 Bit Randomization• DNS requests are NOT case sensitive:

• www.cnn.com = WwW.cNn.CoM

• This approach proposes the use of random capitalization of letters in domain names to provide additional bits of randomness.

• How many additional bits does the above example provide?

• Ok - guessing is now very difficult. Are we finished?

15

http://www.cnn.com

http://WwW.cNn.CoM


What did we fix?

16

ClientVictim

nameserver


adversary

QID = 867 WwW.nEiGhBoRhOoDbAnK.cOm

QID = 867 WwW.nEiGhBoRhOoDbAnK.cOm

QID = 456 www.NEIGHBORhoodBANK.com

QID = 456 WWW.neighborHOODbank.COM

http://www.NEIGHBORhoodBANK.com

http://WWW.neighborHOODbank.COM


What did we fix?

17

ClientVictim

nameserver


adversary

QID = 456 WWW.neighborHOODbank.COM

adversarial nameserver

?

http://WWW.neighborHOODbank.COM


ISPs as Adversaries?

18


DNSSEC• A standard-based (IETF) solution to security in DNS

‣ Prevents data spoofing and corruption

‣ Public key based solution to verifying DNS data

‣ Authenticates

• Communication between servers

• DNS data

• Public keys (a bootstrap for PKI?)

19


DNSSEC Mechanisms • TSIG : transaction signatures protect DNS operations

‣ Zone loads, some server to server requests (master -> slave), etc.

‣ Time-stamped signed responses for dynamic requests

‣ A misnomer -- it currently uses shared secrets for TSIG (HMAC) or do real signatures using public key cryptography

• SIG0: a public key equivalent of TSIG

‣ Works similarly, but with public keys

‣ Not as popular as TSIG, being evaluated

• Note: these mechanisms assume clock sync. (NTP)

20


DNSSEC Mechanisms

cise.ufl.eduroot ufl.edu.eduSigns Signs Signs

• Securing the DNS records

‣ Each domain signs their “zone” with a private key

‣ Public keys published via DNS

‣ Indirectly signed by parent zones

‣ Ideally, you only need a self-signed root, and follow keys down the hierarchy

21


DNSSEC challenges• Incremental deployability

‣ Everyone has DNS, can’t assume a flag day

• Resource imbalances

‣ Some devices can’t afford real authentication

• Cultural

‣ Most people don’t have any strong reason to have secure DNS ($$$ not justified in most environments)

‣ Lots of transitive trust assumptions (you have no idea how the middlemen do business)

• Take away: DNSsec is being deployed, but it is unclear whether it will be used appropriately/widely

22


DNSSEC Criticisms• Not everyone agrees that this standard is the right

way to move forward.

• The cryptographic operations can be slow.

• There is little agreement about who should hold the root keys.

• It can make responses HUGE!

23


DNSCurve• DNSCurve relies on Elliptic Curve Cryptography.

• Much more efficient in terms of performance and space.

• Criticisms:

• DNSSec offers algorithm options, DNSCurve locks in the use of Curve25519.

• DNSCurve secures a connection, not individual messages, meaning that cache entries can be replaced.

24


What Practicioners Think!

From: Randy Bush <[email protected]>!Subject: multiple-choice question of the day!Date: March 18, 2007 9:54:03 AM PDT!To: [email protected]!!!No transition plan!Declared victory before the hard part even started!No real long term plan!No realistic estimation of costs!No real support for the folk on the front lines!Victory will be next month!!Describes:!a - The war in Iraq!b - DNSsec!c - IPv6!d - All of the above

25

mailto:[email protected]

mailto:[email protected]


More criticism

DNSSEC is… 1. unneccessary? 2. a government-controlled PKI? 3. cryptographically weak? 4. Expensive to adopt/deploy? 5. an incomplete solution?

26

(Via http://sockpuppet.org/blog/2015/01/15/against-dnssec/)

http://sockpuppet.org/blog/2015/01/15/against-dnssec/


Wrap-Up• DNS is one of the most critical services underlying

stable operation of the Internet.

• Unfortunately, it is extremely vulnerable to attack as it has no strong authentication mechanisms.

• There are lots of proposed solutions, both “immediately” deployable (weak) and principled (strong).

• While we will likely see widespread DNSSEC deployment, it will almost certainly never be complete.

• How much is enough?

27

cnt 5410 - computer and network security: dns security · southeastern security for enterprise and...

Documents