DNS Security

17 de May de 2015

Mais conteúdo relacionado


DNS Security

  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.) • • 13 root servers ( – 350+ instances (anycasting) • Root-servers TLD master file (TLD authoritative servers) • Secure / non-public update process • Authority & Delegation • Fully Qualified Domain Names ( 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.<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 @ hostname) • Reverse lookups • dig –x • Find a domain’s mail servers • dig 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 with the attacker’s IP address • Spoof NS entry of target domain to attacker’s IP • Query : • (Attacker) Answer : 86400 IN NS 604800 IN A • 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 ( • Spamhaus received a 300Gb/s DDoS June 2014 DNS Security 20
  21. DNS Amplification Attack June 2014 DNS Security 21 Image taken from
  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
  34. Single-flux Example June 2014 DNS Security 34 • Query A • Query B Images taken from
  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
  37. Double-flux Example • Query A • Query B June 2014 DNS Security 37 Images taken from
  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*, ns*.ns* etc.) • Single IP address with TTL=0 • Fast-flux like benign systems • E.g. BitCoin DNS seed / node discovery (e.g. • 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. * • 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. • 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. * <IP address> • Used in phishing campaigns • Evade host-name based blacklists June 2014 DNS Security 45
  46. Thank you! Questions? 46June 2014 DNS Security