CIS 659 – Introduction to Network Security – Fall 2003 – Class 21 – 11/18/03 CIS 659 – Introduction to Network Security – Fall

– Fall 2003 – Class 21 – 11/18/03

How DNS Works?
How DNS Works?
Namespace is organized as a tree
Each record has time-to-live (TTL) in seconds – indicates
A name server controls one zone – a subtree
of this tree how long can a record stay in the cache
This is done to provide for adaptation in a fast changing

He either contains all resource records for nodes

in this subtree environment

Or one of his offspring does Each zone is required to have at least two name servers
This is an administrative division, one domain

Primary

(udel.edu) can have many zones

Secondary (backup)

Clients ask for the data they need

Information is kept on the primary name server and
Resolvers find out the data that clients need periodically backed up on a secondary name server
They have it in their zone file (this machine is the name server)

Or they have it in their cache Inverse queries are satisfied from a dedicated domain in-

Or they know who to ask and they will find out the answer addr.arpa
1 2

CIS 659 – Introduction to Network Security – Fall 2003 – Class 21 – 11/18/03 CIS 659 – Introduction to Network Security – Fall 2003 – Class 21 – 11/18/03

Misusing Trust Relationship DNS Cache Poisoning

Applications perform authentications based on There is no authentication method to assure that
 

DNS names, not addresses the reply we got for DNS query is:
This is not so frequent today, as they use public keys Correct
instead, but it used to be common 5-10 years ago Generated by a name server authoritative for the zone
When such an application receives the request for Therefore anyone can generate a reply?
connection it checks inverse address-to-name mapping DNS request/reply packets have an ID number that is
Only one line in in-addr.arpa holds this and, if used for matching replies to requests
changed, attacker can gain trusted access to the given Anyone who wants to spoof replies must first guess the
application appropriate ID number
Sometimes this can be very easy to do

3 4

CIS 659 – Introduction to Network Security – Fall 2003 – Class 21 – 11/18/03 CIS 659 – Introduction to Network Security – Fall 2003 – Class 21 – 11/18/03

DNS Cache Poisoning DNS Cache Poisoning

A
The scope of the damage:


Attacker machine
B
Denial of service for the client A
Redirection of traffic for the client 1. What is address of B.evil.net C
B
DoS and/or redirection for the whole network if a
cache of a server doing recursive lookup were infected
NS NS
2. What is address of B.evil.net, ID=67
Victim nameserver
Attacker nameserver

VICTIM NETWORK
victim.net
4.5.6.0/24
ATTACKER NETWORK
5 6
evil.net
1.2.3.0/24

1
 CIS 659 – Introduction to Network Security – Fall 2003 – Class 21 – 11/18/03 CIS 659 – Introduction to Network Security – Fall 2003 – Class 21 – 11/18/03

DNS Cache Poisoning DNS Cache Poisoning

A A
Attacker machine
Attacker machine NS in victim.net increments his IDs sequentially!
B B
A A
3. What is address of A.evil.net 5. What is address of boss.microsoft.com
C C
B B

7. It is 1.2.3.25, ID=69
NS NS NS NS
4. What is address of B.evil.net, ID=68
Victim nameserver 9 Victim nameserver
ID=6
Attacker nameserver Attacker nameserver om,
soft.c
.micro
boss
ss of
a ddre
VICTIM NETWORK hat is VICTIM NETWORK
6. W
victim.net victim.net
4.5.6.0/24 4.5.6.0/24
ATTACKER NETWORK ATTACKER NETWORK
7 8
evil.net evil.net
1.2.3.0/24 1.2.3.0/24

CIS 659 – Introduction to Network Security – Fall 2003 – Class 21 – 11/18/03 CIS 659 – Introduction to Network Security – Fall 2003 – Class 21 – 11/18/03

DNS Cache Poisoning Bandwidth Attacks Using DNS

OK, so one network cannot reach boss.microsoft.com DNS replies are sometimes much larger than DNS
This is bad but still, there are many addresses that this network requests (1:3 size difference)

can reach, and this is just one network

This offers potential for amplification denial-of-service
How about poisoning everyone’s cache so they cannot
attacks
reach any of the microsoft.com addresses?
Attacker needs to send very few small requests, spoofing

This can be done if microsoft.com has a secondary server victim’s address

as a public one
Victim will be overwhelmed with replies

Secondary server updates his database from the primary server

(likely inside microsoft.com domain) via zone transfer messages How is this attack different than Smurf?
Format of these messages is similar to DNS request/response

format and can as easily be faked

Now everyone looking for microsoft.com will get fake data

9 10

CIS 659 – Introduction to Network Security – Fall 2003 – Class 21 – 11/18/03 CIS 659 – Introduction to Network Security – Fall 2003 – Class 21 – 11/18/03

Attacks on DNS Root Servers Attacks on DNS Name Servers

Concerted ping flood attack on all 13 of the DNS root 

Attack on Microsoft DNS servers in January

servers in October 2002
2001
Successfully halted operations on 9 of them
Attacked router in front of Microsoft’s DNS
Lasted for 1 hour, turned itself off servers
Appears to have been the work of experts During attack, as few as 2% of web page requests
Did not cause major impact on Internet were being fulfilled
DNS uses caching aggressively

As opposed to 97%, under normal load

Several root servers were provisioned enough

Solved by a better configuration of Microsoft’s



Longer, stronger attacks might have succeeded

DNS servers
The perpetrator of this attack is still unknown
11 12

2
 CIS 659 – Introduction to Network Security – Fall 2003 – Class 21 – 11/18/03 CIS 659 – Introduction to Network Security – Fall 2003 – Class 21 – 11/18/03

Securing Name Servers BIND Vulnerabilities

Root nameservers hold data that changes very slowly BIND is the prevalent implementation of nameserver

Every week or so a portion of it will change functionality

And root servers don’t have that much data anyways Homogeneous nameservers are vulnerable

It is possible to replicate this data and only check

Successful attack can take them all down

occasionally to see whether it has changed BIND is an open source software and has had many
It is also possible to have more than 13 root DNS servers versions
Or to filter ICMP traffic for root DNS servers Each version has fixed some vulnerabilities and

introduced new ones

Attacker can still flood with DNS requests

Securing TLDs is harder since data changes frequently

and there is much more of it “Bound by Tradition: A Sampling of the Security Posture of the Internet’s DNS Servers”
Mike Schiffman [email protected], February 2003
13 14

CIS 659 – Introduction to Network Security – Fall 2003 – Class 21 – 11/18/03 CIS 659 – Introduction to Network Security – Fall 2003 – Class 21 – 11/18/03

BIND Vulnerabilities BIND Vulnerabilities

18 publicly disclosed bugs:
9 of them enable remote code execution

8 enable denial-of-service attacks

1 enables information disclosure

15 16

CIS 659 – Introduction to Network Security – Fall 2003 – Class 21 – 11/18/03 CIS 659 – Introduction to Network Security – Fall 2003 – Class 21 – 11/18/03

BIND Prevalence BIND Version

15% of these run BIND but

chose to implement witty replies

17 18

3
CIS 659 – Introduction to Network Security – Fall 2003 – Class 21 – 11/18/03 CIS 659 – Introduction to Network Security – Fall 2003 – Class 21 – 11/18/03

BIND Version for Root DNS Other Name Server Implementations

Dan Bernstein’s tinydns
It was released in 1999

No publicly reported vulnerabilities

There is even an award of $500 for the first vulnerability found

19 20

CIS 659 – Introduction to Network Security – Fall 2003 – Class 21 – 11/18/03 CIS 659 – Introduction to Network Security – Fall 2003 – Class 21 – 11/18/03

DNSSEC DNSSEC
A modification of DNS protocol aimed at solving two Use digital signatures to sign the data and guarantee
problems: integrity and authenticity
Data integrity – noone modified this data Authoritative name server will sign the data with his private key

Data origin authentication – this data was generated by Anyone can decrypt and verify using server’s public key

an authority responsible for the given zone

If the private key is not kept online (on the name server) then
No protection is provided against denial-of-service there is no danger even if the server is compromised
Worse, some amplification messages are added to make Let us remind ourselves how are signing and
this problem more aggravating verification done!

21 22

CIS 659 – Introduction to Network Security – Fall 2003 – Class 21 – 11/18/03 CIS 659 – Introduction to Network Security – Fall 2003 – Class 21 – 11/18/03

DNSSEC DNSSEC Example

Each zone will have a public/private key pair
We will sign each record in a zone file with the private key

This signature will form a new record – SIG record What is address of copland.udel.edu?

Zone’s public key is stored in another record – KEY record

What if someone wanted to fake zone’s public key? NS

This is prevented by adding a parent signature for KEY record

udel.edu

A=128.175.13.92 Obtain public key pair for p

SIGk(A) Verify k
k=KEY(NS.udel.edu) B=Decrypt SIG(A)
SIGp(k) C=Hash A
A Verify that B==C
23 24

4
 CIS 659 – Introduction to Network Security – Fall 2003 – Class 21 – 11/18/03 CIS 659 – Introduction to Network Security – Fall 2003 – Class 21 – 11/18/03

Proving Non-Existance Sorting

Usually, if something does not exist a generic NOEXIST udel.edu. IN SOA ns.udel.edu. root.udel.edu. (99021800 1h 10m 30d 1d )
IN NS ns.udel.edu.
record is returned IN A 128.175.0.1

This is easily spoofed IN MX 0 mail.udel.edu.

ns IN A 128.175.0.1
Even signatures don’t help (why?)

mail IN A 128.175.0.2
www IN A 128.175.0.3
What if someone claims that a real record does not exist?

ftp IN CNAME www.udel.edu.

We must sign something Sorts to

We will sign the NXT record – this specifies which existing udel.edu. IN SOA ns.udel.edu. root.udel.edu. (99021800 1h 10m 30d 1d )
udel.edu. IN NS ns.udel.edu.
name is lexicographically after the one that does not exist udel.edu. IN A 128.175.0.1

We will sort names, not numbers udel.edu. IN MX 0 mail.udel.edu.

ftp.udel.edu. IN CNAME www.udel.edu.
mail.udel.edu. IN A 128.175.0.2
ns.udel.edu. IN A 128.175.0.1
www.udel.edu. IN A 128.175.0.3
25 26

CIS 659 – Introduction to Network Security – Fall 2003 – Class 21 – 11/18/03 CIS 659 – Introduction to Network Security – Fall 2003 – Class 21 – 11/18/03

NXT record Inverse Address Mapping

udel.edu. IN SOA ns.udel.edu. root.udel.edu. (99021800 1h 10m 30d 1d )
udel.edu. IN NS ns.udel.edu.
udel.edu. IN A 128.175.0.1
udel.edu. IN MX 0 mail.udel.edu.
udel.edu. IN NXT ftp.udel.edu A NS SOA MX NXT
ftp.udel.edu. IN CNAME www.udel.edu.
ftp.udel.edu. IN NXT mail.udel.edu. CNAME NXT
mail.udel.edu. IN A 128.175.0.2
mail.udel.edu. IN NXT ns.udel.edu. A NXT
ns.udel.edu. IN A 128.175.0.1
ns.udel.edu. IN NXT www.udel.edu A NXT
www.udel.edu. IN A 128.175.0.3
www.udel.edu. IN NXT udel.edu. A NXT
Now if someone asks for morning.udel.edu
we would return signed
mail.udel.edu. IN NXT ns.udel.edu. A NXT
27 28