DNS Security 1

DNS Security

Spyridon Dosis

June 2014

DNS Security 2

Outline

• The DNS protocol / infrastructure / tools

• DNS Protocol Attacks

• Securing DNS

• DNSSec

• DNS abuse (fast-flux networks)June 2014

DNS Security 3

Domain Name Service (DNS)

• A directory service for mapping host names to IP addresses (… and more)

• Hierarchical structure (root node, TLDs {gTLD,ccTLD}, SLDs, etc.)

• http://www.root-servers.org/• 13 root servers (a-m.root-servers.net) – 350+ instances (anycasting)• Root-servers TLD master file (TLD authoritative servers)• Secure / non-public update process

• Authority & Delegation• Fully Qualified Domain Names (www.example.com.)

June 2014

DNS Security 4

DNS Queries

• Authoritative Name Server• Provides authoritative answers

• Resolvers• Issues queries e.g. to resolve names to IP addresses

• Iterative• The DNS client asks the DNS server for an answer (e.g.

cached) or a referral to the next delegation level ([caching] name server / resolver)

• Stub-resolvers (e.g. in OS) can’t follow referrals

• Recursive• The DNS client offloads the responsibility of finding an

answer (success or fail) to the DNS server (caching / recursive name server / resolver)

June 2014

DNS Security 5

DNS Queries

• Reverse-mapping• IP-to-name resolution• Uses the reserved domain of IN-

ADDR.ARPA for IPv4, IP6.ARPA for IPv6• Prepend the reversed IP address (e.g.

1.1.168.192.<domain>.)• A number of use cases (e.g. email

source verification, DNS blacklists etc.)

June 2014

DNS Security 6

DNS Primer

• DNS query workflow

June 2014

DNS Security 7

DNS Primer

• Zone & zone files• Operational entities under a domain (e.g. hosts,

mail servers, services etc.)• Described with textual Resource Records (RRs)• RFC 1035 – Zone file and RR format• $TTL directive – Access load & change

propagation

• Sub-domains and sub-zones• Master and slave DNS servers• Master copy of the zone file• Replicated through zone transfers

June 2014

DNS Security 8

DNS Transfer

• Full Zone Transfer (AXFR)• Copies the complete zone file• Based on checking the serial number of the SOA

RR on the master name server

• Incremental Zone Transfer (IXFR)• Notify (NOTIFY)• Notify the NS RRs in the zone when updated

• Dynamic Update• Dynamic DNS (DDNS)

• Updating zone’s RRs from external sources

• BIND-DLZJune 2014

DNS Security 9

DNS RRs

• SOA (Start of Authority)• Zone’s properties

• A / AAAA resource record• Maps hostname to IPv4 / IPv6 address

• NS• Authoritative name servers for the domain

• MX• Mail servers for the domain

• CNAME• Alias for an existing host defined by an A RR

• PTR, TXT, SRVJune 2014

DNS Security 10

DNS Software

• ISC BIND• Microsoft DNS Server• NSD (name server functionality)• PowerDNS (authoritative-only name server)• Unbound (resolver functionality)

• UDP Port 53• 512-byte performance-wise limit on messages• EDNS0 (RFC 2671) for 4096-byte messages

• TCP Port 53• Zone maintenance operations

June 2014

DNS Security 11

DNS-related Utilities

• DIG – Domain Information Groper & nslookup • DNS name resolution using default or

specific nameserver• (e.g. dig @8.8.8.8 hostname)

• Reverse lookups• dig –x 193.10.9.6

• Find a domain’s mail servers• dig dsv.su.se MX

June 2014

DNS Security 12

DNS-related Utilities

• WHOIS• Query & Response Protocol (RFC 3912)• Information about the registration of a

domain, IP address range, autonomous system

June 2014

DNS Security 13

DNS Server Impersonation

• Spoofing a DNS server’s answer• Server-to-server communication• Client-to-server communication• Spoofing the source IP address of the DNS reply

with the legitimate DNS server’s one

• DNS Pharming• Modifying the DNS server settings on the client

or the DHCP server (e.g. WAP)

• Rogue DNS Server• Combined with DHCP starvation / rogue DHCP

server in LANs

June 2014

DNS Security 14

DNS ID Hacking

• Essential in order for the DNS reply to be accepted by the resolver is that the reply ID matches the request ID (DNS protocol header field), match the source port and query section and the authority and additional sections are within the requested domain (bailiwick checking)

• Sniff it if in the same LAN (hub or MitM)• Send some requests to the resolver to better

estimate the ID

June 2014

DNS Security 15

DNS Cache poisoning

• Trick a DNS server into caching a false hostname-IP mapping• E.g. link www.google.com with the attacker’s IP address

• Spoof NS entry of target domain to attacker’s IP• Query : www.example.com• (Attacker) Answer :

example.com. 86400 IN NS www.example.com.www.example.com. 604800 IN A 10.10.10.20

• Patch your servers (better source port and query ID randomization, rejecting “out-of-zone” information

June 2014

DNS Security 16

DNS Security Threats

• Zone file (malicious) / DNS server configuration corruption

• Unauthorized zone file dynamic updates

• Spoofing in zone transfers

• Resolver cache poisoning / data interception

June 2014

DNS Security 17

Securing DNS

• Keep up-to-date the DNS server software• Do not communicate the software version• Disable unneeded features (e.g. zone transfer

or notify by out-of-band update mechanism for multiple master name servers)

• Explicit over default server configuration• Deny-all global options and allow per zone• Run the server software with least privileges• Run multiple servers with different software

June 2014

DNS Security 18

Split (Horizon) DNS

• Two sets of name server records• For internal clients• For external clients

• ‘Hide’ internal servers to external sources

• Provide different answers based on the requester’s source address

• Server-based or software-based

June 2014

DNS Security 19

Open Resolvers

• Resolve queries even for zones it is not authoritative for

• Perform recursive lookups for external clients

• Can be abused to participate in DDoS / leak internal information

June 2014

DNS Security 20

DNS Reflection Attacks

• Spoofed IP source address• DNS server replies to the victim (spoofed

IP source address of the DNS query)• Packet size amplification• <100 byte request• 2-4kb reply

• Distributed reflection attacks• 28m potential DNS resolvers

(http://openresolverproject.org/)• Spamhaus received a 300Gb/s DDoS

June 2014

DNS Security 21

DNS Amplification Attack

June 2014Image taken from http://securitytnt.com/dns-amplification-attack/

DNS Security 22

DNS Amplification Counter-Measures

• BCP-38• Prevent outbound packets with spoofed

source IP address• Responsibility of the ISP

• Rate-limiting controls• Allow recursion for resolvers only to

internal hosts• No recursion for authoritative DNS

serversJune 2014

DNS Security 23

DNSSec

• How can a client trust a query’s response?• Rogue server response• Poisoned cached response• Response modification by a MitM

• DNSSec enables a security-aware name server to verify the authenticity and integrity of query results• Response originating from the requested zone• Integrity of received data• Proof of nonexistence for NXDOMAIN responses

• Leverages PKI and specialized RRs• RRSIG, DNSKEY, NSEC

June 2014

DNS Security 24

DNSSec Principles

• Both the authoritative zone server and the querying resolver must support DNSSec

• The zone file is cryptographically signed (a Secure Entry Point)

• The public key (ZSK and KSK) is stored as the DNSKEY RR

• RRsets are digitally signed (adding the RRSIG RR)

• The records are ordered by canonical name and chained through the NSEC RR

June 2014

DNS Security 25

DNSSec Workflow

• The authoritative nameserver signs the zone’s records with its private key (ZSK and KSK)

• The security-aware resolver uses the respective zone’s public key for signature validation• How to transfer the public key to the

resolver?• Publish the public key as a DNSKEY RR• Transfer the public key using an out-of-

band process (trusted anchor)June 2014

DNS Security 26

DNSSec Validation

• Secure• Trusted anchor is present and the received data

have been validated successfully

• Insecure• Trusted anchor is present but no secure link to

the delegated node (e.g. sub-domain)

• Bogus• Trusted anchor is present but the received data

have not been validated successfully

• Indeterminate• No trusted anchor for this domain

June 2014

DNS Security 27

DNSSec Chains of Trust

• Delegated Signer RR• Authenticating the NS RRs that

point to the child domain by importing the child’s KSK

• The root zone has been signed in July 2010

• Several gTLDs and ccTLDs as well• The validating resolver follows the

chain from the root to the signed zone• Need for a single root-key as trusted

anchor

June 2014

DNS Security 28

Secure Zone Maintenance

• Need to resign the zone when• A change is made to the zone records

(e.g. SOA RR serial number)• The signature expires (RRSIG RRs have

a start time and expire after a period of time e.g. 30d)

• Signing keys rollover• Updating the DS record of the parent• Updating the trusted anchor of security-

aware resolvers

June 2014

DNS Security 29

Fast-flux networks

June 2014

DNS Security 30

Fast-flux Networks

• A distributed system• Master server(s) – motherships -> Controller nodes• Infected/controlled hosts

• Name resolution services• Traffic proxying• Delivery of malware

• Additional operational services (e.g. registration, availability checkers)

• Main goal:• Make the malicious network harder to discover

through layers of traffic redirection• Defeat IP-based ACL approaches

June 2014

DNS Security 31

Fast-flux Use Cases

• Hosting phishing sites directly on a compromised host and advertise its DNS name or IP address through mass-emailing/spear phishing - BUSTED• Attempts for server address obfuscation, proxy

servers with partial success

• Simplicity & A Business Model• Decoupling the malicious content delivery from the

fast-flux network operator

• Difficult to track down• Random compromised hosts, no traffic logging, live

proxying without remaining artifacts

June 2014

DNS Security 32

Single-flux

• Multiple compromised hosts’ IP addresses are mapped to a certain DNS hostname (A records)

• Compromised hosts act as front-end/reverse proxy for the malicious web server.

• Round robin DNS (e.g. 10 random hosts per DNS reply) -> robustness in case of disconnected hosts

• Short DNS TTLs (e.g. <5m) -> dynamismJune 2014

DNS Security 33

Single-flux

June 2014

Image taken from http://www.honeynet.org/papers/ff

DNS Security 34

Single-flux Example

June 2014

• Query A

• Query B

Images taken from http://www.honeynet.org/papers/ff

DNS Security 35

Double-flux

• Advancement over single-flux, compromised hosts appear as authoritative name servers for the specific DNS domain name. (NS records)

• Automated updating of the authoritative name servers records (e.g. registrar API)

• Additional layer of redundancy, availability

• Compromised host acting as authoritative nameserver also is a front-end/proxy for the mothership

June 2014

DNS Security 36

Double-flux

June 2014

Image taken from http://www.honeynet.org/papers/ff

DNS Security 37

Double-flux Example

• Query A

• Query B

June 2014Images taken from http://www.honeynet.org/papers/ff

DNS Security 38

Fast-flux Case Studies

• Warezov/Stration (2007)• Malware variants mainly used for spam

purposes• Phone-home for fetching updates (AV-evasion)• DNS services and download sites behind fast-

flux

• Storm (2007)• UDP-based P2P C&C botnet• Generating image-based spam instead of

template-based messaging• Adopting fast-flux networking scheme

June 2014

DNS Security 39

Fast-flux detection

• DNS monitoring of suspicious domain names• Short TTLs• Number of A records / response• Number of NS records / response• Diversity of IPs/networks/ASNs• Presence of broadband/dialup networks

• Detect upstream mothership node communication• Probe user networks for HTTP,DNS proxying

capabilities (e.g. accompanied with IDS or NetFlow monitoring)

June 2014

DNS Security 40

Fast-flux mitigation

• Block TCP 80 / UDP 53 into user-land networks• Block traffic to controller infrastructure

(motherships, registration, availability checkers)• Stricter DNS registrar policies• DNS Blackhole / BGP route injection against the

controller infrastructure• Passive DNS monitoring for A and NS records

from user networks• Control scripted name server configuration

updates / minimum acceptable TTL• Reputation systems for DNS

June 2014

DNS Security 41

Fast-flux Next Gen

• Slower change rate of IP addresses• 61% with > 60minutes/IP• More registrars, domain name space expansion, lower registration

costs

• Increased sharing of IP addresses and authoritative name servers among fast-flux domains

• Dual-purpose compromised hosts (acting as proxy and DNS servers in parallel)

• N-flux (ns*.flux.com, ns*.ns*.flux.com etc.)• Single IP address with TTL=0• Fast-flux like benign systems

• E.g. BitCoin DNS seed / node discovery (e.g. seed.bitcoin.sipa.be)• NTP DNS round-robin technique for picking a network time server• Content Delivery Networks (CDNs)• Anti-censorship solutions

June 2014

DNS Security 42

Domain Generation Algorithms

• Algorithms employed by malware for periodically generating large numbers of domain names• Used for contacting the controller nodes (e.g. updating their

capabilities, fetch commands)• Contacts a subset of the list, controllers register few new

domains sporadically -> NXDomain-based detection

• Avoids ‘hard-coded’ domain names in the binary (e.g. string dumping)• Even if the algorithm is reverse-engineered, sinkholing 1000s

of future domains is challenging

• Mostly date-based algorithms• Some even used Twitter APIs employing past trending topics

• Examples, Conficker, Torpig, murofet

June 2014

DNS Security 43

Custom DNS Servers

• Malware performs name resolutions against criminal-controlled DNS Servers

• Different view for the malware and the security researcher• May appear as non-existent domain through the

public DNS infrastructure

• Ability to use legitimate domain names for the botnet controllers (e.g. *.google.com)• False-negatives in security products

June 2014

DNS Security 44

Fluxing Domain Names

• Rogue ISPs removing malicious domain names soon after they get added in botnet tracking services (e.g. abuse.ch)

• Malware switches to backup URLs if the main C&C is not reachable

• Maintain a low profile on the law enforcement radar / low number of active botnet controllers

June 2014

DNS Security 45

Wildcard DNS records

• Many-to-one mapping• E.g. *.example.com. <IP address>

• Used in phishing campaigns• Evade host-name based blacklists

June 2014

46

Thank you!

Questions?

June 2014 DNS Security