Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

doublepulsar.com

Post reply on HN
Print view View original

31–40 of 291 posts

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

#31

Post by kolpa »

reaperducer wrote: post #3

How do we know it was unnoticed? It could very well have been noticed and taken two hours for Amazon to mitigate it. I don't know the technical process behind making such a correction, but in any large organization there are steps that have to be followed. It's not like some kid typing out a shell command on his basement Linux box. Inflammatory/clickbait headlines do not make the internet a better place.

If no one mentioned this important outage, it's likely that many/most/all people didn't notice.

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

#32

Post by vertex-four »

0xbadcafebee wrote: post #14

This same attack can be used to generate valid TLS certs for any website, for example using Let's Encrypt. The best part? Your target doesn't need to use Let's Encrypt at all. Anyone can use them to forge certs for any domain . Of course, this is possible with most other cert providers, but Let's Encrypt automates it. So.... TLS certs mean jack squat if you can pull off a BGP+DNS attack. You might want to start pinni…

The solution to this is the CAA issue record combined with DNSSEC. DNSSEC ensures that an attacker can't spoof your DNS even if they have your DNS traffic directed to them globally, and then CAA ensures that only the issuers you want can create certificates for your domain. This is a solved problem, it just requires caring about it.

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

#33

Post by philjohn »

Diederich wrote: post #25
djsumdog wrote: post #7

So they obviously couldn't or didn't hijack certs, so they were depending on people who clicked through or APIs/systems that didn't do cert checks?

Update: see other comment chains invalidating the security I'm claiming HSTS provides. APIs will probably go directly to https:// , and hopefully cert failures will cause the API to blow up with minimal harm. If you want to visit my web site, and you need to type it in, you'll probably just put realms.org into the URL bar of your browser. Most secure websites, such as paypal.com, have something called HSTS https://en…

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

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

#34

Post by AlphaWeaver »

solotronics wrote: post #21

was this related to the myetherwallet.com hack? they hijacked BGP and DNS to redirect traffic to their own page https://altcoinreport.co/my-ether-wallet-hacked/

Yes, the article says the only compromised site they are aware of was MyEtherWallet.

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

#35

Post by lifeisstillgood »

Can I check my understanding

(Somehow) A BGP route was advertised and accepted for the IP range for amazons route53 - so that some / many DNS requests hit a fake server instead of the real amazon one. The only dns requests that changed seem to be for a bitcoin site, and they were redirected to a site that seems to have then grabbed their passwords and then emptied their wallets on the real site.

?

Mitigation strategies that come to mind

- certificate pinning (where I have my browser only accept certificates that I have approved, not just are signed by a CA (this has not really taken off)

- Certificate warning - surely browsers should shout of a certificate that was valid for domain X changes today? (suffers similar problems to pinning)

- BGP route acceptance. We are out of my comfort area now, but this is surely where the real solution lies - why did people accept a BGP chnage to redirect route53 to russia? Can routes be advertised with signing ?

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

#36

Post by zerocrates »

24gttghh wrote: post #27
0xbadcafebee wrote: post #14

This same attack can be used to generate valid TLS certs for any website, for example using Let's Encrypt. The best part? Your target doesn't need to use Let's Encrypt at all. Anyone can use them to forge certs for any domain . Of course, this is possible with most other cert providers, but Let's Encrypt automates it. So.... TLS certs mean jack squat if you can pull off a BGP+DNS attack. You might want to start pinni…

Excuse my ignorance but how does this allow someone to forge TLS certs for a given website/domain name that already has active certs? Wouldn't they have to revoke existing certs and then get new ones during the attack to pull this off?

You don't need to revoke existing certificates to generate/forge new ones.

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

#37

Post by libeclipse »

24gttghh wrote: post #27
0xbadcafebee wrote: post #14

This same attack can be used to generate valid TLS certs for any website, for example using Let's Encrypt. The best part? Your target doesn't need to use Let's Encrypt at all. Anyone can use them to forge certs for any domain . Of course, this is possible with most other cert providers, but Let's Encrypt automates it. So.... TLS certs mean jack squat if you can pull off a BGP+DNS attack. You might want to start pinni…

Excuse my ignorance but how does this allow someone to forge TLS certs for a given website/domain name that already has active certs? Wouldn't they have to revoke existing certs and then get new ones during the attack to pull this off?

You can have multiple certificates for a single host.

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

#38

Post by bklyn11201 »

Getting a basic certificate issued is incredibly easy these days. If you own the DNS resolution, you can get a cert.

Here a few ways I can think of to make this harder for an attacker:

* Add a Strict-Transport-Security to all HTTPS requests. This means the attacker will need to get a valid cert (still easy if you can hijack BGP).

* Pick a preferred SSL issuer and stick with them. Add a CAA DNS record only allowing that one issuer.

* Go through the EV SSL process with your preferred issuer. Now modify your CAA DNS record to add an EV policy. This should make it very difficult for an attacker to get a cert issued during a BGP hijack.

* DNSSEC? Make sure to choose an SSL issuer that will correctly test DNSSEC?

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

#39

Post by peterwwillis »

vertex-four wrote: post #32
0xbadcafebee wrote: post #14

This same attack can be used to generate valid TLS certs for any website, for example using Let's Encrypt. The best part? Your target doesn't need to use Let's Encrypt at all. Anyone can use them to forge certs for any domain . Of course, this is possible with most other cert providers, but Let's Encrypt automates it. So.... TLS certs mean jack squat if you can pull off a BGP+DNS attack. You might want to start pinni…

The solution to this is the CAA issue record combined with DNSSEC. DNSSEC ensures that an attacker can't spoof your DNS even if they have your DNS traffic directed to them globally, and then CAA ensures that only the issuers you want can create certificates for your domain. This is a solved problem, it just requires caring about it.

CAA depends on CAs (all 650 of them) to respect it, and for all of them to implement everything perfectly (it was shown in 2017 that they don't). This also depends on DNS again, which again not everyone will do properly, so CAA requests from CAs can be hijacked. So CAA is stupid.

The client should be getting the list of authorized CAs for the domain from DNS on first connection, and/or from inside the first cert, with expiry dates. It should require that if there is a new CA, that its authorization be signed by a previous CA or cert. The client needs to verify the entire chain of authorized changes throughout history, rather than just believe any cert from any CA at any time. And there should probably be a certificate transparency pooled service which the client checks the first time they see a new chain or new root of a chain (or something, i'm making this up as I go). In the current case the domain owner may eventually figure out something's up, but the client may not, and changing BGP/revoking certs/etc are ineffective when the attack is already in play.

This is the only time you will ever see me say this, but we kind of need Blockchain here.

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

#40

Post by evgen »

24gttghh wrote: post #27
0xbadcafebee wrote: post #14

This same attack can be used to generate valid TLS certs for any website, for example using Let's Encrypt. The best part? Your target doesn't need to use Let's Encrypt at all. Anyone can use them to forge certs for any domain . Of course, this is possible with most other cert providers, but Let's Encrypt automates it. So.... TLS certs mean jack squat if you can pull off a BGP+DNS attack. You might want to start pinni…

Excuse my ignorance but how does this allow someone to forge TLS certs for a given website/domain name that already has active certs? Wouldn't they have to revoke existing certs and then get new ones during the attack to pull this off?

The new, fake cert just has to validate for your phish/drove-by/cred-jacking site that is mimicing a real site. You are not planning a long-term take-over but just to make sure the new site passes checks by your victims.
Post reply on HN