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

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.

 

 
Navigating Security in the Cloud
Diya Jolly, Chief Product Officer, Okta,  12/4/2019
SOC 2s & Third-Party Assessments: How to Prevent Them from Being Used in a Data Breach Lawsuit
Beth Burgin Waller, Chair, Cybersecurity & Data Privacy Practice , Woods Rogers PLC,  12/5/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Navigating the Deluge of Security Data
In this Tech Digest, Dark Reading shares the experiences of some top security practitioners as they navigate volumes of security data. We examine some examples of how enterprises can cull this data to find the clues they need.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-19645
PUBLISHED: 2019-12-09
alter.c in SQLite through 3.30.1 allows attackers to trigger infinite recursion via certain types of self-referential views in conjunction with ALTER TABLE statements.
CVE-2019-19678
PUBLISHED: 2019-12-09
In "Xray Test Management for Jira" prior to version 3.5.5, remote authenticated attackers can cause XSS in the generic field entry point via the Generic Test Definition field of a new Generic Test issue.
CVE-2019-19679
PUBLISHED: 2019-12-09
In "Xray Test Management for Jira" prior to version 3.5.5, remote authenticated attackers can cause XSS in the Pre-Condition Summary entry point via the summary field of a Create Pre-Condition action for a new Test Issue.
CVE-2019-19647
PUBLISHED: 2019-12-09
radare2 through 4.0.0 lacks validation of the content variable in the function r_asm_pseudo_incbin at libr/asm/asm.c, ultimately leading to an arbitrary write. This allows remote attackers to cause a denial of service (application crash) or possibly have unspecified other impact via crafted input.
CVE-2019-19648
PUBLISHED: 2019-12-09
In the macho_parse_file functionality in macho/macho.c of YARA 3.11.0, command_size may be inconsistent with the real size. A specially crafted MachO file can cause an out-of-bounds memory access, resulting in Denial of Service (application crash) or potential code execution.