Regional BGP hijack of Amazon DNS infrastructure

[Matthew Hardeman‏]

This story is still breaking, but early indications are that:

1. An attacker at AS10297 (or a customer thereof) announced several more
specific subsets of some Amazon DNS infrastructure prefixes:

205.251.192-.195.0/24 205.251.197.0/24 205.251.199.0/24

2. It appears that AS10297 via peering arrangement with Google got
Google's infrastructure to buy (accept) the hijacked advertisements.

3. It has been suggested that at least one of the any cast 8.8.8.8
resolvers performed resolutions of some zones via the hijacked targets.

It seems prudent for CAs to look into this deeper and scrutinize any domain
validations reliant in DNS from any of those ranges this morning.

[Wayne Thayer‏]

Thanks Matthew, I appreciate you bringing this to everyone's attention.

Unless I'm misunderstanding the scope of the attack, it would have been
trivial for them to get a trusted cert from most any CA. However, according
to the following article, "Victims had to click through a HTTPS error
message, as the fake MyEtherWallet.com was using an untrusted TLS/SSL
certificate.", yet the attackers still managed to steal millions of dollars
in alt-coins.

https://www.theregister.co.uk/2018/04/24/myetherwallet_dns_hijack/

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Matthew Hardeman‏]

On Tue, Apr 24, 2018 at 7:11 PM, Wayne Thayer <wth...@mozilla.com> wrote:

> Thanks Matthew, I appreciate you bringing this to everyone's attention.
>
> Unless I'm misunderstanding the scope of the attack, it would have been
> trivial for them to get a trusted cert from most any CA. However, according
> to the following article, "Victims had to click through a HTTPS error
> message, as the fake MyEtherWallet.com was using an untrusted TLS/SSL
> certificate.", yet the attackers still managed to steal millions of dollars
> in alt-coins.
>

This is mostly in line with what happened. It is presently believed only
approximately $150K in value of Ethereum was stolen in this event. The
thieves hold an account which has amassed over $17 million in value.

It likely would have been trivial for them to get a certificate from many
CAs during the attack period. I'm curious as to whether they tried or
succeeded and then didn't use it. Or if they tried and failed because a CA
was smart or well positioned.

Of relevance for this community, as you point out, the fake site which
users were referred to did not present a valid TLS certificate at all. It
was a self-signed. Despite that, users clicked through and got taken for
$150k. That, in itself, is a problem for the community. Broadly, I
understand this is one that HSTS seeks to resolve.

Given the sophistication of the attack and how long the attackers held the
space, it does surprise me that they didn't achieve a certificate for their
target... Or did they? That's among the questions I would like to raise.

Perhaps this is a bit of spy-novel flight of fancy, but perhaps there are
plausible attack scenarios to be explored here:

We are days away from virtually ubiquitous CT logging of new certificate
issuances. Some CAs are not yet logging their certificates unless
customers have requested it. I think some start tomorrow, most will likely
start by the end of the week.

What if there were non-obvious goals of the attackers? What if
myetherwallet.com was only a convenient distraction from an as-yet unknown
real target? This is perhaps the more significant security question.

It's possible that the goal was to secure a certificate for another entity
just in time to avoid this quiet issuance from getting CT logged. It's
plausible that this would have been requested from a commercial CA with a
longer validity period, to be held and used in a future attack. The only
way we can know is if CAs are willing to go back to their validation logs
and explore the question.

Any validations which relied upon DNS query responses from authoritative
DNS servers inside 205.251.192.0/24, 205.251.193.0/24, 205.251.195.0/24,
205.251.197.0/24, or 205.251.199.0/24 between approximately 11:05 UTC
through 13:03 UTC on April 24, 2018, were potentially improperly
manipulated.

Depending on what view of the internet a given CA's validation
infrastructure has, a given CAs infrastructure may or may not have been
referencing the wrong DNS servers during that period.

Questions that I'd love to see answered:

Did anyone get a validation request for myetherwallet.com during the attack
period? If so, what was the final status of that validation request? If
denied, on what basis was it denied? If validated, did a certificate issue?

Did anyone receive validation requests during the attack period for any
domain for which the validation infrastructure, in turn, relied upon
answers from the above mentioned IP space? If so, did any of those
validations succeed? If so, did any certificates issue upon that reliance?

[Ryan Hurst‏]

This is an example of why ALL CA's should either already be doing multi-perspective domain control validation or be working towards that in the very near future.

These types of attacks are far from new, we had discussions about them back in the early 2000s while at Microsoft and I know we were not the only ones. One of the earlier papers I recall discussing this topic was from the late 08 timeframe from CMU - https://www.cs.cmu.edu/~dga/papers/perspectives-usenix2008/

The most recent work on this I am aware of is the Princeton paper from last year: http://www.cs.princeton.edu/~jrex/papers/bamboozle18.pdf

As the approved validation mechanisms are cleaned up and hopefully reduced to a limited few with known security properties the natural next step is to require those that utilize these methods to also use multiple perspective validations to mitigate this class of risk.

Ryan Hurst (personal)

[Santhan Raj‏]

What is interesting to me is the DV certificate that Amazon had issued for myetherwallet.com (https://crt.sh/?id=108721338) and this certificate expired on Apr 23rd 2018.

Could it be that the attackers were using this cert all along in place of a EV cert?

[Matthew Hardeman‏]

I seriously doubt that.

MyEtherWallet.com is/was hosted on Amazon CloudFront, and I believe the
private keys for those certs stay locked at Amazon. That was likely the
starter cert that MyEtherWallet.com first went with before securing an EV
cert.

On Wed, Apr 25, 2018 at 11:42 AM, Santhan Raj via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On Wednesday, April 25, 2018 at 1:57:28 AM UTC-7, Ryan Hurst wrote:

> What is interesting to me is the DV certificate that Amazon had issued for
> myetherwallet.com (https://crt.sh/?id=108721338) and this certificate
> expired on Apr 23rd 2018.
>
> Could it be that the attackers were using this cert all along in place of
> a EV cert?

[Matthew Hardeman‏]

Also, during the period of the attack, they were using a self-signed
certificate.

As yet there's no public evidence that they achieved issuance of any
certificate. There is some question as to whether they could have.

On Wed, Apr 25, 2018 at 12:32 PM, Matthew Hardeman <mhar...@gmail.com>
wrote:

> I seriously doubt that.
>
> MyEtherWallet.com is/was hosted on Amazon CloudFront, and I believe the
> private keys for those certs stay locked at Amazon. That was likely the
> starter cert that MyEtherWallet.com first went with before securing an EV
> cert.
>
> On Wed, Apr 25, 2018 at 11:42 AM, Santhan Raj via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
>> On Wednesday, April 25, 2018 at 1:57:28 AM UTC-7, Ryan Hurst wrote:

[Nick Lamb‏]

On Wed, 25 Apr 2018 09:42:43 -0700 (PDT)

Santhan Raj via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:

> What is interesting to me is the DV certificate that Amazon had
> issued for myetherwallet.com (https://crt.sh/?id=108721338) and this
> certificate expired on Apr 23rd 2018.
>
> Could it be that the attackers were using this cert all along in
> place of a EV cert? _______________________________________________

I have not been able to view this link for some reason. However I can
say that I've seen screenshots alleged to be of the Cert Viewer on a
Windows PC connected to the attacker site, and it's hilariously bogus,
it's a self-signed certificate with CA:TRUE set, and the site's name as
Common Name, it looks like if somebody with no previous exposure to the
Web PKI tried to make a certificate based on some random blog post or
old Youtube tutorial. e.g.

https://twitter.com/GossiTheDog/status/988785871188045825

There's no way this was ever valid, anywhere. If it's what was actually
used (and I have no reason to believe it wasn't) the attackers relied
upon the Dancing Pig effect to get their job done.

Maybe we're actually lucky they didn't get a newer tutorial that taught
them to use ACME.

[Santhan Raj‏]

I agree and am obviously speculating at this point.

I did see the (ridiculously silly) self-signed certificate that was used, but the skeptic in me keeps questioning the timeline of this attack and recent multiple cert issuances,
- a self-signed cert created on 2018-03-23 and observed by Censys on 2018-03-29 (https://censys.io/certificates/4f151e2efd755fb1b9a4d50fa6db2af0008dff02ffbef8178be54f9db6e86d75) I assume this is the cert used in the attack from the screenshots
- the self-signed cert was created exactly a year after the Amazon certificate was issued
- the self-signed cert was used in an attack the day when/after the Amazon DV cert expired (April 23rd 2018)
- additionally, and this may have nothing to do with the attack, 3 distinct EV certs issued to myetherwallet.com by Digicert and Comodo on 2018-03-30 and 2018-03-31, even though the existing EV cert (issued by Digicert) was still valid
- https://crt.sh/?id=370369641
- https://crt.sh/?id=371216075
- https://crt.sh/?id=378737050

Again, I'm obviously speculating and all this could be coincidence and business as usual, but if I were writing this crime novel, the plot wouldn't be "1-2 days of attack to steal $150K" but "a year of silent attack to steal $17M and get caught due to an expired cert". Why would anyone with $17M want to go through all this trouble to steal just another $150K?

[Matthew Hardeman‏]

On Wed, Apr 25, 2018 at 1:44 PM, Santhan Raj via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

>
> I did see the (ridiculously silly) self-signed certificate that was used,
> but the skeptic in me keeps questioning the timeline of this attack and
> recent multiple cert issuances,
> - a self-signed cert created on 2018-03-23 and observed by Censys on
> 2018-03-29 (https://censys.io/certificates/4f151e2efd755fb1b9a4d50fa6db2a
> f0008dff02ffbef8178be54f9db6e86d75) I assume this is the cert used in the
> attack from the screenshots
>

That is what I have understood to be the case.

> - the self-signed cert was created exactly a year after the Amazon
> certificate was issued
> - the self-signed cert was used in an attack the day when/after the Amazon
> DV cert expired (April 23rd 2018)
>

My belief is that that was coincidence, if the date of the attack is
significant, it was at or closely before days in which more CAs would begin
CT logging of all their certificate issuances.

- additionally, and this may have nothing to do with the attack, 3 distinct
> EV certs issued to myetherwallet.com by Digicert and Comodo on 2018-03-30
> and 2018-03-31, even though the existing EV cert (issued by Digicert) was
> still valid
> - https://crt.sh/?id=370369641
> - https://crt.sh/?id=371216075
> - https://crt.sh/?id=378737050

These three are not weird. They were all obviously acquired in near time
to each other and there is a rational explanation.

If EV certificate is important to you and if you're a professional in these
matters, it is not unlikely that you would purchase redundant certificates
from two different CAs with entirely different trust hierarchies. This
ensures that you already have in-hand a new TLS certificate in case either
CA has a loss of trust issue, etc. The two from Digicert reflect two
different key lengths. They requested both a 2048-bit version of the
certificate as well as a 4096 bit version of the certificate.

As EV certificates can take some time to acquire, it is not uncommon for a
professional to have multiple simultaneous certificate instances in-hand so
that another certificate is already on hand to replace the one that has a
problem. (Key compromise of operating certificate, CA distrust, revocation
by CA for reasons, etc.)

>
>
> Again, I'm obviously speculating and all this could be coincidence and
> business as usual, but if I were writing this crime novel, the plot
> wouldn't be "1-2 days of attack to steal $150K" but "a year of silent
> attack to steal $17M and get caught due to an expired cert". Why would
> anyone with $17M want to go through all this trouble to steal just another
> $150K?
>

There's the question everyone wants answers to. The attacker demonstrated
some sophistication. No one has suggested any significant part of that
Ethereum came from any prior compromise of MyEtherWallet.com. I myself
wonder if the attack on myetherwallet.com was a "bonus" or side-job,
designed to be the publicly acknowledged reason for the attack and to stop
people digging further. The question which remains is what else might the
attackers have done -- and who was or will be impacted -- during the two
hour window they opened.

It is on that basis I am especially interested to know what DNS validation
attempts were attempted across the various CAs during that time period
which relied upon responses to queries sent to any destination within the
set of impacted prefixes.