Subject: [dane] domain hijacking

From: Wei Chuang <[email-masked]>
Date: Wed, 12 Apr 2017 11:50:36 -0700

Hi dane folks,

There recently was an article in Wired about how a banking site was domain
hijacked:
https://www.wired.com/2017/04/hackers-hijacked-banks-entire-online-operation/
via a DNS registry account hijacking.  I was wondering if DNSSEC can
protect against such hijackings (and thereby protect DANE records).  My
suspicion is no, DNSSEC can't protect against an attack at the registry
level since a hijacker could publish a new set of consistent records for
the zone including at the parent.  If my suspicion is correct, has there
been thought of re-signing the DS record signed with the older private key
in a way that proves ownership through the key change?  This gets published
at the parent so its visible even if the entire zone gets spoofed.  This,
put another way, would prove publicly continuity of ownership for the
domain.

thanks,
-Wei

---

From: Alice Wonder <[email-masked]>
Date: Wed, 12 Apr 2017 12:38:32 -0700

On 04/12/2017 11:50 AM, Wei Chuang wrote:
> Hi dane folks,
>
> There recently was an article in Wired about how a banking site was
> domain hijacked:
> been thought of re-signing the DS record signed with the older private
> key in a way that proves ownership through the key change?  This gets
> published at the parent so its visible even if the entire zone gets
> spoofed.  This, put another way, would prove publicly continuity of
> ownership for the domain.
>
> thanks,
> -Wei

I had thought of this sort of scenario as well.

You can script to watch your DS records and alert you if they ever are 
not suppose to be, but I hope there is a future where certificate 
authorities are replaced by trust anchors independent of the root DNS 
that can behave as a DS record 2FA.

e.g. to create new KSK that DNSSEC would validate, the attacker would 
not only have to fool the registry into uploading new DS records but 
also fool the secondary trust anchor that duplicates the DS records.

Unfortunately that also opens up DoS attack if an attacker is not able 
to change the actual DS records but is able to fool the secondary 
validator of the DS records.

That's DNSSEC issue though, not DANE.

Even if banks use DANE (and I wish they would) they also should have EV 
certificates to currently defend against that type thing.

---

From: "Ken O'Driscoll" <[email-masked]>
Date: Wed, 12 Apr 2017 20:52:44 +0100

On Wed, 2017-04-12 at 11:50 -0700, Wei Chuang wrote:
> protect against such hijackings (and thereby protect DANE records).
[...snip...]

Hi Wei,

My first post to this list!

My understanding of that incident is that the attackers compromised the .br registry and from there reassigned the nameservers, thus redirecting traffic to their rogue server.

DANE or indeed DNSSEC isn't intended to prevent that type of attack, where the attacker has complete control of the domain name at a registry level, including the ability to change NS records and delete DS records. Essentially, in such cases the attacker follows the same procedure the legitimate registrant would follow to disable DNSSEC while changing nameservers.

There are other technologies and strategies available to mitigate the risk of such attacks, but if the registry is compromised then DNSSEC etc. can just be disabled so any scheme involving re-signing DS records can be overcome.

Ken.
-- 
Ken O'Driscoll / We Monitor Email
t: +353 1 254 9400 | w: www.wemonitoremail.com

---

From: Frederico A C Neves <[email-masked]>
Date: Wed, 12 Apr 2017 17:06:49 -0300

Ken,

> My understanding of that incident is that the attackers compromised the .br registry and from there reassigned the nameservers, thus redirecting traffic to their rogue server.

No, please read the article and the corrections we've provided. The
domain contact account had their listed email account compromised, a
free email provider. With email access and no 2FA configured for this
account on our system the attacker did a password reset. With access
to the system did a regular delegation change.

> DANE or indeed DNSSEC isn't intended to prevent that type of attack, where the attacker has complete control of the domain name at a registry level, including the ability to change NS records and d…

Correct. If they had a DS the redelegation, done correctly, would be
only a little bit harder but totally doable.

Fred

---

From: "Ken O'Driscoll" <[email-masked]>
Date: Wed, 12 Apr 2017 21:25:27 +0100

> to the system did a regular delegation change.

Apologies Frederico, didn't realise that the story had been updated.

Ken.

---

From: "John Levine" <[email-masked]>
Date: 13 Apr 2017 03:11:24 -0000

> If my suspicion is correct, has there
>in a way that proves ownership through the key change?

This sounds to me like shutting the barn door after the horse is gone.

If it's important to you that your domain isn't hijacked, we all know
what to do, pick a registrar with good security and 2FA and so forth,
and monitor your own DNS with alarms if there are unauthorized changes.

Also, if we were to invent some sort of change signing, now you have
the other problem where the guy with the private key quits and takes
it with him, and you have to rebootstrap the zone somehow.

R's,
John

---

From: Alice Wonder <[email-masked]>
Date: Wed, 12 Apr 2017 22:02:17 -0700

> it with him, and you have to rebootstrap the zone somehow.

I wonder if the future DANE equivalent of EV type validation is DS 
records at a well known location at the root of the domain (e.g. 
/ds.signed) signed by a trusted third party that clients can use to 
validate what is in their TLD.

The only commercial CA issued certificates I personally have any 
confidence in as an end user are EV and that would give even more 
confidence.

Use DANE to secure to public x.509 and when more confidence than DANE is 
needed, expensive commercial CA to secure the DS records. Cheap 
commercial CA wouldn't be needed because DANE already provides far more 
than domain validation certs can, only DS record certs that involve 
human validation would make sense, for things like banking or commerce 
or major social network.

To work with more than HTTPS third party DS records could be sent with a 
future version of TLS or some kind of blockchain technology.

---

From: Alice Wonder <[email-masked]>
Date: Wed, 12 Apr 2017 22:04:28 -0700

> future version of TLS or some kind of blockchain technology.

Meant to type "third party *signed* DS records"

---

From: Alice Wonder <[email-masked]>
Date: Wed, 12 Apr 2017 23:04:20 -0700

On 04/12/2017 10:04 PM, Alice Wonder wrote:
*snip*
> Meant to type "third party *signed* DS records"

Okay this is how I would do it. I'm new to list and kind of a nobody but...

DANE is used to secure the long-term private key as an alternate to 
commercial DV certificates.

For OV and EV level of confidence - a company can get an x.509 
certificate using their zone as the CN and extensions specifying the DS 
records that is signed by a trusted third party commercial CA.

This x.509 is only used as verification that the DNSSEC validated DS 
records are genuine and to give the consumer confidence the zone has 
been validated using OV or EV standards. It does not replace DS records 
secured by DNSSEC, only adds a second validation in addition to DNSSEC. 
Only OV and EV make sense for this type of x.509.

To compromise a zone protected by this second x.509 a bad actor would 
need to both obtain a fraudulently signed x.509 from a trusted authority 
*and* get fraudulent DS records into the zone's parent zone.

I'm not an expert on TLS but I think this would even work with existing 
TLS, just send this x.509 along with the DANE protected x.509 as part of 
the TLS handshake.

Would that work and solve the problem?

---

From: "Ken O'Driscoll" <[email-masked]>
Date: Thu, 13 Apr 2017 13:27:21 +0100

> *and* get fraudulent DS records into the zone's parent zone.

Or, an attacker could (as in the case we're discussing) just gain access to
the domain registry and re-assign NS records, disabling any DNSSEC type
security in the process. Resolvers have no expectation to be dealing with
DNSSEC signed zones so removing the protection would not be challenged.

Any mechanism that relies on anything that the registrant controls which
they (or an imposter with their credentials) can disable does not address
this risk.

As John already pointed out, organisations can mitigate against these
attacks by choosing registries (and registrars) who offer robust
authentication options along with employing monitoring solutions.

I'm not seeing how any type of protocol can do away with normal operational
level security.

Ken.

---

From: Alice Wonder <[email-masked]>
Date: Thu, 13 Apr 2017 05:38:48 -0700

> I'm not seeing how any type of protocol can do away with normal operational

What I am suggesting is that a CSR be produced from the KSK.

That CSR gets signed by a third party - either OV or EV (no point in DV)

The resulting x.509 cert is sent as part of the TLS handshake.

If it doesn't match the DS record in zone's parent the client refuses.

If it matches the DS record in zone's parent then the client shows the 
pretty OV or EV information in the URL bar.

That won't stop someone who takes over a zone but it will prevent them 
from doing so with the extra EV validation users like me always look for 
when going to our bank or twitter or whatever.

So if Chase has their zone hijacked in the registry, the attacker could 
make a DNSSEC validating phishing site, but it wouldn't have the other 
visual indications of EV because the attacker wouldn't be able to send a 
signed X.509 from the KSK that matches the fraudulent DS records they 
created.

Wouldn't stop MITM from being attempted but it would give at least some 
users a visual indication that things are not what they are suppose to be.

---

From: Hugo Salgado-Hernández <[email-masked]>
Date: Thu, 13 Apr 2017 10:15:29 -0300

> it with him, and you have to rebootstrap the zone somehow.

Agree.

But anyway, we have two indicators of something is wrong, from
DNSSEC perspective. Even the hijacker deletes the DS and the zone
goes insecure, or change it for a new one and the zone goes bogus
for some hours, just like a bad made rollover.

Maybe the bank could indicate somehow that it's zone should never
go insecure/bogus, just like a website owner can signal with HSTS
that it'll never go plain.

Hugo

---

From: Wei Chuang <[email-masked]>
Date: Thu, 13 Apr 2017 07:06:49 -0700

Even with a good registrar there might be some reason for this.  Consider
that 2FA might not  be a permanent solution to zone admin account
hijacking.  For example, RSA 2FA products which are very popular, were
reportedly bypassed back in 2012
<https://arstechnica.com/security/2012/05/rsa-securid-software-token-cloning-attack/>.
Further such a solution might better detect/prevent spoofing by a
adversarial parent zone or registrar.  Agreed that monitoring is a good
idea.  One issue it that it may be difficult for you/your script to be
always vigilant.  Perhaps by making a domain hijacking more visible to
everyone, and having a whistleblowing (i.e. reporting mechanism such as
used in Coniks) protocol then you could distribute the problem of
monitoring.

> it with him, and you have to rebootstrap the zone somehow.

Agreed this is pertinent issue and I don't have a fully baked scheme to
work out this scenario.  But perhaps a solution might involve checking the
cached but stale result to see if that historic state is consistent with a
newly published state up to 1 TTL period.  Errors condition would then
existing for a finite time (1 TTL).

-Wei

---

From: "John R Levine" <[email-masked]>
Date: 13 Apr 2017 12:38:03 -0400

> Perhaps by making a domain hijacking more visible to everyone, and 
> having a whistleblowing (i.e. reporting mechanism such as used in 
> Coniks) protocol then you could distribute the problem of monitoring.

That's just what I *don't* want to do.  I do not want to be volunteered to 
be an unpaid security officer for everyone else's DNS.

It's fine to think about ways that a domain can secure its DNS and detect 
and fix unauthorized change, but I don't think it's fair to expect the 
rest of the world to do it for you.

R's,
John