Local DNS Attack Lab

profilecomputer_science
Chapter4DNSAttacks1.pdf

Network Security

DNS and Attacks

Network Security

● DNS Hierarchy, Zones, and Servers

● DNS Query Process

● DNS Attacks : Overview

● Local DNS Cache Poisoning Attack

● Remote DNS Cache Poisoning Attack

● Reply Forgery Attacks from Malicious DNS Servers

● DNS Rebinding Attack

● Protection Against DNS Cache Poisoning Attacks

● Denial of Service Attacks on DNS Servers

Outline

2

Network Security

Vacation

Savings

DNS

http://208.77.188.166

My Example Blog Spot

http://www.example.com

My Example Blog Spot

Vacation

Savings

www.example.com 208.77.188.166

Domain Name System

Network Security

DNS provides a distributed database over the internet that stores various resource

records, including:

▪ Address (A) record: IP address associated with a host name

▪ Mail exchange(MX) record: mail server of a domain

▪ Name server (NS) record: authoritative server for a domain

Name Servers

• Domain names:

▪ Two or more labels, separated by dots (e.g., cs166.net)

▪ Rightmost label is the top-level domain (TLD)

• Root servers, and servers for TLDs change infrequently

Domain Name System

Network Security

● Domain namespace is

organized in a hierarchical

tree-like structure.

● Each node is called a

domain, or subdomain.

● The root of the domain is

called ROOT, denoted as ‘

. ‘.● Below ROOT, we have Top-Level Domain

(TLD). Ex: In www.example.com, the TLD is

.com.

● The next level of domain hierarchy is second-

level domain which are usually assigned to

specific entities such as companies, schools etc

DNS Domain Hierarchy

5

Network Security

com edu

brown.edu

cs.brown.edu

A brown.edu 128.148.128.180 A xxx.brown.edu 128.148.###.### A xxx.brown.edu 128.148.###.### A xxx.brown.edu 128.148.###.### A xxx.brown.edu 128.148.###.### A xxx.brown.edu 128.148.###.### A xxx.brown.edu 128.148.###.### A xxx.brown.edu 128.148.###.### A xxx.brown.edu 128.148.###.### A xxx.brown.edu 128.148.###.### A xxx.brown.edu 128.148.###.### A xxx.brown.edu 128.148.###.### A xxx.brown.edu 128.148.###.### A xxx.brown.edu 128.148.###.### A xxx.brown.edu 128.148.###.###

A cs.brown.edu 128.148.32.110 A xxx.brown.edu 128.148.32.### A xxx.brown.edu 128.148.32.### A xxx.brown.edu 128.148.32.### A xxx.brown.edu 128.148.32.### A xxx.brown.edu 128.148.32.### A xxx.brown.edu 128.148.32.### A xxx.brown.edu 128.148.32.### A xxx.brown.edu 128.148.32.### A xxx.brown.edu 128.148.32.###

A google.com 66.249.91.104 A xxx.google.com ########### A xxx.google.com ########### A xxx.google.com ########### A xxx.google.com ########### A xxx.google.com ########### A xxx.google.com ########### A xxx.google.com ########### A xxx.google.com ########### A xxx.google.com ########### A xxx.google.com ########### A xxx.google.com ########### A xxx.google.com ########### A xxx.google.com ###########

google.com stanford.edumicrosoft.com

resource records

...

... ...

A xxx.com ########### A xxx.com ########### A xxx.com ########### A xxx.com ########### A xxx.com ########### A xxx.com ########### A xxx.com ########### A xxx.com ########### A xxx.com ########### A xxx.com ########### A xxx.com ########### A xxx.com ########### A xxx.com ########### A xxx.com ########### A xxx.com ########### A xxx.com ########### A xxx.com ###########

A xxx.edu ########### A xxx.edu ########### A xxx.edu ########### A xxx.edu ########### A xxx.edu ########### A xxx.edu ########### A xxx.edu ########### A xxx.edu ########### A xxx.edu ########### A xxx.edu ########### A xxx.edu ########### A xxx.edu ########### A xxx.edu ########### A xxx.edu ###########

Amicrosoft.com 207.46.232.182 A xxx.microsoft.com ########### A xxx.microsoft.com ########### A xxx.microsoft.com ########### A xxx.microsoft.com ########### A xxx.microsoft.com ########### A xxx.microsoft.com ########### A xxx.microsoft.com ########### A xxx.microsoft.com ########### A xxx.microsoft.com ########### A xxx.microsoft.com ########### A xxx.microsoft.com ########### A xxx.microsoft.com ########### A xxx.microsoft.com ########### A xxx.microsoft.com ########### A xxx.microsoft.com ###########

A stanford.edu 171.67.216.18 A xxx.stanford.edu 171.67.###.### A xxx.stanford.edu 171.67.###.### A xxx.stanford.edu 171.67.###.### A xxx.stanford.edu 171.67.###.### A xxx.stanford.edu 171.67.###.### A xxx.stanford.edu 171.67.###.### A xxx.stanford.edu 171.67.###.### A xxx.stanford.edu 171.67.###.### A xxx.stanford.edu 171.67.###.### A xxx.stanford.edu 171.67.###.### A xxx.stanford.edu 171.67.###.### A xxx.stanford.edu 171.67.###.### A xxx.stanford.edu 171.67.###.###

DNS Tree

Network Security

• Started in 1984

• Originally supposed to be named by function

▪ .com for commercial websites, .mil for military

• Eventually agreed upon unrestricted TLDs for .com, .net, .org, .info

• In 1994 started allowing country TLDs such as .it, .us

• Tried to move back to hierarchy of purpose in 2000 with creation of .aero, .museum,

etc.

Top Level Domain (TLD)

Network Security

● Infrastructure TLD: .arpa

● Generic TLD (gTLD): .com, .net,

● Sponsored TLD (sTLD): These domains are proposed and sponsored by private

agencies or organizations that establish and enforce rules restricting the eligibility to

use the TLD: .edu, .gov, .mil, .travel, .jobs

● Country Code TLD (ccTLD): .au (Australia), .cn (China), .fr (France)

● Reserved TLD: .example, .test, .localhost, .invalid

Top Level Domain (TLD)

8

Network Security

● The tree structure depicts subdomains within example.com domain.

● In this case, there are multiple DNS zones one for each country. The zone keeps

records of who the authority is for each of its subdomains.

● The zone for example.com contains only the DNS records for the hostnames that do

not belong to any subdomain like mail.example.com

● DNS is organized

according to zones.

● A zone groups contiguous

domains and subdomains

on the domain tree and

assign management

authority to an entity.

DNS Zone

9

Network Security

● A DNS zone only contains a portion of the DNS data for a domain.

● If a domain is not divided into subdomains, the zone and domain are essentially the

same, because the zone contains all the DNS data for the domain.

● When a domain is divided into subdomains, their DNS data can still be put in the

same zone, so domain and zone are still the same.

● But subdomains can have their own zones.

● usa.example.com is a domain with subdomains as boston, nyc and chicago. Two

zones are created for usa.example.com. First contains usa domain, chicago and boston

subdomain and second contains nyc subdomain.

Zone vs Domain

10

Network Security

● Each DNS zone has at least one authoritative nameserver that publishes information

about the zone.

● It provides the original and definitive answers to DNS queries.

- Can designate other ANS for subdomains

● An authoritative name server can be a master server (primary) or slave server

(secondary).

- Master contains original zone table

- Slaves are replicas, automatically updating

● Makes DNS fault tolerant, automatically distributes load

● ANS must be installed as a NS in parents' zone

Authoritative Name Servers

11

Network Security

● The root zone is called ROOT.

● There are 13 authoritative nameservers (DNS root servers) for this zone.

● They provide the nameserver information about all TLDs

○ https://www.internic.net/domain/root.zone

● They are the starting point of DNS queries.

DNS Root Servers

12

Network Security

They are the

most critical

infrastructure on

the Internet.

13 DNS Root Servers

13

Network Security

DNS Query Process

14

Network Security

● The iterative process starts

from the ROOT Server. If it

doesn’t know the IP

address, it sends back the

IP address of the

nameservers of the next

level server (.NET server)

and then the last level

server (example.net) which

provides the answer.

Local DNS Server and

Iterative Query Process

15

Network Security

Directly send the query to this server.

No answer

(the root does

not know the

answer)

Go ask them!

Emulating Local DNS Server

(Step 1: Ask ROOT)

16

Network Security

There are 4 types of sections in a DNS response :

● Question section : Describes a question to a nameserver

● Answer section : Records that answer the question

● Authority section : Records that point toward authoritative nameservers

● Additional section : Records that are related to the query.

In the above example, we see that as root server doesn’t know the answer there is

no answer section, but tells us about the authoritative nameservers (NS Record)

along with their IP addresses in the Additional section (A record).

DNS Response

17

Network Security

Ask a .net nameservers.

Ask an example.net

nameservers.

Go ask them!

Finally got the answer

Steps 2-3: Ask .net & example.net servers

18

Network Security

● There would be too much network traffic if a path in the DNS tree would be traversed

for each query (Root zone would be rapidly overloaded)

● When the local DNS server gets information from other DNS servers, it caches the

information.

● Each piece of information in the cache has a time-to-live value, so it will be

eventually time out and removed from the cache. Specified by ANS reply's time-to-

live field

● Operating systems and browsers also maintain resolvers and DNS caches

▪ View in Windows with command ipconfig /displaydns

▪ Associated privacy issues

● DNS queries are typically issued over UDP on port 53

▪ 16-bit request identifier in payload

DNS cache

19

Network Security

● /etc/host: stores IP addresses for some hostnames. Before machine contacts the

local DNS servers, it first looks into this file for the IP address.

● /etc/resolv.conf: provide information to the machine’s DNS resolver about the

IP address of the local DNS server. The IP address of the local DNS server provided by

DHCP is also stored here.

Local DNS Files

20

Network Security

● Denial-of-Service Attacks (DoS): When the local DNS servers and the authoritative

nameservers do not respond to the DNS queries, the machines cannot retrieve IP

addresses which essentially cuts down the communication.

● DNS Spoofing Attacks:

o Primary goal: provide a fraudulent IP address to victims, tricking them to communicate with a

machine that is different from their intention.

o Example: If a user’s intention is to visit a bank’s web site to do online banking, but the IP

address obtained through the DNS process is attacker’s machine, the user machine will

communicate to the attacker’s web server.

DNS Attacks

21

Network Security

22

Network Security

Overview of the Attack Surfaces

23

Network Security

● If attackers have gained the root privileges on a machine,

o Modify /etc/resolv.conf: use malicious DNS server as the machine’s local

DNS server and can control the entire DNS process.

o Modify /etc/hosts: add new records to the file, providing the IP addresses for

some selected domains. For example, attackers can modify IP address of

www.bank32.com which can lead to attacker’s machine.

DNS Attacks on Compromised Machines

24

Network Security

● We will use this setup for our experiment

Set Up DNS Server and Experiment

Environment

25

Network Security

● Need to modify /etc/resolv.conf

● DHCP may overwrite this file, we

need to tell DHCP client to

manually set the DNS server in

this file, and then never modify it

thereafter.

Setup: User Machine

26

Network Security

➢ Install BIND 9 DNS server: sudo apt-get install bind9

➢ Configure BIND 9 server

● BIND 9 gets its configuration from /etc/bind/named.conf,

● The file contains several “include” entries. One of the entries is

“/etc/bind/named.conf.options”. In this file, we can specify where the

DNS cache is to be dumped.

Commands

related to

DNS cache

Setup: Configure Local DNS Server

27

Network Security

➢ Turn Off DNSSEC: DNSSEC is used to protect against spoofing attacks on DNS

servers. To simplify our experiment, we need to turn it off. Modify

named.conf.options:

➢ Use fixed source port (to simplify our experiment): Modify named.conf.options

➢ Restart DNS Server: sudo service bind9 restart

Configure Local DNS Server:

Simplification

28

Network Security

➢ Create zones: Create two zone entries in the DNS server by adding them to

/etc/bind/named.conf.

For reverse lookup

(IP → hostname).

For forward lookup

(Hostname → IP).

Set Up DNS Zones on Local DNS Server

29

Network Security

/etc/bind/example.net.db (The file name is specified in named.conf)

@: Represents the

origin specified in named.conf (string

after “zone”) [example.net]

Zone File for Forward Lookup

30

Network Security

/etc/bind/192.168.0.db: (The file name is specified in named.conf)

Zone File for Reverse Lookup

31

Network Security

Testing Our Setup

32

Network Security

Local DNS Cache Poisoning Attack

Network Security

Spoofing DNS Replies (from LAN)

34

Network Security

Spoofing Replies: IP and UDP headers

35

Network Security

Spoofing Replies: DNS Header and Payload

36

Network Security

Goal: Forge DNS

replies after seeing a

query from Local DNS

Server

Local DNS Cache Poisoning Attack

37

Network Security

Local DNS Cache Poisoning Attack

38

Network Security

● Run “sudo rndc dumpdb –cache” and check the contents of

“/var/cache/bind/dump.db”.

● Clean the cache using “sudo rndc flush” before doing the attack.

Inspect the Cache

39

Network Security

Remote DNS Cache Poisoning Attack

Network Security

Challenges: For remote attackers who are not on the same network as the local DNS

server, spoofing replies is much more difficult, because they need to guess two random

numbers used by the query packet:

● Source port number (16-bit random number)

● Transaction ID (16-bit random number)

Cache effect: If one attempt fails, the actual reply will be cached by local DNS server;

attacker need to wait for the cache to timeout for the next attempt.

Challenges

41

Network Security

How can we keep

forging replies without

worrying about the

cache effect?

Kaminsky’s Idea: • Ask a different question

every time, so caching

the answer does not

matter, and the local DNS

server will send out a

new query each time.

• Provide forged answer in

the Authority section

The Kaminsky Attack

42

Network Security

This random

name will change

for each attack

attempt

This answer

does not matter

This is what we want the local

DNS server to cache

Tell the DNS server to use this one as the

nameserver for the example.com domain

The Kaminsky Attack: A Sample Response

43

Network Security

Attacks from Malicious DNS Server

Network Security

When a user visits a website, such as attacker32.com, a DNS query will eventually come

to the authoritative nameserver of the attacker32.com domain. In addition to providing an

IP address in the answer section of the response, DNS server can also provide information

in the authority and additional sections. Attackers can use these sections to provide

fraudulent information.

Attacks from Malicious DNS Server

45

Network Security

Additional

information is

provided

They will be discarded: out of zone. They will cause security

problems if not discarded.

Fake Data in the Additional Section

46

Network Security

This one is

allowed

This one is

out of zone,

and should

be discarded

Fake Data in the Authority Section

47

Network Security

This one

is allowed

This one is not allowed (out of zone). The local DNS server

will get the IP address of this hostname by itself.

Reply Forgery Attacks from

Malicious DNS Servers

48

Network Security

● In the reverse lookup, a DNS query tries to find out the hostname for a given IP

address.

● Question: Can we use the hostname obtained from reverse DNS lookup as the basis

for access control?

o Example: Packets from syr.edu are allowed to access certain services.

● To answer this question, we need to know how to do reverse lookup

Reply Forgery in Reverse DNS Lookup

49

Network Security

Example :

Given an IP address, 128.230.171.184, the DNS resolver constructs a “fake name”

184.171.230.128.in-addr.arpa and then send queries through an iterative process.

We emulate the entire reverse lookup process using @ option in the dig command.

Reply Forgery Attacks from

Malicious DNS Servers

50

Network Security

Step 1: Ask a root server. We get the

nameservers for the in-addr.arpa zone.

Step 2: Ask a nameserver of the in-addr.arpa

zone. We get nameservers for the 128.in-

addr.arpa zone

Reverse DNS Lookup

51

Network Security

Step 3: Ask a nameserver of the 128.in-

appr.arpa zone. We get the nameservers

for the 230.128.in-addr.arpa zone

Step 4: Ask a nameserver of the

230.128.in-appr.arpa zone. We get

the final result

Reverse DNS Lookup

52

Network Security

● Question: Can we trust the hostname obtained from reverse DNS lookup for a

suspicious IP address?

● Answer:

○ If a packet comes from attacker, the reverse DNS lookup will go back to the attacker’s

nameserver.

○ Attackers can reply with whatever hostnames they want.

Review Our Question

53

Network Security

Protecting Against DNS Cache Poisoning Attacks

Network Security

● DNSSEC is a set of extension to DNS, aiming to provide authentication and integrity

checking on DNS data.

● With DNSSEC, all answers from DNSSEC protected zones are digitally signed.

● By checking the digital signatures, a DNS resolver is able to check if the information

is authentic or not.

● DNS cache poisoning will be defeated by this mechanism as any fake data will be

detected because they will fail the signature checking.

DNSSEC (DNS Security Extensions)

55

Network Security

56

Network Security

Protection Using DNSSEC

57

Network Security

Transport Layer Security (TLS/SSL) protocol provides a solution against the cache

poisoning attacks.

● After getting the IP address for a domain name (www.example.net) using DNS

protocol, a computer will ask the owner (server) of the IP address to proof that it is

indeed www.example.net.

● The server has to present a public-key certificate signed by a trusted entity and

demonstrates that it knows the corresponding private key associated with

www.example.net (i.e., it is the owner of the certificate).

● HTTPS is built on top of TLS/SSL. It defeats DNS cache poisoning attacks.

Protection Using TLS/SSL

58

Network Security

● Both DNSSEC and TLS/SSL are based on the public key technology, but their chains

of trust are different.

● DNSSEC provides chain of trust using DNS zone hierarchy, so nameservers in the

parent zones vouch for those in the child zones.

● TLS/SSL relies on Public Key Infrastructure which contains Certificate Authorities

vouching for other computers.

DNSSEC vs. TLS/SSL

59

Network Security

DNS Rebinding Attack

Network Security

SOP: Limit the access permission (read/write) of JS or Application from different origin.

e.g., http://www.example.com/dir/:

● http://www.example.com/dir2 different directory, but same domain, resource

can cross-call each other.

● http://www.example.com:82/dir/ different port, does not qualify

● http://www.anotherone.com/ different domain, does not qualify

Cookie information from different source will be stored to different domain file.

but <src><link><img> are not controlled by SOP

61

Same Origin Policy

Network Security

Ajax code

The target server

(vulnerable)

Attacker

Attack goal: interact with the target server from outside

Same Origin Policy

Firewall

62

DNS Rebinding Attack

Network Security

63

DNS Rebinding Attack

Network Security

DoS Attacks on DNS

Network Security

• ICMP Attacks

- The Ping Flood Attack

- The Smurf Attack

• SYN Flood Attacks

• Optimistic TCP ACK Attack

• Distributed DOS Attack

IP/network layer

Transport layer

Network-based DoS Attacks

Network Security

• Send large number of packets to

host providing service

– Slows down or crashes host

– Often executed by botnet

• Attack propagation

– Starts at zombies

– Travels through tree of internet routers

rooted

– Ends at victim

• IP source spoofing

– Hides attacker

– Scatters return traffic from victim

Distributed DoS Attack

Network Security

Attacks on the Root and TLD Servers :

Root nameservers: If the attackers can bring down the servers of the root zone, they can

bring down the entire Internet. However, attack root servers is difficult:

● The root nameservers are highly distributed. There are 13 (A,B….M) root nameservers (server farm) consisting of a large number of redundant computers to provide reliable services.

● As the nameservers for the TLDs are usually cached in the local DNS servers, the root servers need not be queried till the cache expires (48 hrs). Attacks on the root servers must last long to

see a significant effect.

67

DoS Attacks on Root Servers

Network Security

Nameservers for the TLDs are easier to attack. TLDs such as gov, com, net etc have quite

resilient infrastructure against DOS attacks. But certain obscure TLDs like country-code

TLDs do not have sufficient infrastructure. Due to this, the attackers can bring down the

Internet of a targeted country.

68

DoS Attacks on TLD Servers

Network Security

UltraDNS: DNS provider for

many major e-commerce

companies such as Amazon,

Walmart, Expedia. In 2009,

DoS against this provider was

launched which suffered an

outage for an hour.

69

DoS Attacks on Nameservers of a

Particular Domain

Network Security

Dyn network : In 2016, multiple DDoS attacks were launched against a major DNS

service provider for companies like CNN, BBC, HBO, PayPal etc. The attacks are

believed to have been launched through botnet consisting of different IoT devices like IP

cameras, baby monitors etc. It caused major Internet services unavailable .

70

DoS Attacks on Nameservers of a

Particular Domain

Network Security

DNSPod : In 2009, several DNS servers of a Chinese domain service provider were hit by

DDoS.

● The attack was meant to target one particular company (Baofeng.com) which is widely popular video streaming site in China.

● On the next day of attack, when DNS responses previously cached by the other servers timed out, Baofeng’s media player on users’ machines could not find the IP addresses of the servers

because of the attack.

● Due to the bug in the media player software, instead of waiting, they continuously sent out DNS queries at a faster rate. Due to massive number of DNS queries, they flooded and congested the

network of China Telecom (ISP). It impacted 20 provinces and is described as the worst Internet

incident in China.

71

DoS Attacks on Nameservers of a

Particular Domain

Network Security

● How DNS works

● Spoofing Attacks on DNS

o Local DNS cache poisoning attacks

o Remote DNS cache poisoning attacks

o Reply forgery attacks

● Defense against DNS spoofing attacks

o DNSSEC

o TLS/SSL

● Denial of Services on DNS

72

Summary