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
Threaded  |  Newest First  |  Oldest First
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.

 

 
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 | 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.
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.
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
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
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
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.
Microsoft Patches Wormable RCE Vulns in Remote Desktop Services
Kelly Sheridan, Staff Editor, Dark Reading,  8/13/2019
The Mainframe Is Seeing a Resurgence. Is Security Keeping Pace?
Ray Overby, Co-Founder & President at Key Resources, Inc.,  8/15/2019
GitHub Named in Capital One Breach Lawsuit
Dark Reading Staff 8/14/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
7 Threats & Disruptive Forces Changing the Face of Cybersecurity
This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
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-15132
PUBLISHED: 2019-08-17
Zabbix through 4.4.0alpha1 allows User Enumeration. With login requests, it is possible to enumerate application usernames based on the variability of server responses (e.g., the "Login name or password is incorrect" and "No permissions for system access" messages, or just blocki...
CVE-2019-15133
PUBLISHED: 2019-08-17
In GIFLIB before 2019-02-16, a malformed GIF file triggers a divide-by-zero exception in the decoder function DGifSlurp in dgif_lib.c if the height field of the ImageSize data structure is equal to zero.
CVE-2019-15134
PUBLISHED: 2019-08-17
RIOT through 2019.07 contains a memory leak in the TCP implementation (gnrc_tcp), allowing an attacker to consume all memory available for network packets and thus effectively stopping all network threads from working. This is related to _receive in sys/net/gnrc/transport_layer/tcp/gnrc_tcp_eventloo...
CVE-2019-14937
PUBLISHED: 2019-08-17
REDCap before 9.3.0 allows time-based SQL injection in the edit calendar event via the cal_id parameter, such as cal_id=55 and sleep(3) to Calendar/calendar_popup_ajax.php. The attacker can obtain a user's login sessionid from the database, and then re-login into REDCap to compromise all data.
CVE-2019-13069
PUBLISHED: 2019-08-17
extenua SilverSHielD 6.x fails to secure its ProgramData folder, leading to a Local Privilege Escalation to SYSTEM. The attacker must replace SilverShield.config.sqlite with a version containing an additional user account, and then use SSH and port forwarding to reach a 127.0.0.1 service.