
Why CISA Issued Our First Emergency Directive - ca98am79
https://cyber.dhs.gov/blog/#why-cisa-issued-our-first-emergency-directive
======
blunte
Considering the top two cybersecurity roles in the US government have been
vacant since mid 2018, it's fortunate that there are still some people focused
on area.

~~~
vxNsr
My understanding is Trump is having so much trouble getting confirmations
through congress, he's basically stopped trying except for essentials and the
gov has never taken tech related stuff as essential.

~~~
gumby
He’s had few difficulties. Executive positions simply aren’t being filled, for
some reason. He’s proposed many judges. AFAIK every name proposed for any
position has been approved by the senate.

~~~
speeder
I am not from US, but decided to google quickly about this... and you are
wrong, and the guy that is downvoted seemly is right:

[https://thehill.com/homenews/senate/423965-senate-throws-
hun...](https://thehill.com/homenews/senate/423965-senate-throws-hundreds-of-
trump-nominees-into-limbo)

~~~
gumby
Hmm, interesting. The high profile ones seem to go through without any more
than a ceremonial objection so those less prominent ones are surprising.

Thanks for checking this!

------
tptacek
Fun detail: their first-ever "emergency directive", owing to a rash of DNS
hijacking attacks, and not one mention of DNSSEC, despite the fact that the US
Government requires agencies to use it. And they do! Pull a list of random
.GOV or .MIL domains and check if they have DNSSEC --- most will! And it did
fuck-all to stop this attack.

~~~
magila
This attack vector is not something DNSSEC was ever intended to defend
against, so why would it be mentioned? Once the registrar account associated
with a domain is pwned the attacker can do pretty much anything they want with
it, including obtain fraudulent certificates.

~~~
anoncontractor
As someone who has recently dealt with a major government agency, the
requirement of DNSSEC means that agencies can’t use Route53 as it doesn’t
support DNSSEC. This makes it much less likely that an agency will use
something like Terraform for managing DNS, which would help in making sure all
records are validated and easily auditable. Instead, many DNS records are
managed by hand or with bespoke systems. The best case is that it’s managed by
maybe Akamai, but records are still updated via support tickets and
implemented by hand (as akamai’s Terraform support is pretty bad).

So it’s relevent to mention DNSSEC because it’s spoken of within the
government as a method of securing DNS, but in reality it makes things worse.
It doesn’t protect against attacks like these and the end result is you are
forced to use a crappy system that makes you even more vulnerable to these
sorts of attacks. It’s the worst of all worlds.

(Also, I was on the call they held for CIOs and tech leaders of all agencies,
and it was astonishing how many of the questions in their chat made it obvious
that many of the entrenched players didn’t even understand how this attack
worked.)

~~~
belorn
The article/directive specifically called out DNS account passwords on DNS
hosting providers. If they were using support tickets and manually implemented
changes by hand then there would not be an account. With no account for a
control panel you don't have any risk that the email and password gets dumped
on pastebin. In the directive it even speaks about password managers, which
again implies that the issue they are talking about are DNS control panels
like the one at Route53, likely with reused password, and not bespoke systems.

For high priority domain names I would go so far and recommend against having
a DNS control panel accounts on things like Route53. It has access control
management but unless the department has the experience and skills it will
likely end up with a single account that has full access with little oversight
when something goes wrong. Those departments are likely better served going
through a domain management company that handles all the security and manage
who can request changes and how. If they have the experience and skills then
managing it fully themselves can be a better option, but then what they really
need is a registrar which allows for DNSSEC keys to be forwarded (with for
example a cds record).

~~~
anoncontractor
“If they were using support tickets and manually implemented changes by hand
then there would not be an account.”

Your contracting team may not have a DNS account, but the contractor that
deals with DNS changes certainly does.

The point is that all infrastructure really should be managed with code. If
you managed DNS from Terraform you’d notice that your production DNS system
was in conflict from what your code said it should be the next time a
terraform plan/apply was run (which is happening all the time from dev or
maybe CI). Without it you could go months or years without noticing a changed
entry on a little used, but critical system. From what I remember this attack
was ongoing for a couple years before it was noticed.

~~~
belorn
If they are using contractors that have DNS accounts with email and password
as authentication, and who reuse that on other online websites which later get
leaked, then that is major a failure in procurement when the bid was initially
created.

> The point is that all infrastructure really should be managed with code

That I agree 100% with. If the agency itself has a IT department with
experience and knowledge then the most optimal choice is that they do it
themselves with either something like Terraform or their own physical hardware
with authoritative DNS running on it. Agencies that is involved with either
critical infrastructure, personal information, or state secrets should always
have a security risk analyze done which describe what would happen if someone
broke into DNS and where the vulnerabilities are. Sadly very few agencies does
this.

Other agencies are likely better served by updating their procurement in
respect to DNS management and make sure the requirements lists liability and
high security. Make sure that rather than some cheap bulk registrar with a do-
it-yourself control panel, where the registrar always have zero livability if
the credentials are leaked, it is better to pay a more costly management
company that manage the infrastructure with code.

------
ccnafr
tl, dr: Because Iranian hackers were hijacking DNS records for government
sites.

~~~
ciupicri
Where is Iran mentioned?

~~~
eganist
It's buried in links, but the FireEye research referenced by US CERT discusses
it.

[https://www.us-cert.gov/ncas/current-
activity/2019/01/10/DNS...](https://www.us-cert.gov/ncas/current-
activity/2019/01/10/DNS-Infrastructure-Hijacking-Campaign)

And

[https://www.fireeye.com/blog/threat-
research/2019/01/global-...](https://www.fireeye.com/blog/threat-
research/2019/01/global-dns-hijacking-campaign-dns-record-manipulation-at-
scale.html)

\---

Link chain that I followed:

1) op — [https://cyber.dhs.gov/blog/#why-cisa-issued-our-first-
emerge...](https://cyber.dhs.gov/blog/#why-cisa-issued-our-first-emergency-
directive)

2) first link in op, "emergency directive" —
[https://cyber.dhs.gov/ed/19-01](https://cyber.dhs.gov/ed/19-01)

3) footnote #1 in the emergency directive — [https://www.us-
cert.gov/ncas/current-activity/2019/01/10/DNS...](https://www.us-
cert.gov/ncas/current-activity/2019/01/10/DNS-Infrastructure-Hijacking-
Campaign)

4) FireEye research referenced on the US CERT page —
[https://www.fireeye.com/blog/threat-
research/2019/01/global-...](https://www.fireeye.com/blog/threat-
research/2019/01/global-dns-hijacking-campaign-dns-record-manipulation-at-
scale.html)

------
AlphaWeaver
>We know an active attacker is targeting government organizations.

>Using techniques that aren’t especially innovative, we know they can
intercept and manipulate legitimate traffic, make services unavailable or
cause delay, harvest information like credentials or emails, or cause a range
of other malicious activities.

>We know that this type of attack isn’t something many organizations monitor
for or have tight controls around.

Interesting that they've specifically identified a case of this ongoing in a
coordinated manner. Makes sense why it'd be an "emergency directive" in this
case.

------
Operyl
Seems reasonable enough, steps that should have already been taken (and may
have been already for certain sectors of the government). Pretty level headed
“directive,” I definitely welcome it.

------
w8rbt
Nine out of ten times, it's bad passwords.

~~~
Operyl
Or shared credentials, etc.

~~~
Iwan-Zotow
or Putin

------
jessaustin
There isn't enough detail here. Which agencies gave an unknown (still unknown
even now!) actor or actors access to all information that the public passed to
them over the internet? What harms has the public suffered as a result?

~~~
616c
This impacted work for people I know and we have all asked around informally
and no one has info in the beltway so those in the know seem to be tight
lipped about it.

That said I was unaware of the Talos publication last week so I will read that
but I assume this same surface level fluff.

~~~
jessaustin
Thanks for that. I'm now _more_ worried not less. b^)

------
westurner
There are a number of efforts to secure DNS (and SSL/TLS which generally
depends upon DNS; and upon which DNS-over-HTTPS depends) and the _identity
proof_ systems which are used for record-change authentication and
authorization.

Domain registrars can and SHOULD implement multi-factor authentication.
[https://en.wikipedia.org/wiki/Multi-
factor_authentication](https://en.wikipedia.org/wiki/Multi-
factor_authentication)

Are there domain registrars that support FIDO/U2F or the new W3C WebAuthn
spec?
[https://en.wikipedia.org/wiki/WebAuthn](https://en.wikipedia.org/wiki/WebAuthn)

Credentials and blockchains (and biometrics):
[https://gist.github.com/westurner/4345987bb29fca700f52163c33...](https://gist.github.com/westurner/4345987bb29fca700f52163c339a270f)

DNSSEC:
[https://en.wikipedia.org/wiki/Domain_Name_System_Security_Ex...](https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions)

ACME / LetsEncrypt certs expire after 3 months (*) and require various proofs
of domain ownership:
[https://en.wikipedia.org/wiki/Automated_Certificate_Manageme...](https://en.wikipedia.org/wiki/Automated_Certificate_Management_Environment)

Certificate Transparency:
[https://en.wikipedia.org/wiki/Certificate_Transparency](https://en.wikipedia.org/wiki/Certificate_Transparency)

Certs on the Blockchain: "Can we merge Certificate Transparency with
blockchain?"
[https://news.ycombinator.com/item?id=18961724](https://news.ycombinator.com/item?id=18961724)

Namecoin (decentralized blockchain DNS):
[https://en.wikipedia.org/wiki/Namecoin](https://en.wikipedia.org/wiki/Namecoin)

DNSCrypt:
[https://en.wikipedia.org/wiki/DNSCrypt](https://en.wikipedia.org/wiki/DNSCrypt)

DNS over HTTPS:
[https://en.wikipedia.org/wiki/DNS_over_HTTPS](https://en.wikipedia.org/wiki/DNS_over_HTTPS)

DNS over TLS:
[https://en.wikipedia.org/wiki/DNS_over_TLS](https://en.wikipedia.org/wiki/DNS_over_TLS)

DNS:
[https://en.wikipedia.org/wiki/Domain_Name_System](https://en.wikipedia.org/wiki/Domain_Name_System)

------
ehnto
I am probably just cynical but the title reads like a medium tech blogger is
about to tell me why he started using React in the cloud.

