In the early stages of the “Net” each computer system participating in this network could only be contacted by knowing it’s unique 32bit IP address. As the Net grew into the Internet that we know today, some changes had to be made to allow this system of interconnected computers to communicate with each other, and their human operators to make sense of these addresses.
In 1983, the concept of DNS (Domain Name Servers) became a reality by way of Paul Mockpetris, Jon Postel, and Zaw-Sing Su, who proposed this new nomenclature of finding websites by translating simple DNS names to their corresponding IP addresses. For over 30 years DNS has been the transparent mechanism that has allowed the global phenomenon of the Internet to work its way into every facet of our modern lives.
Why, might you ask, is this very system being used by attackers against us? The answer is more complex than you might think, but the problem is growing. Advisories continue to use age-old techniques to their advantage, and the security upgrades that were supposed to protect us are not being adopted.
In this article I’ll be sharing key techniques attackers have used to target DNS as both an attack conduit, as well as an attack tool itself. I’ll also share the top three things you can do in your own environment to help protect yourself from these attacks and do you part in securing the Internet.
Attack 1: Floods and Leaky Faucets
In early 2014, Akamai observed an attack against one of its customers in the gaming vertical based in the Asia Pacific region. The attack came in at 320gbps at peak, producing more than 71.5 million packets per second. But what was unique about this onslaught is that the attacker also produced an unprecedented 2.1 million requests per second of legitimate DNS queries against that organization’s DNS servers.
DNS resiliency will always be in the forefront of reliable service of any online system, but other faults in the modern business ecosystem start to emerge. Even if the DNS provider stays online and can respond to all of these DNS queries, the modern “cloud service” billing model makes no way to abstract this query flood from normal service. Thus, the victim organization is charged for all the queries it successfully responded to. I call this type of attack the “leaking faucet,” as it takes advantage of the variability of the modern “pay for use” cloud billing structure. GET floods (of legitimate requests) against a CDN customer’s “hero image” etc., if the CDN does its job and serves this traffic, guess what? You get to pay for it! This is a risk that must be managed as well. But let’s get back to DNS.
Attack 2: Hijacking the keys to your Domain
The attack du jour in the headlines today is DNS Hijacking. This is nothing new, but I’ll briefly explain how it occurs. Due to operational flaws in how Domain/Hosting Providers manage access to make changes to DNS hosting settings, attackers use well known social engineering methods to “trick” the provider into allowing an illegitimate change to be made to an organization’s DNS record. Below is a phishing email that was used to trick domain owners into replying back to the attacker with the exact info their registrar required for them to make changes to their DNS records.
A common change would be to take the “A” record of that domain and point it to an all-together different IP address owned by the attacker which contains a “YOU’VE BEEN PWND” message superimposed on a copy of the corporate website. In years past this happened to many different organizations, from a U.S. Government-owned website to that of a luxury auto manufacturer.
The key to reducing your risk against attacks like this is by making changes in two areas. The first is to make changes to your DNS by setting Client and Registrar settings to prohibit unauthorized changes. The second has to do with the process in which you allow changes to be made to your DNS zone via your registrar. Just like getting an EVSSL (Extended Validation) SSL/TLS cert requires a “more rigorous” series of processes and paperwork to be completed, you can also review with your registrar what processes and controls are in place before any changes can be made to your zone settings.
Attack 3: Attacking the APEX Domain
An APEX record is like a TLD (Top-Level Domain) which refers to the part that follows immediately after the “dot” symbol. The main difference is that TLD’s refer to the .COM/.NET of a domain name where an APEX record exists for a domain found by only requesting the TOP of that DNS Zone record. It’s also commonly referred to as a root domain since it does not contain a subdomain part. So, the APEX domain for a domain normally requested as www.xyz[.]com would simply be xyz[.]com.
Attackers have taken advantage of yet another side hustle attack against organizations making the digital conversion to using cloud services to augment their own domain services. One example would be an organization that hosts their own authoritative servers for xyz.com out of their own datacenter. Knowing that they need to leverage a cloud provider to protect them from DNS based attacks, they use Cloudy-DNS (fictional company) to be a secondary name server for them, but configures the authoritative name server to remain within their own datacenter.
The problem presents itself when the attacker, using some simple recon, realizes that the authoritative responses for this domain must come from the onsite DNS servers that the organization houses in their datacenter.
The reason is that according to IETF RFC 1035 the SOA (Start of Authority) record is forced to direct responses from the delegated DNS name server back to the authoritative name servers which manage the domain field of those top-level responses. This means that a query flood attack against www.xyz[.]com would be handled by the Cloudy-DNS name servers, but an attack on the Zone APEX at xyz[.]com would be forced back to the DNS servers in the datacenter flooding those limited resources and exposing the IP space. Doing reverse queries against the corresponding IP space might now reveal more attack surface to the attacker.
Though this was not meant to be a comprehensive list, hopefully this has demonstrated several attack methods that aren’t always top of mind and warrant some attention to see how your own settings and operational procedures stack up.
(Tony Lauro manages the Enterprise Security Architecture team at Akamai Technologies. With over 20 years of information security industry experience, Tony has worked and consulted in many verticals including finance, automotive, medical/healthcare, enterprise, and mobile applications. He is currently responsible for Akamai‘s North America clients as well as the training of an Akamai internal group whose focus is on Web Application Security and adversarial resiliency disciplines. Tony‘s previous responsibilities include consulting with public sector/government clients at Akamai, managing security operations for a mobile payments company, and overseeing security and compliance responsibilities for a global financial software services organization.)
