
A DNS hijacking wave is targeting companies at an almost unprecedented scale - Elof
https://arstechnica.com/information-technology/2019/01/a-dns-hijacking-wave-is-targeting-companies-at-an-almost-unprecedented-scale/
======
ams6110
The "clever trick" seems to be:

 _previously compromised the login credentials for the administration panel of
the target’s DNS provider_

or

 _previously compromised domain registrar or ccTLD_

Unless I'm missing something, given either of those things, doesn't take much
cleverness...

~~~
ploxiln
It's some kind of alarmism over letsencrypt ... "letsencrypt will give tricky
attackers a valid certificate for a domain!!!" (if they get control over the
domain) (... certs have almost always been granted based on control of the
domain, though historically it mostly MX records ... so attackers could do
pretty much the same thing 15 years ago)

~~~
cronix
I believe this is why letsencrypt certs are only valid for 3 months.
Personally, I'd like it monthly.

~~~
Crosseye_Jack
I was under the impression that it was more to get admins to automate the
issuance and have it auto renew than manually issue and forget and let the
cert expire.

If I have control of a dns or register control panel I can use any of the
other free ssl certs out there for an attack.

Comodo Will give you a valid cert for 90 days as a trial, others will give you
30 days. AWS cert manager (ok iirc I can only use those within AWS but the
point still stands. And if I’m being naughty it’s not gonna be hard to acquire
a few stolen CC to bill my AWS usage too) will give you a year. All for free.
WooSign / StarCom used to issue free 1 year certs (I think wooSign might still
do but they are issued by another CA).

~~~
dcbadacd
This also fixes certificates lasting too long after domains change hands,
allows faster deployment of certs with fixes and other new tech. There are
many benefits to short expiry.

------
LeonM
That's why I placed this Ask HN a while ago:

[https://news.ycombinator.com/item?id=17704828](https://news.ycombinator.com/item?id=17704828)

I pitched that idea at startup school, and got accepted. However, after a
while I pivoted to something else, as I decided that the name registry and DNS
market is just too crowded. I was afraid that we'd be spending 99% of the time
and budget on convincing people they need secure domain/DNS management,
instead of building the technology.

~~~
btrettel
Security could be an advantage for a variety of online services. When
selecting an online service, I'm starting to use U2F 2FA support as a way to
narrow the list of services to consider, so making a decision is easier. Few
domain name registrars offer U2F from what I can tell.

------
tptacek
Note that these attacks involve _compromised accounts with authority servers_
, so despite being the most visible and impactful DNS attacks of the last few
years, DNSSEC would have done little to defend against them; in fact, even in
the DNSSEC fantasy-world where DANE replaces X.509 CAs, these attackers would
still have accomplished their goals.

~~~
fosco
after reading the headline I immediately thought of "14 DNS Nerds Don't
Control the Internet" [0].

[0] [https://sockpuppet.org/blog/2016/10/27/14-dns-nerds-dont-
con...](https://sockpuppet.org/blog/2016/10/27/14-dns-nerds-dont-control-the-
internet/)

~~~
wav-part
Much better than (CA0 || CA1 || ... ). All it takes is one CA out of 10s of
independent CAs to misbehave to insecure whole tls.

In DNSSEC/DANE, world only has to watch one entity rather than 10s of
entities.

~~~
tptacek
No. You have to trust _all the CAs_ , _and_ the governments that control the
DNS.

[https://www.imperialviolet.org/2015/01/17/notdane.html](https://www.imperialviolet.org/2015/01/17/notdane.html)

~~~
wav-part
> No. You have to trust all the CAs, and the governments that control the DNS.

Not in DNSSEC. .xxx need only trust dnsroot. yyy.xxx need only trust .yyy and
dnsroot.

firefox/chrome/etc with support from important orgs with high value names
(google.com/bankofamerica.com/etc) would then make sure that dnsroot/.com/etc
do not abuse the trust. They have incentive and methods of punishment. There
is no legal authority that clients need to map DNS . to existing root keys. A
client can map a.b.c to any key it wants.

The risk of gov overreach is same for both tls and DNSSEC. DNSSEC just trusts
fewer entities. The only people who benefit from current system, are CAs who
are getting $$$ for nothing.

>
> [https://www.imperialviolet.org/2015/01/17/notdane.html](https://www.imperialviolet.org/2015/01/17/notdane.html)

This is orthogonal. Weak Keys are not required or implied characterstic of
DNSSEC.

~~~
akerl_
If browsers start mapping cert trust to something besides the DNS roots...
it’s not DNSSEC, it’s something else entirely, it’s “our current system, maybe
with some slight tweaks”

~~~
wav-part
I am not suggesting every client do their own mapping, that is not a naming
system at all. There has to be very large consenus for a naming system to be
effective. I just pointed that out to show that dns is not under any gov
control. Its under a control of an entity that can be punished.

However who gets to have dnsroot is just a value of a config in DNSSEC. The
value itself should not be used to criticize DNSSEC cause its changeable.

~~~
akerl_
How do you punish .com if they misbehave? Move every site off .com?

~~~
wav-part
No. You just map .com to another key with an agreement that new .com owner pre
signs and map existing .com subs _the right way_. An unaware xxx.com does not
need to do anything. As long as its done publically with a bang and enough
consensus, disruption should be minimal.

Again this is unavoidable in any system that need trust. Thats why I like PoW
DNS.

~~~
tptacek
Who is "you"? The people we're afraid of manipulating .COM control the DNS.
Google can't "map .com to another key". Their option would be to _leave .COM_
; that is the gun DNSSEC would give to the USG to hold against Google's head.

~~~
wav-part
You is firefox/chrome/etc. Yes you can. The ownership of .com is not as
exclusive/protected as .xxx or xxx.com. Thus the firefox/chrome/etc can map it
to anyone they feel. Considering so many high value .com subnames, .com can be
transferred to neutral party or even dnsroot. USG do not own ".com" string. No
one does. Just like ".".

~~~
tptacek
Your claim here is that a browser vendor could somehow fork the DNS and use
its own .COM? Explain how that could possibly work.

~~~
wav-part
Anyone can fork DNS. Its just a (name, key) map. As long as its done with
__enough consensus __, it can be done. Mismanagement of .com is serious enough
to demand that kind of change.

Lets say .com gets mismanaged. Community is infurious. firefox/chrome/etc
demands that . remap .com to new more trustable entity. If . does not.
firefox/chrome/etc then remap . to new more trustable entity, because .com
must be as trustable as ., because .com is that important. New . give back
ownership of all tlds to their previous owners. Except for .com. .com goes to
the more trustable entity as intended. New .com then does again similar import
of all good xxx.com.

In this whole incident, no one loses the ownership of their names except for
.com and possibly . .

Now no gov can touch *.com. Though its different for cctld. Those are owned by
their respective govs. Same goes for gtld. But no one gets to mess with . .com
.org .net.

~~~
akerl_
It sounds like what you’re proposing is for browser vendors to, in unison,
overthrow IANA and the related organizations and stage a coup where they start
running their own DNS root authority. And then claiming that this would happen
without impact to end users / owners-of-individual-domains.

~~~
wav-part
Browser vendors (specifically all DNS users) have the option. They can do it,
if IANA fails at the job of being a dnsroot. Disruption is inversely
proportional to consensus. If everyone do it, there is no disruption. Some
disruption is unavoidable. Its fair price to pay for stable and solid global
naming system.

Ultimately its about deciding who gets to own "x.y.z" string brand
globally/contextlessly. World obviously need a single naming system. Either
that or expect to have multiple owners to "google.com".

My suggestions are required otherwise why would someone build a global brand
if ownership is not safe or guarnteed enough. Future is way more chaotic.
Without crypto, a global naming system is not going to survive.

~~~
tptacek
OK. I don't think we have to debate this any more. We can just leave it here:
you think DNSSEC is a workable solution to our problems as long as the
browsers can, if they ever need to, create their own alternate DNS for the
web.

------
cobbzilla
"almost unprecedented" implies that there was an earlier wave of DNS hijacking
that was even larger (thus setting some kind of precedent). Was there such a
precedent? And if so, I didn't see mention of it in the article.

------
throwaway5752
Source link: [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)

~~~
westurner
> _The National Cybersecurity and Communications Integration Center issued a
> statement [1] that encouraged administrators to read the FireEye report._
> [2]

[1] [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)

[2] [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)

------
abbadadda
Via the article: "(FireEye) advised administrators to take a variety of
measures, including:

* ensure they’re using multifactor authentication to protect the domain’s administration panel

* check that their A and NS records are valid

* search transparency logs for unauthorized TLS certificates covering their domains and

*conduct internal investigations to assess if networks have been compromised"

------
mobilemidget
"One DNS hijacking technique involves changing what’s known as the DNS A
record."

Could be any record, depends on the intentions of the hijacker. Typically we
see web traffic being hijacked to another ipv4 host which indeed, is an A
record. Another abuse option could be to alter SPF/DKIM to do a more
sophisticated phishing campaign.

~~~
aidos
And because there are so many SPF records including SPF records including...
you can be pretty undetectable.

------
bonyt
What ever happened to HPKP? It seems like that would somewhat mitigate these
attacks since they rely on using their control over the domain to get a new DV
cert. A pinned certificate would at least protect those who have accessed the
sites before.

~~~
mh-
Deprecated/killed.

[https://www.chromestatus.com/feature/5903385005916160](https://www.chromestatus.com/feature/5903385005916160)

~~~
moosingin3space
If you're confused as to why, this article was illuminating:
[https://scotthelme.co.uk/using-security-features-to-do-
bad-t...](https://scotthelme.co.uk/using-security-features-to-do-bad-things/)

~~~
tptacek
HPKP was underdesigned; it was a protocol evolution of something Google was
already doing semi-manually. There was a competing initiative inside Google
--- certificate transparency --- and that won out.

There's validity in the approach and I hope it comes back sometime, maybe with
additional mechanism around managing pins.

------
hedora
If an attacker can spoof your DNS records (or if they can simply man in the
middle the connection between your server and the internet), then they can
generate valid Let’s Encrypt certificates.

If I had the time or inclination, I’d write a transparent https gateway that
used let’s encrypt to man-in-the-middle http and https connections to servers
behind it.

You could imagine deploying something like that on the edge of AWS for mass
surveillance purposes, or maybe a misguided white-hat could use it to “secure”
http-only services (it’s an improvement in a defeatist sort of way...)

~~~
wcdolphin
For the MTM scenario, how would you convince letsencrypt’s CA to issue you a
cert for any domain? Don’t you need to complete the challenge in order for the
CA to issue you a cert?

~~~
topranks
You’d have to somehow redirect / spoof DNS responses to Let’s Encrypt to fool
them and make it look like you passed the challenge.

Not trivial, but far from impossible for as long as the world maintains that
securing the DNS is pointless.

------
Animats
This is the problem with quickie SSL cert issuance from "Let's Encrypt". If it
took 10 days of consistent domain resolution to get an SSL cert, this wouldn't
be happening.

~~~
topranks
The attack is based on compromising control of the victim’s domain.

What’s to stop someone in control of a domain putting records up for 10 days?
It’d still happen, just be a delay between compromising the domain and getting
the cert is all.

~~~
Animats
Presumably the owner of the domain would notice if their site was diverted for
ten days.

------
josefresco
This is clever in that they evaded detection. But I've seen and been the
victim of much more sophisticated DNS hijacks that didn't require any
credentials.

------
PaulHoule
Could this be a big setback for "Let's Encrypt" since it uses DNS resolution
for its own authentication instead of being a second factor?

~~~
JoshTriplett
All domain-validated certificates use factors you can control if you control
the domain, whether email or web or DNS. This has nothing to do with Let's
Encrypt.

~~~
PaulHoule
Yeah, but it is a problem with domain-validated certificates in general that
kinda defeats the purpose of SSL.

It seems most of the time that a web site is "hacked" (defaced) somebody
changed the DNS instead of attacking the actual web server.

SSL signing can potentially be a second line of defense, but only if having
control of the DNS (thus web and email) is insufficient to get a cert.

~~~
icedchai
What are the alternatives?

About 20 years ago, I remember having to go through tons of hoops to get a
certificate. Faxing corporate docs and other bureaucracy. That can all be
forged.

~~~
dylz
\- TXT record: pointless if your DNS is hacked

\- CNAME record: pointless if your DNS is hacked

\- Put a file or add a meta-tag to HTML at a specific path: pointless if your
DNS is hacked, they can just add/change A/AAAA record and host their own
webserver

\- Email to webmaster@.. etc: pointless if your DNS is hacked, add MX record

