The document discusses various DNS security threats such as DNS hijacking, cache poisoning, and tunneling. It provides examples of how DNS tunneling works by encoding data in domain names and using subdomains for communication. The document also outlines some mitigation techniques for DNS tunneling, including payload analysis, traffic analysis, and restricting unusual DNS behaviors and record types.
2. So we’ve talked about
• DNS cache-poisoning and DNSsec
Lets talk about a few other possibilities
• DNS hijacking (a specific use-case)
• DNS tunneling
3. The Typical TLS (SSL) Web Interaction
Web
Server
Web
Browser
https://example.com/
TLS-encrypted
web page
DNS
Resolver
example.com?
10.1.1.1231
2
5
6
DNS Svr
example.com
DNS Svr
.com
DNS Svr
root
3
10.1.1.123
4
4. The Typical TLS (SSL) Web Interaction
Web
Server
Web
Browser
https://example.com/
TLS-encrypted
web page
DNS
Resolver
10.1.1.1231
2
5
6
DNS Svr
example.com
DNS Svr
.com
DNS Svr
root
3
10.1.1.123
4
Is this encrypted
with the
CORRECT
certificate?
example.com?
6. DNS-Based Authentication of Named Entities
(DANE)
How do you know if theTLS (SSL) certificate is the correct one
the site wants you to use?
• Store the certificate (or fingerprint) in DNS (newTLSA record)
and sign it with DNSSEC.
7. DANE
Web
Server
Web
Browser
w/DANE
https://example.com/
TLS-encrypted web page
with CORRECT certificate
DNS
Server
10.1.1.123
DNSKEY
RRSIGs
TLSA
1
2
Firewall
(or
attacker)
https://example.com/
TLS-encrypted web page
with NEW certificate
(re-signed by firewall)
Log files
or other
servers
DANE-equipped browser
compares TLS certificate
with what DNS / DNSSEC
says it should be.
example.com?
8.
9. DANE – Different operation modes
("certificate usage" field)
• 0 – CA specification
• The TLSA record specifies the Certificate Authority (CA) who will provide TLS certificates
for the domain. Must be a valid CA included in browser/app.
• 1 – Specific TLS certificate
• The TLSA record specifies the exact TLS certificate that should be used for the domain.
Note that this TLS certificate must be one that is issued by a valid CA.
• 2 – Trust anchor assertion
• The TLSA record specifies the “trust anchor” to be used for validating the TLS certificates
for the domain. Allows for the use of a CA not included in application.
• 3 – Domain-issued certificate
• The TLS record specifies the exact TLS certificate that should be used for the domain, BUT,
in contrast to usage #1, the TLS certificate does not need to be signed by a valid CA. This
allows for the use of self-signed certificates.
11. DNS as a covert channel
• Can we ??? What do you think -Yes/No/Maybe
• Well WHY NOT
• 2 types of covert channels - DNS could potentially use
• Storage
• Timing
12. DNS tunneling
• DNS tunneling allows you to conceal (well sort of but rather
the right word is “encode”) data within a DNS message
• Includes application protocol data - why not, its just data
• and transport it to any destination
• But ‘HOW’ and ‘WHERE’ would you hide data ?
13. Popular DNS tunneling tools
• Ozyman,TCP-over-DNS, Iodine, Dns2tcp, DNScat and,
DeNiSe, NSTX
• Ty Miller (Black Hat 2008)
• Heyuka
14. What can you do with this stuff ?
• A common motivation for these tools is to get free Wi-Fi access for sites with a captive portal for http,
but free flowing DNS.
• A DNS tunnel can be used for as a full remote control channel for a compromised internal host.
Capabilities include Operating System (OS) commands, file transfers or even a full IP tunnel.
• For example, data exfiltration via DNS tunneling is a method incorporated in to the squeeza
penetration testing tool (Haroon, 2007).
• These tools can also be used as a covert channel for malware. For example, Feederbot (Dietrich, 2011)
and Moto (Mullaney, 2011) are known to use DNS as a communication method.
• Common uses – covert communication channels, data exfiltration
15. Ok !!! So how does this work ?
The core techniques used by all DNS tunneling utilities include
• a controlled domain or subdomain
• a server side component
• a client side component and
• data encoded in DNS payloads.
16. A quick and dirty example
• the client sends anA record request where the data is encoded the in
host name:
MRZGS3TLEBWW64TFEBXXMYLMORUW4ZI.t.example.com.
• The server could respond with an answer as a CNAME response:
NVWW2IDPOZQWY5DJNZSQ.t.example.com.
17. Communication or Data Exfiltration using
sub-domains
• The only characters allowed within domain names are a-z,
A-Z, 0-9, hyphens, periods
• General encoding techniques base32/base64
• Usual followed with
• Compression to minimize traffic
• Encryption is also possible
18. Mitigations
• No single silver bullet.
• Mitigations could fall into 2 types of categories
• Payload analysis
• Traffic analysis
19. Payload analysis
• Size of request and response
• Entropy of hostnames
• Statistical analysis
• Uncommon record types
• Signature matching
20. Traffic analysis
• Volume of DNS traffic per IP address
• Volume of DNS traffic per domain
• Number of hostnames per domain
• Domain history
• Volume of NXDomain responses
21. DNS Protection is Not Just About DDoS
DNS reflection/DDoS attacks
Using third-party DNS servers (mostly open resolvers) to propagate a
DoS or DDoS attack
DNS amplification
Using a specially crafted query to create an amplified response to flood
the victim with traffic
TCP/UDP/ICMP floods
Denial of service on layer 3 or 4 by bringing a network or service down by
flooding it with large amounts of traffic
DNS-based exploits Attacks that exploit bugs or vulnerabilities in the DNS software
DNS cache poisoning Corruption of DNS server cache data with a rogue domain or IP
Protocol anomalies
Causing the server to crash by sending malformed DNS packets and
queries
Reconnaissance
Attempts by hackers to get information on the network environment
before launching a DDoS or other type of attack
DNS tunneling
Tunneling of another protocol through DNS port 53 for malware insertion
and/or data exfiltration
Volumetric/DDoSAttacks
DNS hijacking
Modifying the DNS record settings to point to a rogue DNS server or
domain
NXDomain attack
Attacks that flood DNS server with requests for non-existent domains,
causing it to send NXDomain (non-existent domain) responses
Phantom domain attack Attacks where a DNS resolver is forced to resolve multiple non-existent
domains, causing it to consume resources while waiting for responses
DNS-specific Exploits
Editor's Notes
An application that understand DNSSEC and DANE will then know when the required certificate is NOT being used.
Certificate stored in DNS is controlled by the domain name holder. It could be a certificate signed by a CA or a self-signed certificate.
Key point - who is really looking for this stuff
Well pretty much anywhere in any portion of a DNS message -
Queries – subdomains, TXIDs etc.
Responses - CNAME, TXT records, IP addresses etc.
Most of these use covert storage channels like encoding data into subdomains
Some also use TXT records to exfiltrate data in responses as TXT records allow free form text to be included in the response
Reverse DNS tunneling Shellcode
increasing their bandwidth from 5 bits per character to 8 bits per character.
Additionally, they took advantage of EDNS0 to increase the bandwidth ceiling from 512 bytes per packet to 1024 bytes per packet.
Covertness was added by spoofing packets across a range of IP addresses instead of from a single system
NSTX (very popular – allows for full IP tunneling)
The controlled domain is used to define the authoritative name server for that domain or subdomain.
The core technique is to encode data in DNS payloads. This is an area where the specifics of each utility vary widely. From a high level simplified point of view, the client wants to send data to server. It will encode that data in the DNS payload. For example
Entropy of hostnames – character frequency analysis – encoded names have even use of character set.
Statistical analysis – looking for measureable statistical anomalies such as % of numerical characters encoded in domain, % of length of longest meaningful substring,
Domain history – blacklisted domans etc.
For general computing a DNS request is only made prior to another request, for example a web page request over http. With this in mind another detection method is to look for DNS requests that don‘t have a corresponding request by another application such as http.
These are some of the key attacks we’ve seen growing in number in the last year…
This list is always growing as malware architects find new ways and workarounds to exploit vulnerabilities in DNS protocols.
The blue font indicates Volumetric or DDoS DNS attacks, such as amplification or reflection where a victim’s device is flooded with an overwhelming amount of traffic.
Some in-line devices and cloud vendors can rate-limit to slow down these attacks– they will try to scale out their infrastructure to meet the firepower of the DDoS attack itself.
But the attackers always seem to find a way to launch a bigger attack. If you remember from earlier in the course, most DDoS attacks today are exceeding 200Gb in size!
The red font indicates DNS specific exploits. These attacks are very difficult for IPS, DPI devices, and Nex Gen firewalls to mitigate because they’re not designed for DNS protocol.
See your power point notes to learn more about each of these attacks, and how Infoblox Advanced DNS Protection protects against ALL of them.
<name each one>
<Additional Information>
DNS reflection/DrDoS attacks
Reflection attacks are attacks that use a third party DNS server, mostly an open resolver in the internet, to propagate a DDoS attack on the victim’s server. A recursive server will process queries from any IP address and return responses. An attacker spoofs the DNS queries he sends to the recursive server by including the victim’s IP address as the source IP in the queries. So when the recursive name server receives the requests, it sends all the responses to the victim’s IP address.
DrDoS or Distributed Reflection Denial of Service uses multiple such open resolvers, thereby creating a Denial of Service (DoS).
DNS amplification
DNS amplification is an attack where a large number of specially crafted DNS queries are sent to the victim server. These result in a very large response that can reach up to 70 times the size of the request. Since DNS relies on the User Datagram Protocol (UDP), the attacker can use a small volume of outbound traffic to cause the DNS server to generate a much larger volume. The the amplification of outbound responses congests the DNS server’s outbound bandwidth. This results in a Denial of Service (DoS).
DNS-based exploits
These are attacks that exploit vulnerabilities in the DNS software. This causes the DNS software to terminate abnormally, causing the server to stop responding or crash.
TCP/UDP/ICMP floods
These are volumetric attacks with massive numbers of packets that consume a network’s bandwidth and resources. Attackers can also use BGP, OSPF, NTP, or ICMP (Ping of Death, Smurf) protocols to bring down servers or network devices.
-------------------------------------
Additional attack types with more detailed descriptions:
TCP SYN floods consist of large volumes of half-opened TCP connections. This attack takes advantage of the way TCP establishes connections. The attacking software generates spoofed packets that appear to the server to be valid new connections. These packets enter the queue, but the connection is never completed—leaving false connections in the queue until they time out. The system under attack quits responding to new connections until the attack stops. This means the server is not responding to legitimate requests from clients to open new connections, resulting in a Denial of Service (DoS).
UDP floods send large numbers of UDP packets to random ports on a remote server, which checks for applications listening to the port but doesn’t find them. The remote server is then forced to return a large number of ICMP Destination Unreachable packets to the attacker saying that the destination is unreachable. The attacker can also spoof the return IP address so that the replies don’t go to the attacker’s servers. Sending the replies exhausts the victim server’s resources and causes it to become unreachable.
ICMP attacks use network devices like routers to send error messages when a requested service is not available or the remote server cannot be reached. Examples of ICMP attacks include ping floods, ping-of-death and smurf attacks. This overwhelms the victim server or causes it to crash due to overflow of memory buffers
DNS cache poisoning
Corruption of DNS cache data. It involves inserting a false address record for an Internet domain into the DNS query. If the DNS server accepts the record, subsequent requests for the address of the domain are answered with the address of a server controlled by the attacker. For as long as the false entry is cached, incoming web requests and emails will go to the attacker’s address. New cache-poisoning attacks such as the “birthday paradox” use brute force, flooding DNS responses and queries at the same time, hoping to get a match on one of the responses and poison the cache. Cache poisoning prevents access or helps to redirect the clients to a rogue address (hijacking), preventing legitimate users from accessing the company’s site.
Protocol anomalies
Send malformed DNS packets, including unexpected header and payload values, to the targeted server. Even though the packet size may be the same, the payload contents may not. Attackers make use of software bugs in protocol parsing and processing implementation. The victim server stops responding by going into an infinite loop or crashes.
Reconnaissance
This attack consists of attempts to get information on the network environment before launching a large DDoS or other type of attack. Techniques include port scanning and finding versions and authors. These attacks exhibit abnormal behavior patterns that, if identified, can provide early warning. No direct effect on the server but indicates an impending attack.
DNS tunneling
This attack involves tunneling another protocol through DNS port 53—which is allowed if the firewall is configured to carry non-DNS traffic—for the purposes of malware insertion and/or data exfiltration. A free ISC-licensed tunneling application for forwarding IPv4 traffic through DNS servers is widely used in this kind of attack.
How Infoblox protects against these attacks:
Smart rate thresholds can put the brakes on DNS DDoS and flood attacks— without denying services to legitimate users. Smart rate thresholds use Advanced DNS Protection’s ability to discriminate between different query types and rates associated with them. For example, a downstream DNS caching server might generate 100 times base traffic compared to a normal desktop source, and this traffic might be legitimate. An HTTP or mail proxy server has a higher DNS traffic demand, which is legitimate. So basic rate limiting is ineffective (they either cause too much false positive, or provide too large a gap). The key to flood control is smart rate thresholds.
Source-based throttling detects abnormal query rate increase by source IP and applying rate limits. There is a counter per IP address and if we get too many operations per second from that IP, rate limits will be applied to that traffic.
Destination-based throttling detects abnormal increases in traffic grouped by target domains.
For anomalies and exploits, Advanced DNS Protection ensures the packets are valid DNS packets and then analyzes those packets for patterns of exploits that target specific vulnerabilities before they reach the DNS software. The definition of a good packet has been tightened based on extensive analysis. Input validation failures include: DNS UDP packets when the DNS question name or label is too long, invalid question count, invalid number of entries in the question section, invalid question class or resource record. It also drops DNS UDP packets when incremental zone transfer requests contain zero or more than one authority or an invalid authority.
For cache poisoning, Advanced DNS Protection can reduce the window of DNS resolver response acceptance and uses rate limiting and packet response matching to mitigate this attack. This rule passes DNS UDP response packets from upstream DNS servers or external DNS primaries if the packet rate is less than the packets per second value setting. If any source IP sends packets over this value, the appliance blocks all such traffic from this source IP for a certain period of time. It offers similar mitigation for DNS ACK packets from NIOS initiated connections.
For reconnaissance, Advanced DNS Protection drops UDP packets requesting information on authors and/or version information.
For tunneling, the anti-tunneling rule passes a large amount of inbound UDP DNS queries if the packet rate is less than the packets per second value (default = 2). If any source IP sends packets over this value, the appliance blocks all such traffic from this source IP for a certain period of time.