Attacks/Breaches

DHS Issues Emergency Directive on DNS Security

All government domain owners are instructed to take immediate steps to strengthen the security of their DNS servers following a successful hacking campaign.

On Jan. 22, US-CERT issued notice of a CISA emergency directive on DNS infrastructure tampering. The notice was the typically brief CERT notice, but it linked to an emergency directive at cyber.dhs.gov that called on anyone managing .gov or other agency-managed domains to take a series of steps aimed at remedial efforts — and to take those steps very quickly.

"The fact that they put out the warning means that there's been some sort of successful breach against a government site that they're recovering from," says John Todd, executive director at Quad9. "This type of warning means that there's been some damage."

Marc Rogers, executive director of cybersecurity at Okta, agrees. "CERT puts out notifications on a regular basis, but I haven't seen one with such a strong sense of urgency before, which tells me that DHS is acting on actual knowledge of an ongoing attack," he says.

In the emergency directive, DHS said "attackers have redirected and intercepted web and mail traffic, and could do so for other networked services." The attacks began when someone stole, obtained, or compromised user credentials for an account able to make changes to the DNS records, the directive points out.

Most experts think the events alluded to in the emergency directive are related to a campaign of DNS attacks described by FireEye in a blog post dated Jan. 9. In that post, researchers said that attackers, most likely employed or sponsored by agencies in Iran, use a variety of techniques to gain access to and control over DNS servers. Once done, the result is activity that can compromise a variety of data and information types.

FireEye wrote that the attacks appeared to have begun as long ago as 2017, and prominently feature a technique first described by researchers at Cisco Talos in which the DNS "A" records are modified. This technique results in the attacker gaining a user's username, password, and domain credential, without producing any activity that would alert the user to a problem.

One of the ways in which attackers hide their activity is through the use of a counterfeit encryption certificate. "The attack described is heavily using 'Let's Encrypt,' which allows someone to easily get a certificate for a domain they control. The attackers went in, modified the records, then immediately got a certificate from Let's Encrypt, so people coming in from other domains won't get an error message," says Adnan Baykal, global technical adviser at the Global Cyber Alliance.

While the duration of the overall attack makes it highly unlikely that it was timed to take advantage of the current partial government shutdown, aspects of the shutdown have made it easier for the attack to succeed. "When you see that there are close to 100 certificates in federal domains that have expired during the shutdown, each one represents a serious risk for users who go to the site. This pushes up the risk of DNS hijacking," Rogers says.

Baykal agrees. "Visitors are getting browser errors, and people have no good way to tell whether the error is from an expired certificate or a spoofed certificate," he says.

These statements amplify the point that there's little for a site's visitors to do regarding possible DNS hijacking. "You need to use or have access to a validating recursive DNSsec resolver," Todd says. "You can use a service that tries to give me an accurate answer, and if it's not accurate, it fails the request." He notes, though, that most users rely on their ISPs' DNS servers, few of which use DNSsec validation.

As for the emergency directive's mandates, they include auditing DNS records, changing passwords for accounts that have DNS administration privileges, and putting two-factor authentication into service — and doing it all within 10 days. "All of the remediation makes perfect sense based on the FireEye report. You’d hope that they would have done so earlier, but that horse has left the barn," says Cricket Liu, executive vice president of engineering and chief DNS architect at InfoBlox.

And the mandates shouldn't be ignored by those who aren't bound by the government directives. "This is a wakeup call for anyone who owns a domain. Although the US government is issuing the order, anyone anywhere in the world should be paying a lot of attention," Todd says.

Liu agrees. "The things they're recommended are a good idea for anyone, whether you're part of the federal government or not," he says. "All of these are a good idea, regardless."

Related Content:

Curtis Franklin Jr. is Senior Editor at Dark Reading. In this role he focuses on product and technology coverage for the publication. In addition he works on audio and video programming for Dark Reading and contributes to activities at Interop ITX, Black Hat, INsecurity, and ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Dr.T
50%
50%
Dr.T,
User Rank: Ninja
1/27/2019 | 6:26:00 PM
Re: When is a vulnerability not a vulnerability?
These are things that you should know and should already be embodied in your standards, Agree with this. Some just do not play by the book.
Dr.T
50%
50%
Dr.T,
User Rank: Ninja
1/27/2019 | 6:24:07 PM
Re: When is a vulnerability not a vulnerability?
Virtually everything on the list of required actions is a common sense thing that anyone administering DNS should do Agee. Another thing they should all do not to let certification expire.
Dr.T
50%
50%
Dr.T,
User Rank: Ninja
1/27/2019 | 6:22:21 PM
Re: When is a vulnerability not a vulnerability?
If your organization does security as a compliance checkbox for HIPAA or SOX Agree. This is one of the biggest problem I would consider, security for the shake of compliance.
Dr.T
50%
50%
Dr.T,
User Rank: Ninja
1/27/2019 | 6:21:21 PM
Re: When is a vulnerability not a vulnerability?
DHS has to tell us that in a way that makes people run around screaming the sky is falling?! I hear you. At the sand time any vulnerability can easily turn itself to a big issue to many people.
Dr.T
100%
0%
Dr.T,
User Rank: Ninja
1/27/2019 | 6:18:27 PM
Expired certificate
There is no excuse to let certificates be expired, those can be automated for extensions.
miletran168
50%
50%
miletran168,
User Rank: Apprentice
1/25/2019 | 10:20:28 PM
Re: When is a vulnerability not a vulnerability?
wow. so good. i think so
dan91266
100%
0%
dan91266,
User Rank: Strategist
1/24/2019 | 1:17:06 PM
Re: When is a vulnerability not a vulnerability?
I suppose there is some truth to that. However, I'm going to be harsh here; if you don't know these things you really have no business being a DNS administrator or in cybersecurity at all. These are things that you should know and should already be embodied in your standards, and if not followed the auditor should have pointed this out already. This just reeks of incompetence.
Curt Franklin
100%
0%
Curt Franklin,
User Rank: Author
1/24/2019 | 1:01:50 PM
Re: When is a vulnerability not a vulnerability?
To be fair, this is a directive to government admins, not the general public. Virtually everything on the list of required actions is a common sense thing that anyone administering DNS should do -- this is just requiring that the government (which was, by and large, supposed to have already done these things) do them right dammit now.

The "news" piece of this is that something happened (we haven't been told precisely what) that spurred this rather unusual emergency directive from DHS. It's a chance for the rest of us to learn from their mistakes.
dan91266
100%
0%
dan91266,
User Rank: Strategist
1/24/2019 | 11:37:10 AM
When is a vulnerability not a vulnerability?
This one just feels like Chicken Little to me. OMFG! If you're careless about your DNS registration, you can get Pwned.  Really? DHS has to tell us that in a way that makes people run around screaming the sky is falling?!  

This kind of security theater crap masquerading as vigilance gives us a bad name as a profession and contributes to alert fatigue.

 

How about this? If your DNS MX record or SOA record changes, and you don't notice, that might be a problem.

If you expose personal data from your DNS registrar and that person is also on Facebook and Linked In, you might have a problem.

If your DNS stops working right and you don't notice, you might have a problem. 

Yes indeed, you might a have a problem, but it's not the one DHS exposes in this overblown cry of "WOLF! WOLF!", the problem is you're doing security theater, not security.  

If your organization does security as a compliance checkbox for HIPAA or SOX, or just as a safe harbor for liability, you deserve to get Pwned by something as lame as social engineering your DNS registration. 

 

Meanwhile spare the rest of us warnings about the sky falling when it's just a fog bank.

 

 
When Your Sandbox Fails
Kowsik Guruswamy, Chief Technology Officer at Menlo Security,  4/11/2019
Julian Assange Arrested in London
Dark Reading Staff 4/11/2019
8 'SOC-as-a-Service' Offerings
Steve Zurier, Freelance Writer,  4/12/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
5 Emerging Cyber Threats to Watch for in 2019
Online attackers are constantly developing new, innovative ways to break into the enterprise. This Dark Reading Tech Digest gives an in-depth look at five emerging attack trends and exploits your security team should look out for, along with helpful recommendations on how you can prevent your organization from falling victim.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-1840
PUBLISHED: 2019-04-18
A vulnerability in the DHCPv6 input packet processor of Cisco Prime Network Registrar could allow an unauthenticated, remote attacker to restart the server and cause a denial of service (DoS) condition on the affected system. The vulnerability is due to incomplete user-supplied input validation when...
CVE-2019-1841
PUBLISHED: 2019-04-18
A vulnerability in the Software Image Management feature of Cisco DNA Center could allow an authenticated, remote attacker to access to internal services without additional authentication. The vulnerability is due to insufficient validation of user-supplied input. An attacker could exploit this vuln...
CVE-2019-1826
PUBLISHED: 2019-04-18
A vulnerability in the quality of service (QoS) feature of Cisco Aironet Series Access Points (APs) could allow an authenticated, adjacent attacker to cause a denial of service (DoS) condition on an affected device. The vulnerability is due to improper input validation on QoS fields within Wi-Fi fra...
CVE-2019-1829
PUBLISHED: 2019-04-18
A vulnerability in the CLI of Cisco Aironet Series Access Points (APs) could allow an authenticated, local attacker to gain access to the underlying Linux operating system (OS) without the proper authentication. The attacker would need valid administrator device credentials. The vulnerability is due...
CVE-2019-1830
PUBLISHED: 2019-04-18
A vulnerability in Locally Significant Certificate (LSC) management for the Cisco Wireless LAN Controller (WLC) could allow an authenticated, remote attacker to cause the device to unexpectedly restart, which causes a denial of service (DoS) condition. The attacker would need to have valid administr...