NETWORK SECURITY

Based on Dieter Gollmann’s book, Computer Security, 3rd Edition.

Domain Name System (DNS)
¨ distributed directory service
¤ used for looking up IP addresses for host names, and
vice versa (reverse look-up)
¤ basis for Same-Origin Policy
n Protocol, hostname, port # (get more into it in Web Security)
¨ zones
¤ host names and IP addresses collected in zones
¤ zone managed by its authoritative name server
¤ authoritative name servers provide mapping between
hostnames and IP addresses for their zones
Domain Name System (DNS)
¨ 13 (logical) root servers on Internet
¨ all name servers are configured with the IP addresses
of these root servers
¨ Global Top Level Domain (GTLD) servers
¤ in charge of top-level domains such as .com, .edu, .net, .org,
.cc, .cn, etc.
¤ can be more than one GTLD server per top-level domain
(TLD)
¤ root servers know about GTLD servers
¤ GTLD servers know authoritative name servers in their TLD
¤ recursive name servers pass name resolution requests on to
other name servers and cache answers received
 IP Address Look-up
1. client asks its local resolver to resolve a host name (target)
2. resolver checks whether it has a valid IP address for target in its cache
¤ if it does this address is returned
¤ otherwise resolver refers request to one of root server
3. root server returns list of GTLD servers for target’s TLD
¤ + their IP addresses
4. resolver refers request to one of GTLD servers
5. GTLD server returns list of authoritative name servers for target’s domain
¤ + their IP addresses
6. resolver refers request to one of authoritative name servers
7. authoritative name server returns an authoritative answer with target’s IP
address + TTL
8. resolver sends answer to client and caches binding
9. answer remains in cache until it expires
IP Address Lookup
¨ TTL of answer set by authoritative name server
¤ authoritative name server usually knows how stable
address bindings are in its zone
What’s a vulnerability here?
¨ Attacker can get to resolver before trusted name
server
¤ note that this is different from trusted name server
going rogue
DNS Security: Lightweight
Authentication
¨ resolver uses challenge-response protocol to authenticate
origin of replies received
¤ 16-bit query ID (QID) and UDP port that should receive answer are
included in each request
¨ responding name server copies QID into its answer; replies on
port indicated
¨ resolver caches first answer received for a given QID and host
name on nominated port
¨ resolver then discards this QID and drops all answers that do
not match an active QID
What’s a vulnerability here?
Cache Poisoning Attack
¨ Attacker asks a resolver to resolve a host name attacker wants to
take over
¨ Attack
¤ host name must not have a valid entry in resolver’s cache
¤ attacker immediately floods resolver with spoofed answers mapping
hostname to an IP address of attacker’s choice
n spoofed answers contain guessed QIDs with a long TTL
n if a spoofed answer with correct QID arrives on correct port before genuine
answer, attacker’s value is cached and correct answer is dropped
¤ if anyone queries resolver for target’s host name, resolver will give
address provided by attacker from cache
n until attacker’s TTL expires
n if authoritative answer comes first it will be cached
n attacker is blocked until authoritative TTL expires
Cache Poisoning Attack
¨ Probability of attack succeeding depends on following
factors:
¤ difficulty of guessing QID
n easy when QID is generated by a counter (2^-16 probability)
¤ difficult of guessing port #
n easy if fixed port # is used
¤ width of time window until authoritative answer arrives
n window of opportunity can be increased by running a
simultaneous denial-of-service attack against the authoritative
name server
¤ good implementations of DNS will address first two issues
Solution?
DNSSec (DNS Security Extensions)
¨ protects authenticity and integrity of resource
records with digital signatures
¤ when resolver receives the record, it can verify that the
correct authoritative name server has sent the record
¤ prevents cache poisoning attack

¤ based on public key infrastructure

n I will try to revisit this in detail after we study cryptography
DNS Rebinding Attack
¨ When resolving a host name, the resolver ‘trusts’ the
authoritative DNS server and relies on the
information received.
¨ What if the authoritative DNS server lies?
DNS Rebinding Attack
¨ attacker registers a domain name, such as attacker.org
¨ starts attracting web traffic
¤ e.g. using an advertisement
¨ when user visits the host (in domain attacker.org), attacker answers DNS
queries for attacker.org (he owns the DNS server in his domain) with the IP
address of his own server with a short time-to-live (TTL)
¨ serves visiting clients with malicious JavaScript
¨ malicious script waits for TTL to expire, and connects to attacker.org again
¨ attacker rebinds the host name to the IP address of a target server that is
inaccessible from the public Internet (example behind a firewall)
¨ the browser believes the two servers belong to the same origin because
they share a host name, and it allows the script to read back the response
¨ the script can easily exfiltrate the response, enabling the attacker to read
arbitrary documents from the internal server
DNS Rebinding Simple Example
¨ Alice connects to bad.malicious.com, which resolves to IP 1.2.3.4 with a TTL
of 1 second.
¨ 1.2.3.4 serves some JavaScript code to Alice’s browser, set to execute in 10
seconds.
¨ The DNS server in control of *.malicious.com immediately points
bad.malicious.com to 10.0.0.1
¨ 10 seconds later, the JavaScript on Alice’s browser connects to
bad.malicious.com, in compliance with the same origin policy, and retrieves
a web page from Alice’s internal server at 10.0.0.1
¨ The DNS server resets bad.malicious.com to 1.2.3.4 and after some period
of time, Alice’s browser reconnects and sends 1.2.3.4 its findings
DNS Rebinding Attack
¨ Remember: same-origin policies authorize actions based on the
domain of the host:
¤ in DNS rebinding: attacker bypasses same-origin policy by
confusing browser into combining network resources controlled by
distinct entities into one origin
¤ using DNS rebinding, attacker can:
n circumvent firewalls to spider corporate intranets
n exfiltrate sensitive documents
n compromise unpatched internal machines
n hijack the IP address of innocent clients to send spam e-mail, commit
click fraud, and frame clients for misdeeds
n read and write directly on network sockets, subsuming the attacks
possible with existing JavaScript-based botnets, which can send HTTP
requests but cannot read back the responses
¨ DNSSec is no defense against DNS rebinding attacks
Solution?
Pinning
¨ browser shouldn’t trust DNS server on TTL of a
binding but sets its own
¤ pins host name to IP address web page loaded from
¨ pinning overrules TTLs set by authoritative name
servers
¤ e.g. when JavaScript connects to attacker.org, browser
will connect back to attacker’s server instead of internal
server
Pinning
¨ pinning no longer effective defense against DNS
rebinding attacks in current browsers
¤ vulnerabilities introduced by plug-ins
¤ plug-ins provide additional functionality to webpages
n socket-level network access
¤ browser and each plug-in maintain separate pin
databases
n creates new class of vulnerabilities called multi-pin
vulnerabilities
n permit attacker to mount DNS rebinding attacks
Other Solutions
¨ Private IP addresses can be filtered out of DNS
responses.
¨ The Firefox NoScript extension provides partial
protection (for private networks) using
its ABE feature, which blocks web traffic from
external addresses to local addresses.