The Dirty Dozen of DNS Attacks

Gone are the old days where the DNS protocol could be drawn out, in its simplest form, on a napkin. Over the years, the protocol has evolved tremendously that many of us are quite frankly amazed that it still works. For the Domain Name System (DNS), we used all sorts of simple analogies like:

  • DNS as a “Directory Assistance Service”
  • DNS as a “Post Office”
  • DNS as a “Translator”
  • DNS as a “GPS System”
  • DNS as an “Address Book”
  • DNS as a “Switchboard Operator”
  • DNS as an “Index”

Well, it turns out, it is all of those things. That’s both exciting and frightening at the same time. All internet-facing standards lack the viability of their existence by sheer good will. In other words, they are all subject to abuse and attack since the internet doesn’t know boundaries when it facilitates global operation with impunity.

So it isn’t a surprise to anyone working in a SOC as a defender (or as a red-team/adversary simulation for that matter), that there are all sorts of opportunities to abuse the Domain Name System. Here is a list of twelve attacks that a security team needs to be aware of. Since this is the ADAMnetworks blog, we are including the ways that adam:ONE has a role (or not).

1. DNS hijacking - the good, the bad, the ugly

The Good

For legacy endpoints that are hard-coded to use public DNS resolvers (it’s amazing how often we find 10-year old IoT devices that use 8.8.8.8), hijacking-for-good gives endpoints the convenience of getting DNS answers, but with the security of being answered by policy. This is the adam:ONE way of ensuring device functionality while enforcing the policy it has been assigned to. Note the hijacking works only for legacy DNS on port 53 when running in clear-text mode.

In iptables the rules would look like this:

# iptables -t nat -L -n -v
...
Chain adamONE_PREROUTING (1 references)
 pkts bytes target     prot opt in     out     source               destination         
   48  3224 DNAT       udp  --  *      *       0.0.0.0/0           !192.168.50.1         udp dpt:53 to:192.168.50.1:53
   10   428 DNAT       tcp  --  *      *       0.0.0.0/0           !192.168.50.1         tcp dpt:53 to:192.168.50.1:53

Similarly, on pfSense/FreeBSD:

[24.11][admin@site1.anycorp.io]/root: pfctl -sa | grep 127.0.0.2
rdr on ix1 inet proto tcp from any to ! (self) port = domain -> 127.0.0.2
rdr on ix1 inet proto udp from any to ! (self) port = domain -> 127.0.0.2

Our standard managed deployment listens on 127.0.0.2 for this reason.

Other appliances take a more heavy-handed approach and packet-inspect for DNS queries. Given that protected networks utilized DTTS (Don’t Talk To Strangers), the simpler NAT hijack rule is all that is needed, and much more resource-efficient.

The Bad

When malware injects itself to an endpoint to hijack DNS queries so it can forward queries to an adversary’s DNS server in order to poison or re-direct to unintended destinations, bad things happen. The good news is that when such an endpoint is behind an adam:ONE environment as described above, the hijacking has no impact, because the security gateway hijacks the the malicious hijack.

The Ugly

This happens en masse when:

  • an upstream network such as the Internet Service Provider’s network is compromised
  • endpoints have not adopted encrypted DNS
  • no DNS firewall/security appliance exists between the endpoint and the upstream network

We saw this recently with nation state actors infiltrating service provider networks. This is also mitigated by ensuring the premises always use DNS encryption across internet backbones.

2. DNS Cache Poisoning

Attackers can poison a DNS cache by tricking DNS resolvers into caching false information, with the result that the resolver sends the wrong IP address to clients, and users attempting to navigate to a website will be directed to the wrong place. adam:ONE® is designed specifically to prevent its cache from being poisoned. This is done by using standards-based DNS encryption to trusted protective resolvers. Furthermore, DNS cache on adam:ONE is accessible on a per-policy basis. One policy may not have the same answer as compared to a different policy, even on the same network.

3. DNS Amplification

This is a reflection-based volumetric distributed denial-of-service (DDoS) attack in which an attacker leverages the functionality of any resolver in order to overwhelm a target server or network with an amplified amount of traffic, rendering the server and its surrounding infrastructure inaccessible. adam:ONE® is specifically designed to prevent this attack from being initiated on protected networks. This is achieved by legacy DNS being hijacked so internet-bound DNS queries (see above), including application attacks, never get outside the local network.

4. DNS Tunneling

DNS tunneling attacks exploit the DNS protocol to tunnel malware and other data through DNS queries to a domain controlled by the attacker. Sometimes it isn’t even the DNS protocol but exploiting the availability of port 53. adam:ONE® is designed to mitigate known exploitation techniques, specifically with Reflex, where DGA domains or newly-registered domains aren’t tagged as verified, and as such, are denied by policy.

5. DNS Flooding

DNS flooding is a type of distributed denial of service (DDoS) attack in which an attacker overwhelms DNS authoritative servers with a huge number of resolution requests. Such an attack can prevent DNS servers from responding to legitimate traffic. adam:ONE® is an optimized on-premise caching resolver, and is not used as an authoritative public service. However, anti-DDoS providers do offer DNS flooding protection.

6. Subdomain Attack / Sitting Ducks Attack

A subdomain takeover occurs when an attacker gains control over a subdomain of a target domain, or by exploiting an oversight called “lame delegation,” where domains mistakenly point to incorrect authoritative name servers. adam:ONE® does not offer any protection from this as it isn’t in the role of an authoritative server. However, mitigation is achieved with proper handling of the authoritative records on behalf of the domain owner.

7. Domain Generation Algorithm (DGA) Attack

In this technique, attackers churn out domain names and IP addresses for malware command and control servers. With adam:ONE® Reflex, any domain that is not yet verified and tagged as “unknown” can simply be blocked and is therefore unreachable and the risk is mitigated for any vulnerable user/endpoint to be able to reach a DGA domain.

8. DNS Rebinding

This leverages the Domain Name System (DNS) to run malicious JavaScript and attack devices on a user’s private network. adam:ONE® prevents this by default by preventing public FQDNs from resolving to rfc1918 IP addresses. This can be overridden for legitimate uses of public DNS records that resolve to private networks.

9. NXDOMAIN Attack

This attack targets authoritative servers. adam:ONE® does not play a role in protecting any authoritative servers. Mitigation boils down to having excess capacity to deal with unexpected surges. Protection can usually be obtained from anti-DDoS services.

10. DNSSEC bypass

Whenever an endpoint is not using DNS encryption, it is subject to interception of its DNS and can be completely unaware of an authoritative DNSSEC answer being different than an intercepted query/answer offering a non-DNSSEC answer. With DNS encryption, adam:ONE® is RFC9462 compliant and offers DoH/DoT to mitigate this for every protected endpoint.

11. DNS Pharming

DNS Pharming is a type of DNS attack where users are automatically redirected to a fake version of a website which often looks identical to that of the real website in order to steal personal information such as login credentials, email addresses and credit card details.
Mitigation offered by adam:ONE® is achieved in different attack styles by either DTTS and DNS Encryption, or Reflex, blocking DGA and unknown domains.

12. Traffic abusing port 53 but not for DNS

Since TCP/UDP port 53 is often open to the Internet, it is exploitable by abusing its port for any purpose whatsoever. As an example, if Psiphon fails at first to connect via web proxies, it will attempt to use port 53 to tunnel its VPN services among other tricks.

Conclusion

So there you have it. The simplicity of legacy DNS is gone, but it is as essential as ever to our lives and commerce online. Protecting against all of these attacks is not for the faint of heart, but we have your back. Our mission is to protect people and that’s only possible when we know what the attack vectors are and how we can seek and offer protection.