In my last blog post, part 1 of this series, I discussed the important role DNS plays in protecting service provider networks from DNS amplification attacks, and the necessity of not only blocking malicious queries but also of not blocking good queries. In this post, I’ll look at Pseudo-Random Subdomain (PRSD) attacks and other malware (like phishing and ransomware), showing why DNS is perfectly suited to protect both networks and subscribers.
Pseudo-Random Subdomain (PRSD) Attacks
I haven’t spoken to a single operator that hasn’t suffered from these types of DNS attacks. Most often the discussion involves outages. PRSD attacks are particularly nasty in the sense that they’re designed to starve the recursive DNS servers of recursive contexts, rendering them unusable to legitimate users. PRSD attacks started several years back and still have not gone away. PRSD traffic is generally always there, but the amount varies and can change quickly. PRSD activity can be <1% of all DNS traffic on any given day (but can drop to 0%), then without warning, can spike upwards of 15% or higher of all DNS query traffic, which presents enormous strain on the DNS infrastructure due to the influx of recursion that must occur. This shows the erratic and unpredictable nature of PRSD and why intelligent, proactive protection should be deployed on the DNS servers. Most operators I speak to try to solve this problem by manually capturing packets and trying to block them.
What Does a PRSD Attack Look Like?
Think of a legitimate DNS query for a web site; for example, www.nominum.com. This is a valid DNS query because it will return the IP address of the Nominum web site. Simple example. However, if the 1st label (the www part) was to be a random string (or seemingly random string), xsiejandi.nominum.com – what would this mean? Since the core domain (nominum.com) is registered, this will force the recursive DNS server in question to open a recursive context looking for that random string from Nominum’s authoritative servers.
If you aren’t completely familiar with the differences between caching & recursive DNS, please read our blog.
The result of course would be an NXDOMAIN response, that would then be placed into the DNS server’s negative cache (negative cache is caching of non-existent domains). Next, if the left label was changed again and again, with each query, then each query would trigger a recursive query to Nominum’s authoritative servers, consuming recursive contexts and populating the server’s negative cache with useless NXDOMAIN records. If this is compounded again across a number of clients at a reasonably high query rate, recursive contexts can be consumed. Generally, there’s an upper limit of recursive contexts that may be as low as 50,000. Once this is reached, it can impact legitimate recursion resulting in SERVFAIL responses.
This situation has been seen by most operators around APAC (and globally) in the past few years and is particularly difficult to prevent using traditional methods. This is because the queries themselves, despite being malicious in nature, are technically valid DNS queries. So, the DNS server is simply doing what the RFC requires it to do – perform recursion.
To be protected against this type of DNS attack, an intelligence-based approach must be used, rather than only volumetric, but the tools available will come down to the particular DNS servers that are being attacked. If a volumetric-only (i.e., limiting QPS) is used, then there is always the chance of collateral damage due to over blocking (that is, blocking legitimate queries). For example, we would not want to block access to www.nominum.com, but we would want to block xsiejandi.nominum.com (etc.) queries, so we must use intelligence to predict the future PRSD strings since they are generally created using DGAs (Domain Generation Algorithms). Additionally, we would also want the server to monitor responses (in real time) from the authoritative server. One additional challenge is that the strings are becoming less and less “random”. In some cases that I’ve seen, the strings are based on dictionary words. So, the appearance of a seemingly random strings is not enough to make a policy decision on.
What About Other Malware? Can DNS Help There?
Yes. DNS is used in over 91% of malware communication today vs. direct IP, to contact Command & Control (C&C) servers. Recent cases of ransomware attacks (Locky, etc.) provide examples where DNS is used for this communication. Additionally, phishing attacks that are used to distribute malware also rely on DNS. One example – the recent Google Docs phishing campaign – is explained in one of our Data Science team’s blog post.
In the more recent case of WannaCry/Crypt, DNS was used as a kill switch mechanism. This was not known initially, as it was thought to be C&C communication. However, queries to the kill switch domains gave operators a lot of insight as to which subscribers were infected with this malware. For more information on Nominum & WannaCry, please read our blog post.
In conclusion; DNS plays a major role in an overall network and subscriber security plan. DNS is not only an attack vector itself, it’s a major component of malware & phishing attacks today. This places DNS in a great position to not only be part of the problem but a major part of the solution. This is why it is critical to adopt a comprehensive security plan that involves DNS.