The document discusses DNS security and various DNS attacks. It begins with an overview of the DNS protocol and infrastructure, then describes common DNS attacks like spoofing, cache poisoning, and reflection attacks. It also covers mitigation techniques like DNSSEC and discusses fast flux networks used by malware to evade detection. The document provides technical details on securing DNS servers and domains through configurations, software updates, and cryptographic protocols.

1. DNS Security
Spyridon Dosis
June 2014 DNS Security 1

2. Outline
• The DNS protocol / infrastructure / tools
• DNS Protocol Attacks
• Securing DNS
• DNSSec
• DNS abuse (fast-flux networks)
June 2014 DNS Security 2

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 3

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 4

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 5

6. DNS Primer
• DNS query workflow
June 2014 DNS Security 6

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 7

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-DLZ
June 2014 DNS Security 8

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, SRV
June 2014 DNS Security 9

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 10

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 11

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 12

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 13

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 14

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 15

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 16

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 17

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 18

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 19

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 20

21. DNS Amplification Attack
June 2014 DNS Security 21
Image taken from http://securitytnt.com/dns-amplification-attack/

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 servers
June 2014 DNS Security 22

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 23

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 24

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 25

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 26

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 27

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 28

29. Fast-flux networks
June 2014 DNS Security 29

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 30

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 31

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) -> dynamism
June 2014 DNS Security 32

33. Single-flux
June 2014 DNS Security 33
Image taken from http://www.honeynet.org/papers/ff

34. Single-flux Example
June 2014 DNS Security 34
• Query A
• Query B
Images taken from http://www.honeynet.org/papers/ff

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 35

36. Double-flux
June 2014 DNS Security 36
Image taken from http://www.honeynet.org/papers/ff

37. Double-flux Example
• Query A
• Query B
June 2014 DNS Security 37
Images taken from http://www.honeynet.org/papers/ff

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 38

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 39

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 40

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 41

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 42

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 43

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 44

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 DNS Security 45

46. Thank you!
Questions?
46June 2014 DNS Security