On the Anatomy of a DNS Attack – Types, Technical Capabilities, TTPs, and Mitigation
DNS Attack Classification. Prophylaxis and Mitigation(s)
The Domain Name System (DNS), with its quirks, kinks, and compulsion to create unnecessarily long acronyms is a world of its own (design). At this point, any DNS treatise, article, paper, or cheat-sheet, makes Encyclopedia Britannica’s letter “A” volume look like a “quit smoking” leaflet. There’s a perfectly sound reason behind DNS’s complexity – everything happening on your web browser right now, including you reading this article, is the Domain Name System weaving its magic.
Although I’m quite tempted to blabber away about the awesomeness of the Internet’s Yellow Pages, I’ll just stick with a quick refresher of what DNS is (and is not). The article you’re about to read is entirely dedicated to your friendly neighborhood hacker; probably the only person that can turn something as innocuous as an intelligent cooker into a full-fledged IED. So, without further ado, let’s take a closer look at the DNS attack. I’ll be covering classification, techniques, and available mitigation and\or fixes. Enjoy!
DNS 102 – Blast from the not-so-distant past
Just to refresh our memory (pun intended) about what DNS is and is not, I’ve jotted down some info that will definitely help you put things into context much easier.
DNS – stands for Domain Name System and, as I’ve mentioned in the intro, it’s the phone book of the Internet. The analogy is pretty neat, clearly illustrating how human-readable info (e.g., google.com, heimdalsecurity.com) can ‘dumbed down’ into forms that are machine-friendly. Tech talk coming to DNS is defined as a methodology that “provides translation of a networked machine’s (host’) name to a machine-readable IP address so that packets are routed over the network correctly.
Conversely, for security reasons, a server on the network may use “reverse lookup” in order to assure its administrators that the proper people are connected to it.” Cornell University really knows its DNS. So, for your browser to display your favorite website, the machine needs to know the IPv4 or IPv6 address associated with the name. Kind of a neat trick you would want to boast in front of your non-geeky friends: fire up a command prompt window, type in “nslookup” followed by the address of your favorite website. You’ll get the server’s address and its corresponding IP address. One more thing: this collection of IP-name addresses all fit in nicely into a big address book called the DNS record.
Resolvers – little delivery boys that fetch the numerical address of a queried, human-readable address.
DNS namespace hierarchy – The Library of Alexandria of DNS administrative domains. The hierarchy is as follows: the root of “.”, TLDs (Top-Level Domains) for things like “.edu”, “.com”, “.org”, SLDs (Second-Level Domains), Sub-Domain of Parent, and Host.
DHCP – stands for Dynamic Host Configuration Protocol and it’s used to fast-track the process of how devices use services such as DNS or NTP by automatically configuring IP assignation.
Still here? Well, if you’re not half bored to death, let’s talk about the various types of attacks that leverage vulnerability or design limitations found in the DNS.
DNS Attack Genealogy
As far as descriptive acronyms go, DoS really manages to capture the essence of this type of cyber-attack. Short for Denial-of-Service, this attack is aimed at barring users from a machine or a network by either exhausting its resources or effectively shutting it down. A least known fact about DoS(s) is that this type of action on target is mostly used to either hide tracks or to hamper the victim’s recovery efforts.
Basically, this would be the cherry on top. As far as variety is concerned, there are several kinds of DoS attacks, each levering a vulnerability or protocol\system\code limitation or…unexpected machine-side replies. DoS attacks are commonly employed by threat actors hunting down HVTs with advanced cyber protection. Anyway, before I go about the other attacks, I just want to show you this really nifty and simple DoS attack you can try at home. All you need are two virtual machines, one running Linux, and the other one running Windows.
I tried it out on Oracle’s VM VirtualBox, but you can probably use any type of OS emulation software. This attack is called the Ping of Death (boo-hoo-hoo!) and it’s used to crash, freeze, or force-reboot a server or another network-bound resource. PoD leverages a limitation TCP\IP packet transmission– the max limit is 65,536 bytes. Normally, if a data packet is larger than the admissible limit, it will be broken down into smaller packets. That’s called data fragmentation and it’s something very normal.
What’s not normal is using the ping command to send data packets larger than 65,536 bytes. The result – the server could freeze, crash or reboot. Now, to test out the Ping of Death attack, go ahead and set up the machines and then download this free PoD software on your Linux machine. Unpack, execute, and go crazy. Please be sure to do this in a controlled environment, otherwise, it may be construed as a hacking attempt. With this in mind, let’s now turn our attention to other DoS attacks.
Resource Depletion DoS attack.
First on the list is the so-called resource depletion DoS attack. Yup, you’ve guessed it – the attacker aims to trigger a DoS type of response in the victim’s machine by depleting the device’s resource pools: CPU, memory, disk, and network. For instance, the attacker can drive up the CPU consumption of a forum-type application hosted on a server by bombarding the victim with intricate REGEX queries using a self-launching script that basically loops those queries. Memory depletion is another type of Resource Depletion DoS attack – think about vulnerable email agents. A threat actor could trigger a memory depletion attack just by uploading hundreds of thousands of attachments to a draft mail.
Since unsent emails are stored locally, filling them to the bring with junk could exhaust the machine’s memory. How about disk depletion? Well, as you know, most apps produce logs which are pretty useful for figuring out what went wrong with an app. Logs take up just a few kilobytes. However, by knowing which ‘buttons’ to push in order to recreate a specific error, the threat actor can force the application to fill up all the available disk space with logs. Sure, takes a lot of time, consideration, research, and resources on both sides, but it can be done.
Network resource depletion DoS attack – now that’s a mouthful! To pull this stunt, the threat actor will need an open recursor (i.e., DNS server that talks with other DNS servers to fetch the IP address requested by the client) and, of course, the victim’s machine. What happens here is that the attacker will flood the open recursor with TCP-transmitted DNS packets, while assuming the victim’s IP address. Thinking of these legit requests, the name server will allocate resources for all resources until the pool is depleted, barring the real host from using these resources.
A type of vulnerability or rather limitation exploitation attack, BOA (Buffer Overflow Attack) aims to force the system to write memory to a nearby buffer instead of the intended spot. When the memory’s written in the buffer instead of the ‘regular’ place, it causes the application leveraging that memory to crash. This type of limitation is endemic to C-written applications. Buffer Overflow Attack can also be employed for purposes other than DoS. For instance, an attacker can potentially tamper or replace values in either the base pointer or the indicator pointer in order to execute malicious code.
Also called a ping flood, this kind of DoS attack abuses a common connectivity test for the purpose of crashing, freezing, rebooting, or render the target machine inoperable. Conventionally, the ICMP ping test is used to ascertain the strength of connectivity between two endpoints operating on the same network. How this works is that a machine sends an ICMP echo request to another machine. In turn, the receiver sends back an echo reply. By measuring the round-trip, you can determine the connection’s strength.
As you would imagine, an attacker can abuse the ICMP echo request-reply mechanism to overload the victim’s network. Although it may sound like a good place to start if you were to DoS a target, the attack itself does have some requirements: the attacker’s bandwidth must be larger than the victim’s bandwidth. More than that, the attacker must know the victim’s IP address in order to focus the attack. And, on top of that, the attacker must also dig up information on the victim’s router.
Also called a “half-open” attack, the SYN flood abuses the TCP\IP three-way handshake mechanism. I already covered the three-way handshake mechanism in a previous article. The way this works is that the attacker will trigger a deny user response in the server by repeatedly sending SYN packets and disregarding SYN-ACK, server-side packages.
Heimdal™ Threat Prevention - Endpoint
- Machine learning powered scans for all incoming online traffic;
- Stops data breaches before sensitive info can be exposed to the outside;
- Advanced DNS, HTTP and HTTPS filtering for all your endpoints;
- Protection against data leakage, APTs, ransomware and exploits;
DDoS is to volume, as DoS is to precision. Distributed Denial-of-Service attacks leveraged compromised hosts (bots) in order to launch full-scale DoS-type attacks on large targets. So, non-technically speaking, DoS is the lone wolf, striking with surgical precision, while DDoS is the general, who orders his soldiers into battle. DDoS attacks occur more frequently compared to simple DoS attacks. Why? Bots and botnets are readily available on the dark web and volumetric attacks have higher odds of success compared to DoS. Enough about that – let’s see some types of DDoS attacks.
Fairly similar to the SYN flood, this type of DDoS leverages the User Datagram Protocol (UDP) and UDP packets. Basically, the attacker will flood the user’s opened ports with a bunch of junk UDP packets. Thinking that these are legit UDP comm attempts, the host will attempt to listen on that port in search of the app sending those UDP packets. With no packets found, the host will have no choice but to reply with an ICMP unreachable destination packet. Well, as you would imagine this goes on and on until the host’s network resources are exhausted.
Works the same way as the DoS counterpart. The only difference here is volume – DDoS attacks have the advantage of hundreds or thousands of bots capable of ICMP flooding the victim at the same time.
Same DoS mechanism, but more ‘zombies’ to do the heavy lifting.
In Network Time Protocol (NTP) attacks the threat actor bombards public-facing NTP servers with UDP packets for DoS purposes. The name of the attack is given by how attackers exploit the so-called query-to-response ratio. Basically, the NTP server crashes when it’s no longer able to resolve all the queries received from the attacker.
Very efficient DDoS attack, levering the GET or POST reply-response mechanisms. What happens is that the threat actor sends as many legitimately GET or POST queries to the server, forcing it to answer each and every one of them. This resource-intensive replying process depletes server resources resulting in DoS.
Fast Flux is a very flashy and Tron-reminiscing name for masking botnets. Technically, it’s not an attack but rather an evasion method botnet operators employ to avoid detection. With fast flux, threat actors can quickly change between compromised hosts, rendering them invisible to detection tools.
Reflected Cross-Site Scripting attack (XSS)
During a reflected Cross-Site Scripting attack (XSS), the threat actor seeks to abuse the HTPP response issued by an application receiving a request, kind of like an echo. The point of this is to discover whether or not an application receiving an HTTP request performs any kind of data checks upon receiving a query. Here’s a quick example of this – some websites mirror back your search terms. So, if you search for something like “cat food”, you may receive a response such as <<you search for: “cat food”>>. Now, in unsecured websites, threat actors could leverage this improper data processing praxis to append malicious arguments in the URL, resulting in an XSS attack. Best thing about this: the attacker is not the one actually executing the attack. The blow would be dealt by the next user who searches for something on the website.
Mitigation(s) and parting thoughts
All of these attacks can severely disrupt operations, not to mention the fact that some DDoS and ransomware operators can destroy the data, device, or both after the attack’s done. So, let’s see about mitigation.
- Use legitimate cloud-based hosting.
- Availability monitoring.
- Registrar locking.
- Deep-packet inspection.
- Traffic-scrubbing filters.
- “The worst is yet to come rule”. Most DDoS attacks come in waves. The first wave is the attacker testing out defenses. Be sure to expect a second and even a third wave.
Resource Depletion DoS attack mitigation:
- Automatic Static and Dynamic analysis.
Buffer overflow mitigation:
- DEP (data execution prevention)
- Ensuring that the code is secure.
- Taking advantage of the compiler warning.
- Stack canaries.
ICMP flood mitigation:
- Curb the processing limit of inbound ICMP messages.
- Perimeter firewall fine-tuning.
SYN flood mitigation:
- Use the oldest half-open TCP\IP connection once the backlog’s full.
- SYN cookies.
UDP flood mitigation:
- Curb system response rate of ICMP packets.
HTTP flood mitigation:
- Traffic profiling.
- IP reputation.
NTP Amplification mitigation:
- Verify IP sources.
- Disable monlist.
Fast flux mitigation:
- Access control.
Reflected Cross-Site Scripting attack (XSS) mitigation:
- User cyber-awareness (don’t click on suspicious links, open emails from untrusted or unknown sources).
- Web application firewall.
One more thing before I go – coverage. The methods illustrated in the previous section can protect you only to a certain extent. Beyond that point, protection mostly falls into the trial-and-error zone. For that extra ounce of protection, you should definitely give Heimdal™ Threat Prevention-Endpoint a try – DNS traffic filtering, deep-packet inspection, and everything you can think of in terms of DNS attack prevention at your fingertips. Hope you’ve enjoyed this little repartee and, as always, stay safe, stay frosty, and reach out if you have any more questions.