Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Attacks/Breaches

8/30/2013
11:52 AM
Commentary
Commentary
Commentary
50%
50%

The Easiest Way To Deface A Website Is To Target The Domain Registrar

Hacking the DNS and domain maintenance systems makes for a much easier, safer, and efficient way of defacing the busiest and highest-profile websites on the Internet

Earlier this week there was yet another attack attributed to the Syrian Electronic Army (SEA). For a period of around six hours, some visitors to The New York Times, two Twitter services, and The Huffington Post's U.K. sites were redirected to pro-Assad political Web content. Many people naturally assumed that these high-profile websites had been hacked and then defaced, but in reality the attack was much simpler -- and the SEA attackers had no need to even touch a single server belonging to these organizations.

Despite being arguably the most critical component of the modern Internet, very few people really understand how DNS and, more specifically, domain maintenance works. In recent years, I think businesses with a significant Internet presence have grown to appreciate some of the threats that can affect their DNS infrastructure, but have yet to invest in suitable systems and response plans that'll help keep their sites and content accessible under anything more than the lightest touch of a competent hacker.

Unlike much of the infrastructure used by online businesses to serve content on the Internet or process transactions, DNS and domain registration is almost exclusively managed by third parties. In the majority of cases, these DNS and domain registration providers know their business pretty well, but there's often a big disconnect between the security of their operations and that of their largest clients.

For example, for websites that receive 50,000-plus unique visitors per day or process more than 1,000 financial transactions per hour, you can be pretty sure that they're running current generation perimeter defense systems (NGFW, IPS, DLP, etc.), undergo regular and extensive security reviews and penetration testing, and are generally monitored in real-time by a back-office contingent of seasoned system administrators and product managers -- by the business themselves.

Meanwhile, DNS is hosted by one third party, domain registration is likely managed by another one, and none of the security defenses or alerting systems feeds back to the client. Oh, and the domain registration provider may be the same folks who the company originally purchased the domain name 15 years ago.

From a hacker's perspective, going after the target's DNS infrastructure or domain management portal represents a soft target.

Hacking a modern Web server cluster, subverting it to your political cause, and having that message presented to thousands of site visitors for more than five minutes is a difficult task. Hacking the hosting infrastructure of a major Internet business or service provider is often considerably harder. Meanwhile, targeting and subverting a small DNS hosting provider or obtaining the administration credentials for the domain registration portal is a much easier proposition -- the attacker probably doesn't even need to touch any systems owned and operated by their ultimate target. Once key DNS entries have been altered, the attackers can appear to have compromised the target's Web services for hours (if not days), as the updated entries propagate around the Internet.

While the end effect is the same, the hacks against the DNS server or the domain registration process are technically quite different. Hacking a DNS server, on one hand, is much like hacking any other infrastructure device, but there are also a lot of additional attack vectors that specifically target weaknesses in the way the DNS application and database operates -- looking to affect caching glitches, exploit DNS service vulnerabilities, usurp administrative access controls, or by simply guessing a management account.

Hacking the domain registration system tends to be a different beast. In most cases, hacks against the system focus on obtaining the access credentials of the domain owner or administrator. For example, in the SEA attack earlier this week, the attackers are said to have employed a spearphishing attack against staff at a Melbourne IT reseller to capture administrator-level account details, and used them to edit the name server fields. By changing the name server fields for the targeted domains, the SEA was able to redirect all Internet lookups for those particular top-level domains (TLDs) to DNS servers it controlled, and those DNS servers, in turn, answered inbound lookup queries for hosts (and services) associated with those TLDs with the IP addresses of servers they controlled -- serving up pro-Assad political content.

I've constantly found the domain registration and administrative process to be weak and haphazard. In the first phases of a penetration test, during the passive information gathering phase, it's easy to identify administrative weaknesses in the domain registration details from even a quick WHOIS lookup. When you start to enumerate which accounts can maintain a domain entry (i.e., via the "mnt-by:" tag), and those that still rely on an authentication password protected by a lowly MD5 hash (i.e., "auth: MD5-PW"), you're bound to shake your head in disbelief.

My advice to organizations looking to protect themselves from similar DNS and domain registry level attacks is, in the first order, choose a DNS provider and domain registrar that can prove they've invested in the appropriate level of perimeter defense systems and response strategies -- ideally at a level comparable (or better) than your own. In this particular service tree of the Internet, you really do get what you pay for.

Second, when you're assessing the security of your key websites and Internet accessible infrastructure, make sure that your DNS and domain registrars are not only included in the passive information gathering stages, but are also within the scope of a penetration test or red-team exercise.

Finally, you should "harden" your domain administration processes -- ensuring that you're using strong authentication and change control procedures and, where possible, you've locked the domain via the "registry-lock" and "registrar-lock" options.

A warning, though: Even after performing these actions, DNS and domain maintenance processes will remain one of the weaker points of your Internet security stature. Vigilance is advised. Recognize that this is a continued weak spot, ensure that you monitor for changes continuously, and vet incident response plans appropriately.

Gunter Ollmann, CTO, IOActive Inc.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
How Attackers Infiltrate the Supply Chain & What to Do About It
Shay Nahari, Head of Red-Team Services at CyberArk,  7/16/2019
US Mayors Commit to Just Saying No to Ransomware
Robert Lemos, Contributing Writer,  7/16/2019
The Problem with Proprietary Testing: NSS Labs vs. CrowdStrike
Brian Monkman, Executive Director at NetSecOPEN,  7/19/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Building and Managing an IT Security Operations Program
As cyber threats grow, many organizations are building security operations centers (SOCs) to improve their defenses. In this Tech Digest you will learn tips on how to get the most out of a SOC in your organization - and what to do if you can't afford to build one.
Flash Poll
The State of IT Operations and Cybersecurity Operations
The State of IT Operations and Cybersecurity Operations
Your enterprise's cyber risk may depend upon the relationship between the IT team and the security team. Heres some insight on what's working and what isn't in the data center.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-12551
PUBLISHED: 2019-07-22
In SweetScape 010 Editor 9.0.1, improper validation of arguments in the internal implementation of the Memcpy function (provided by the scripting engine) allows an attacker to overwrite arbitrary memory, which could lead to code execution.
CVE-2019-12552
PUBLISHED: 2019-07-22
In SweetScape 010 Editor 9.0.1, an integer overflow during the initialization of variables could allow an attacker to cause a denial of service.
CVE-2019-3414
PUBLISHED: 2019-07-22
All versions up to V1.19.20.02 of ZTE OTCP product are impacted by XSS vulnerability. Due to XSS, when an attacker invokes the security management to obtain the resources of the specified operation code owned by a user, the malicious script code could be transmitted in the parameter. If the front en...
CVE-2019-10102
PUBLISHED: 2019-07-22
tcpdump.org tcpdump 4.9.2 is affected by: CWE-126: Buffer Over-read. The impact is: May expose Saved Frame Pointer, Return Address etc. on stack. The component is: line 234: "ND_PRINT((ndo, "%s", buf));", in function named "print_prefix", in "print-hncp.c". Th...
CVE-2019-10102
PUBLISHED: 2019-07-22
aubio 0.4.8 and earlier is affected by: null pointer. The impact is: crash. The component is: filterbank. The attack vector is: pass invalid arguments to new_aubio_filterbank. The fixed version is: after commit eda95c9c22b4f0b466ae94c4708765eaae6e709e.