RE: A Deep Dive on the Recent Widespread DNS Hijacking

Mailman List Mirror (Read Only)
1

You might have missed reading the very article you cite.

"Woodcock said PCH’s reliance on DNSSEC almost completely blocked that attack, but that it managed to snare email credentials for two employees who were traveling at the time.
....
Aside from that, DNSSEC saved us from being really, thoroughly owned.”

Or maybe ACME .. https://tools.ietf.org/html/draft-ietf-acme-acme-12#section-11.2

"It is therefore RECOMMENDED that ACME-based CAs make all DNS queries via DNSSEC-validating stub or recursive resolvers. This provides additional protection to domains which choose to make use of DNSSEC.”

I am not sure how many of the domains listed as being hijacked are DNSSEC signed, but it seems if they were, and had a reasonable long TTL on a DS record at their parent, many if not most of these could have been prevented/detected.

ICANN seems to think that is the case: ICANN Calls for Full DNSSEC Deployment
https://www.icann.org/news/announcement-2019-02-22-en

Of course, DNSSEC is often blamed for not protecting those who did not deploy/use it. Not sure what can be said about that line of reasoning.

Dougm

2

Obviously none of y'all read the report. Here is the relevant quote:

""""
DNSSEC protects applications from using forged or manipulated DNS data, by requiring that all DNS queries for a given domain or set of domains be digitally signed. In DNSSEC, if a name server determines that the address record for a given domain has not been modified in transit, it resolves the domain and lets the user visit the site. If, however, that record has been modified in some way or doesn’t match the domain requested, the name server blocks the user from reaching the fraudulent address.

While DNSSEC can be an effective tool for mitigating attacks such as those launched by DNSpionage, only about 20 percent of the world’s major networks and Web sites have enabled it, according to measurements gathered by APNIC, the regional Internet address registry for the Asia-Pacific region.

Jogbäck said Netnod’s infrastructure suffered three separate attacks from the DNSpionage attackers. The first two occurred in a two-week window between Dec. 14, 2018 and Jan. 2, 2019, and targeted company servers that were not protected by DNSSEC.

However, he said the third attack between Dec. 29 and Jan. 2 targeted Netnod infrastructure that was protected by DNSSEC and serving its own internal email network. Yet, because the attackers already had access to its registrar’s systems, they were able to briefly disable that safeguard — or at least long enough to obtain SSL certificates for two of Netnod’s email servers.

Jogbäck told KrebsOnSecurity that once the attackers had those certificates, they re-enabled DNSSEC for the company’s targeted servers while apparently preparing to launch the second stage of the attack — diverting traffic flowing through its mail servers to machines the attackers controlled. But Jogbäck said that for whatever reason, the attackers neglected to use their unauthorized access to its registrar to disable DNSSEC before later attempting to siphon Internet traffic.

“Luckily for us, they forgot to remove that when they launched their man-in-the-middle attack,” he said. “If they had been more skilled they would have removed DNSSEC on the domain, which they could have done.”
"""

If you manage to get access to the change the dns delegation at the parent you can also turn DNSSEC off. Clearly the scripties managed to do this once but "forgot" to do it the second time around ... That they also "forgot" to disable DNSSEC on PCH is not particularly relevant. It only goes to prove my point that DNSSEC is irrelevant and only gives a false sense of security (for this particular attack vector). I suppose you could have really long timeouts on your DS records, but that would merely "complicate" matters for the scripties and would not be protective ...

3

Keith,

You are right, if you can compromise a registrar that permits DNSSEC to be disabled (without notification/confirmation to POCs etc), then you only have a limited period (max of DS TTL) of protection for those resolvers that have already cached the DS.

If that makes DNSSEC irrelevant in this specific scenario is in the eye of the beholder I guess. I agree in that specific scenario it is not preventative.

In the 3rd attack noted below, do we know if the CA that issued the DV CERTS does DNSSEC validation on its DNS challenge queries?

Hopefully folks who deploy DNSSEC signed zones test validation on their domains on a regular basis, and I would hope that a CA issuing DV CERTS would do DNSSEC validation on signed zones in their DNS challenges.

Given that this is only one vector for attacks of a similar style, it seems like locking down the underlying infrastructure is still a good idea.

The paper below mentioned in a NANOG talk last week gives food for thought.

Bamboozling Certificate Authorities with BGP
https://www.usenix.org/conference/usenixsecurity18/presentation/birge-lee

dougm

4

I just checked

Bing.com
Google.com
Amazon.com
Facebook.com
Netflix.com
Twitter.com
Chase.com
Coinbase.com

None of them have dnssec signed domains.

They are smart. They make money on the web. And they have, likely consciously, made a cost / benefit risk driven evaluation of dnssec that it is not worth using. More specifically, their inaction implies dnssec is more risk than benefit, which i agree with.

Those FANG companies have the resources to lead the way, but if they are balkiing … it’s a tall order to ask the rest of us (we have to buy our own lunch crowd) to jump in the pool.

But, icann is rationally raising the “never waste a good outage” to advance your tired agenda.

CB

5

In article <B7DF0851-C5A3-4366-8ADF-501D1418F9E1@nist.gov> you write:

You are right, if you can compromise a registrar that permits DNSSEC to be disabled (without notification/confirmation to POCs
etc), then you only have a limited period (max of DS TTL) of protection for those resolvers that have already cached the DS.

As far as I can tell, that's roughly all of them. If you have the
credentials to log in and change the NS, you can change or remove the
DS, too.

As someone else noted, the only reason DNSSEC made any difference was
that the script kiddies sometimes forgot to turn it off or install
their own DS. If you are actually interested in preventing this
stuff, 2FA will be orders of magnitude more effective than messing
with DNSSEC.

There are certainly threats that DNSSEC addresses, but getting your
registrar account pwned isn't one of them.

R's,
John

6

And, that wouldn’t change in the nearest future, because the concept of “hostile pinning” as it was present with HTTPS Public Key Pinning could also be ported to DNSSEC this way.

“Hostile signing”… doesn’t that sound scary.

7

Google has been validating on 8.8.8.8 for years now though they only properly enabled EDNS for Google.com on Jan 10, 2019. Prior to that you needed to include a EDNS ECS option to get a EDNS response. They also DNSSEC sign some of their zones. https://developers.google.com/speed/public-dns/faq

8

We know that neither Comodo nor Let's Encrypt were DNSSEC validating before issuing certs. The Let’s Encrypt guys at least seemed interested in learning from their mistake. Can’t say as much of Comodo.

                                -Bill

9

For those watching from the sidelines, This guy is perfectly encapsulating one of the arguments that seem to pop up in the wake of attacks: “What actually happened is irrelevant, because I can imagine other things that could hypothetically have happened, but didn’t, which would have reinforced my view of the world.”

I can’t say that I understand the psychology behind people thinking this way, but as we’re choosing to be transparent about our experience for the benefit of others, I thought I’d highlight this particular quirk, as Mr. Medcalf is far from alone (not about DNSSEC specifically, but apparently attacks bring people with all manner of chips on their shoulders out of the woodwork). It’s a particularly self-defeating logical fallacy, so being aware of it is the first step to recognizing it and avoiding it.

                                -Bill

10

Bill,

Did you have a CAA record defined and if not, why not?

-Hank

11

I would also note that a organisation can deploy RFC 5011 for their own zones and have their own equipment use DNSKEYs managed using RFC 5011 for their own zones. This isolates the organisation’s equipment from the parent zone’s management practices.

I would also note that you can configure validating resolvers to expect secure responses for parts of the namespace and to reject insecure responses even when they validate as insecure.

An organisation can also deploy DLV for their own zones using their own registry. While the current code DLV validating code is only invoked when the response validates as insecure, there is nothing preventing a policy which says that DLV trumps or must also validate for entries in a registry. At this stage is would be a minor code change to add such policy knobs. DLV is a just a in-band way of distributing trust anchors.

Mark

12

I would also note that a organisation can deploy RFC 5011 for their own
zones and have their own equipment use DNSKEYs managed
using RFC 5011 for their own zones. This isolates the organisation’s
equipment from the parent zone’s management practices.

I would also note that you can configure validating resolvers to expect
secure responses for parts of the namespace and to reject
insecure responses even when they validate as insecure.

One thing that immediately struck me upon reading the Krebs post was
that people got owned by having to downgrade the end-to-end model of
the Internet into Proxy-land. A hotel wifi. Probably only challenged by
"Free Wifi" in other spaces in its ability to demolish the Internet as
thought out and envisioned.

We can conclude in two different directions here;

* We need to work on making the Internet more transparent to applications,
  and thus increasing security.

* We're all doomed anyway. DNSSEC is useless.

Pick whichever you like. Our children will judge us.

13

If the attacker got a CA to issue the cert because they changed the DNS server to be their own, a CAA record wouldn’t have helped (or at least been even easier to thwart than DNSSEC).

Ask

14

Yes (as Mark knows) I would like to be able to use DLV in this enterprisey
way. It should also help validators to continue working for local domains
when external connectivity is funted.

Tony.

15

Did you have a CAA record defined and if not, why not?

If the attacker got a CA to issue the cert because they changed the DNS server to be their own, a CAA record wouldn’t have helped (or at least been even easier to thwart than DNSSEC).

Yes if an attacker pwned the DNS then game over no matter what. I go under the assumption that the attacker was not able to take over the DNS system but rather other things along the way, in which case CAA should be of some assistance.

-Hank

16

You are right, if you can compromise a registrar that permits
DNSSEC to be disabled (without notification/confirmation to POCs
etc), then you only have a limited period (max of DS TTL) of
protection for those resolvers that have already cached the DS.

As far as I can tell, that's roughly all of them. If you have
the credentials to log in and change the NS, you can change or
remove the DS, too.

Yes, though with the 1 day TTL most registries put on DS records, you at
least have the chance to notice your DS has changed or been deleted and
attempt to recover your registry account.

That is somewhat a "locking the barn door" approach, and 2FA and other
account security is the best solution. However, we are in a world now
where every layer of security we can add is probably a good idea and
having a day to notice could be handy.

DNSSEC isn't useless but it solves one specific problem, end to end
data integrity. It also requires operational cleanliness and attention
to detail. We shouldn't make claims about what it can't do; we're much
better off getting everyone to understand what it does and doesn't
do. And underline what other security best practices they should be
following.

If someone owns your registry account, you're screwed. And right now, it
tends to be the most neglected part of the entire zone ownership
world. Let's use this opportunity to help folks lock down their
accounts, not muddying the waters with dubious claims.

17

If someone owns your registry account, you're screwed. And
right now, it tends to be the most neglected part of the
entire zone ownership world. Let's use this opportunity to
help folks lock down their accounts, not muddying the waters
with dubious claims.

Reread this and felt I should clarify that I realize that John and Doug
are not the ones saying DNSSEC is useless. I just hate to see the knee
jerk "oh, see, DNSSEC didn't save the day so it's obviously
useless". Let's give the world a better explanation.

18

Hi Paul,

Reread this and felt I should clarify that I realize that John and Doug
are not the ones saying DNSSEC is useless. I just hate to see the knee
jerk "oh, see, DNSSEC didn't save the day so it's obviously
useless". Let's give the world a better explanation.

Security is only as strong as its weakest link. No single link can be expected to protect the whole chain on its own.

Cheers,
Sander

19

@Paul — I think you meant “registrar account” rather than “registry account”
since most domain holders don’t have registry accounts. Registry accounts are
primarily held by registrars. If someone owns a registrar’s registry account, then
all of their customers (and potentially many many others) are screwed.

Owen

20

One thing to consider with authentication for domain registrar accounts:

DO NOT USE 2FA VIA SMS.

This is a known attack vector that’s been used by SS7 hijacking techniques for several well documented thefts of cryptocurrency, from people who were known to be holding large amounts of (bitcoin, ethereum, whatever) on exchanges which supported 2FA authentication.

In some cases there was no SS7 hijacking going on, but rather social engineering of (t-mobile, sprint, verizon, at&t) customer service representatives to get a new SIM card issued for the attack target’s phone.

tl;dr: ss7 considered harmful