Live data from Hacker News

Hijack of Amazon’s domain service used to reroute web traffic for two hours

doublepulsar.com

111–120 of 291 posts

Re: Hijack of Amazon’s domain service used to reroute web traffic for two hours

#111
post #105

Surely related (and warning!): During this period I received an email from: ship-confirm@amazon.com purporting to notify me of the despatch of a non-existent order; with an attached .zip. Nothing about the message, except the .zip and suggestion of an order's existence, was at all suspicious - all links point to amazon.com. I checked on amazon.com (without following a link) and on amazon.co.uk (where I would usually…

That's just regular spam. I bet if you checked you would see the email was not actually sent by Amazon, and did not have a DKIM signature.

Re: Hijack of Amazon’s domain service used to reroute web traffic for two hours

#112
post #45

Earlier quoted context omitted.

Forgive my ignorance but I have a few questions: * Why would HSTS help in this case? While HSTS is active, does it prevent clicking through the warning (which was done here)? * How would a CAA record help against cert issuance in this case? Is it only helping against compromise of the authoritative during the remaining TTL of the record in recursives AND if the CAA record points to something that doesn't have on-dema…

HSTS wouldn't help users clicking through warnings, but it's a good thing to have (myetherwallet doesn't use HSTS). CAA record would only help in remaining TTL. Once expired, then it doesn't matter. So yeah, these seem like decent steps to help protect but certainly not going to 100% prevent an attack like this one.

>HSTS wouldn't help users clicking through warning

Actually it would have! Chrome and possible other browsers do not allow clicking throw certificate validation issues on sites with HSTS. For example, try to get to https://badssl.finn.io in Chrome.

Re: Hijack of Amazon’s domain service used to reroute web traffic for two hours

#115
post #57

Earlier quoted context omitted.

DNSSEC adoption would prevent a hijacker from manipulating responses.

No, it wouldn't. It comically wouldn't: in a BGP hijacking attack, the attackers control IP. It doesn't matter what your signed DNS record points to; attackers will just make that address theirs.

I think in this instance DNSSEC would have prevented the entire attack. If I understand the sequence of events correctly, the route hijack was done to the auth DNS servers hosting myetherwallet.com. Then these rogue DNS servers redirected users to a fake myetherwallet.com.

If myetherwallet.com had been DNSSEC signed then users who validated the signature chain would have not been redirected to the fake site. But it's not DNSSEC signed.

Re: Hijack of Amazon’s domain service used to reroute web traffic for two hours

#116
post #112

Earlier quoted context omitted.

HSTS wouldn't help users clicking through warnings, but it's a good thing to have (myetherwallet doesn't use HSTS). CAA record would only help in remaining TTL. Once expired, then it doesn't matter. So yeah, these seem like decent steps to help protect but certainly not going to 100% prevent an attack like this one.

>HSTS wouldn't help users clicking through warning Actually it would have! Chrome and possible other browsers do not allow clicking throw certificate validation issues on sites with HSTS. For example, try to get to https://badssl.finn.io in Chrome.

Sorry how does that help if the attackers purchase a new "valid" SSL certificate since they control the DNS and thus email?

Re: Hijack of Amazon’s domain service used to reroute web traffic for two hours

#117

Earlier quoted context omitted.

A CAA DNS record won't help much if the attacker can just go to the certificate issuer and request a valid SSL certificate because they own DNS. Plus can't they just change the CAA DNS record?

If you are using DNSSEC, hopefully the issuers are validating it.

I'm not able to find any information on Let's Encrypt and DNSSEC validation. Anyone know if they validate it?

Re: Hijack of Amazon’s domain service used to reroute web traffic for two hours

#118

How did they manage to steal coins if they didn't get a valid cert? Did people logging into MyEtherWallet just ignore the invalid cert warnings and log in anyway?

Could be, could also be API clients not doing cert validations

Re: Hijack of Amazon’s domain service used to reroute web traffic for two hours

#119

Earlier quoted context omitted.

Except, it would have been trivial for them to get Lets Encrypt to issue them a valid cert.

it depends, let's encrypt might be performing request from different sources (and then it would need a bigger BGP hijack to fake them)

If LetsEncrypt is actually hosted within AWS, then a network request from them to Route53 might not even hit the public internet.

Re: Hijack of Amazon’s domain service used to reroute web traffic for two hours

#120

Earlier quoted context omitted.

How similar was this to the BGP attack by Russia in late 2017? https://arstechnica.com/information-technology/2017/12/suspi...

>by Russia Sounds like xenophobic bullshit.

More correct to say "Russian Government"
Post reply on HN