TCP/IP: DNS - cs.bham.ac.ukexr/lectures/networkSecurity/11_12/slides/08_t… · The Domain Name...

TCP/IP: DNS

Network Security

Lecture 8

The Domain Name System

• Database that primarily maps IP addresses (147.188.192.42) to names (www.cs.bham.ac.uk) and viceversa– Nice properties: distributed, coherent, reliable, autonomous, and hierarchical

• DNS namespace has tree structure– Domain is a node in this tree

– All nodes except the root have labels (e.g., www)

– Fully qualified name: nodes labels, bottom up, each followed by a dot

• Nodes are grouped (clique) into zones (administrative boundaries)– Apex is called the “start of authority”

– Bottom edges with other zones below them are “delegation points”

– Bottom nodes with no other zones below them are “leaf nodes”

– Each zone is served by authority servers

• Nodes store actual content in resource records (RRs)– RR: name, class, type, TTL, and data

– Data can map IP to host name and viceversa

– Data can specify the mail server for domain

• More: P. Vixie, “DNS Complexity”, ACM Queue, 2007Eike Ritter Network Security - Lecture 8 2

Domain hierarchy

Eike Ritter Network Security - Lecture 8 3

.

com net uk

google acco

google bham

csph

lloydstsb

arpa

in-addr

147

188

192

42

(root)

Mapping names to IPs and viceversa

• Can a host name be mapped to many IP addresses?– Yes. For example, load balancing

$ nslookup www.google.comName:www.l.google.comAddress: 209.85.143.99Name:www.l.google.comAddress: 209.85.143.104

• Can an IP address be mapped to many domain names?– Yes. For example web hosting

(Some) domains seen at 74.125.53.132:amomsrantings.blogspot.com, bloxee.blogspot.com, culturadohashi.blogspot.com, ocedeloguxuf.blogspot.com, opensocial.googleusercontent.com, www-blogger-, ads.gmodules.com,, www.gmodules.com, …

– Tool: Passive DNS replication @ BFK


Servers

• Primary authoritative server– Authoritative for a zone

– Loads mappings from local configuration (file on disk)

• Secondary authoritative server– Backup

– Their zone data comes to them from primary servers via a zone transfer procedure

• Recursive and caching server– Caches query results until their TTL expires

– Implements the recursive algorithm needed to locate a RR


Clients

• Often called “resolvers”

• Most often they do not cache (“stub

resolver”)

• Rely on recursive service of their designated

full resolver

• Tools: nslookup, dig, host


$ cat /etc/resolv.conf

search cs.bham.ac.uk

nameserver 147.188.192.4

nameserver 147.188.192.8

Queries

• Recursive– Client asks the server to respond

with either the requested resource record or error message if none exists

– If DNS server does not have the queried information, it queries other servers until it gets the information (or the query fails)

• Iterative– Client asks the server to respond

with the best answer it can provide, given its cache or zone data

– If DNS server does not have the queried information, it may respond with a referral to server that may have it

• Specify the information requested (type of query)− A: address of host

− NS: authoritative name server for domain

− CNAME: canonical name

− MX: mailer for host

− TXT

• Are identified by ID field (16 bits)

• Can be done over UDP or TCP− Typically UDP; TCP for larger

responses


Example


$ dig google.com

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34072

;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 0

;; QUESTION SECTION:

;google.com. IN A

;; ANSWER SECTION:

google.com. 300 IN A 209.85.143.99

google.com. 300 IN A 209.85.143.104

;; AUTHORITY SECTION:

google.com. 172800 IN NS ns4.google.com.




;; Query time: 21 msec

;; SERVER: 147.188.192.4#53(147.188.192.4)

;; WHEN: Wed Feb 2 18:29:31 2011

;; MSG SIZE rcvd: 132

Example


% dig +norecurse google.com

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52597

;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0

;; QUESTION SECTION:

;google.com. IN A

;; AUTHORITY SECTION:

com. 172794 IN NS i.gtld-servers.net.

com. 172794 IN NS e.gtld-servers.net.

com. 172794 IN NS l.gtld-servers.net.

com. 172794 IN NS c.gtld-servers.net.

com. 172794 IN NS h.gtld-servers.net.

com. 172794 IN NS d.gtld-servers.net.

com. 172794 IN NS b.gtld-servers.net.

com. 172794 IN NS g.gtld-servers.net.

com. 172794 IN NS f.gtld-servers.net.

com. 172794 IN NS a.gtld-servers.net.

com. 172794 IN NS k.gtld-servers.net.

com. 172794 IN NS j.gtld-servers.net.

com. 172794 IN NS m.gtld-servers.net.

DNS query


13:30:08.018705 IP 10.4.130.214.51103 > 147.188.128.102.53: 1313+ A?

google.com. (28)

13:30:08.047483 IP 147.188.128.102.53 > 10.4.130.214.51103: 1313 5/13/0

A 74.125.230.114, A 74.125.230.115, A 74.125.230.116, A 74.125.230.112,

A 74.125.230.113 (319)

DNS spoofing


server1.example.com

172.16.48.1

Attacker:

6.6.6.6

server2.example.com

172.16.48.2

ns1.evil.com

ns1.example.com

Assumption: server1 trusts

connection from

.example.com

1) attacker connects to server1

from 6.6.6.6

2) server1 looks up the name

associated with 6.6.6.6

3) ns1.evil.com replies

“server2.example.com”

4) Server1 grants access to

attacker

1.

2.-3.

Defense: double reverse lookup

• Given IP address I1, obtains the name N

– Mapping is provided by name server responsible

for I1, which may well be completely

untrustworthy

• Given N, obtain its address I2

– Mapping is provided by name server responsible

for N. In the scenario before, this name server is

trusted

• Check if I1 = I2


DNS hijacking

• DNS does not provide any means of authentication

• Racing against the queried named server it is possible to provide a fake IP address/domain name mapping

– Attacker could mount attack against client

– Attacker could mount attack against name server

• The attacker needs to set correctly the request ID

– Easy if attack done on the same LAN (sniffing)

– Need to guess if done blindly


DNS hijacking


ns1.example.com

Victim:

172.16.48.2

Attacker:

172.16.48.1

A? google.com

A 74.125.230.115

A 172.16.48.1

DNS amplification attack

• Certain queries can cause large responses– TXT, ANY query

– Queries for “.” (root)

• Most typically, queries done over UDP

• Do you see a problem here?(remember smurf attacks?)

• DNS amplification attack:– The attacker spoofs the source IP address to be the address of the victim

– Sends these “expensive” queries to a large number of servers

– Servers will send the response to the victim, overloading it

• Defenses:– Don’t allow open recursive servers, that is recursive servers that respond

queries from external clients

– Respond to expensive queries from untrusted parties with shorter error messages (REFUSED answer, instead of providing the list of root servers)


DNS poisoning

• Certain DNS implementations used to cache anything contained in a DNS reply

• Malicious DNS server would return a reply with additional answers that would poison the victim’s cache– Query for foo.com answered with additional section

containing the IP address of bank.com

– Can you use it to bypass the double reverse lookup?

• Solution: only accept additional information that is relative to the domain being queried (bailiwick check)


DNS poisoning

• Attacker forces recursive resolver to initiate a DNS query

• As the resolver is waiting for answer from authority resolver, attacker forges answers

• Attacker needs to guess all the transactional elements used in the victim’s query– Query ID

– Port number

• If success, victim will store wrong IP-domain mapping

• If attacker looses the race, he will have to wait until the correct response expires (TTL field)– Order of several days, typically


A? google.comID = 1234

ns.victim.com ns.google.com

IN A google.com172.16.48.1ID = 1234

Attacker172.16.48.1

Kaminsky attack

• Technique to “speed up” the poisoning attack

• Attacker sends query for 000001.bank.com

• Recursive server recursively attempts to answer the query contacting authoritative server of bank.com (ID = 1234)

• Attacker sends a number of spoofed responses (trying to guess the correct ID) with 2 parts:– Answer for 000001.bank.com is arbitrary

– Authority section that claims a malicious IP is the NS for the bank.com zone

• If the attacker guesses the ID and port number, Bailiwick check passes

• If the attacker is unsuccessful, the correct answer (likely, NXDOMAIN) arrives first and is accepted

• But now attacker can simply try again, querying for 000002.bank.com – Attacker does not need to wait for TTL to expire


TCP/IP RECAP

In form of a quiz


PGP

• Alice signs a message as follows:$ gpg –s –a msg.txtand sends it to Bob via regular email

• What security properties are guaranteed?

– Integrity?

– Confidentiality?

– Authenticity?

• Would anything change if Alice signed the message in binary format, i.e., without using the –a flag?


IP addresses

• Looking at logs of network traffic of the School web server (147.188.192.42), you notice a bunch of ICMP echo messages directed to it. They all have the source IP address set to 192.168.1.1.What do you do?

– Look up the IP to notify the admin of the corresponding network

– Drink another coffee: there’s nothing you can do

– Filter packets from reserved network addresses


IP


C:

172.16.48.3

00:11:22:33:44:03

A:

172.16.48.2

00:11:22:33:44:02

B:

172.16.48.1

00:11:22:33:44:01

Src IP: ?, Dst IP: ?

Src ether: ?; Dst ether: ?

You’re monitoring traffic between A and C. What are the values of IPdatagrams that you expect?

libpcap

• Our forensic team just recovered the

following snippet of code from the hard disk

of the old administrator. What was the

purpose of the code (port 23 is the telnet

port)?

#!/bin/bash

tcpdump –i eth0 –s0 port 23 –w dump.pcap


IP options

• Briefly explain why most routers drop IP

packets with the IP source routing option


Scanning

• Briefly explain the traffic found in the

following trace


12:31:38.707533 ARP, Request who-has 172.16.48.130 tell 172.16.48.139, length 2812:31:38.708077 ARP, Reply 172.16.48.130 is-at 00:0c:29:27:25:40, length 4612:31:38.708083 IP 172.16.48.139.39844 > 172.16.48.130.80: tcp 012:31:38.708116 IP 172.16.48.139.60408 > 172.16.48.130.443: tcp 012:31:38.708567 IP 172.16.48.130.80 > 172.16.48.139.39844: tcp 012:31:38.708582 IP 172.16.48.139.39844 > 172.16.48.130.80: tcp 012:31:38.708615 IP 172.16.48.130.443 > 172.16.48.139.60408: tcp 012:31:38.708806 IP 172.16.48.139.39844 > 172.16.48.130.80: tcp 0

TCP

• You have been hired to implement the TCP/IP

stack in the new iPosh. You are tired of

reading RFCs and decide that for picking Initial

Sequence Numbers you will use the following

formula:ISN = # packets sent + src_port + src_ip + dst_port + dst_ip

• Is this a good idea?


TCP

• You are studying the ISN generator of the iPosh2 and you derive the following graph. What is your onclusionon the security of the device?


DNS

• You are monitoring queries to your DNS

server, when you notice the following series

of queries:

A? asdasdsa.example.com

A? gdfgfoger.example.com

A? p34339ds.example.com

A? p03jsdss.example.com

• What is your analysis?


TCP/IP: DNS - cs.bham.ac.ukexr/lectures/networkSecurity/11_12/slides/08_t… · The Domain Name...

Documents

Transcript of TCP/IP: DNS - cs.bham.ac.ukexr/lectures/networkSecurity/11_12/slides/08_t… · The Domain Name...