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

91–100 of 291 posts

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

#91

Post by Cshelton »

DividableMiddle wrote: post #55
bklyn11201 wrote: post #51

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.

wait, myetherwallet doesn't use HSTS? I thought they had a vulnerability analysis done a few months ago. I feel like this should have been something that was caught.

Wow, that's scary. I even told someone recently, jokingly of course, they forgot to add HSTS for their mvp app.

But MEW doesn't have HSTS? I would never use it personally on a public Wifi, but many people will for sure and they have no idea they'd be MITM'd.

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

#92

Post by blibble »

Kalium wrote: post #64
bklyn11201 wrote: post #38

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 th…

> * Pick a preferred SSL issuer and stick with them. Add a CAA DNS record only allowing that one issuer. It may be worth also suggesting HPKP here. That would be effective for many customers. > * DNSSEC? Make sure to choose an SSL issuer that will correctly test DNSSEC? This basically means you can't use Route53, which is a deal-breaker for a lot of people running services.

GCP supports DNSSEC, I moved all my domains away from Amazon due to this

was very easy to setup on GCP too

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

#93

Post by breakingcups »

isostatic wrote: post #59
rgbrenner wrote: post #2

A website I own was affected by this. I got an alert from our monitoring saying the website was down for 1hr 2min 59sec. Luckily, they didn't redirect it to anything. I have other domains using Route53 (and hosted at AWS, just like this one).. that weren't affected AFAICT.

> I got an alert from our monitoring saying the website was down for 1hr 2min 59sec. That's a very accurate time. What system do you use to allow sampling at under 1 second intervals? My nagios boxes poll every minute, so an outage could be 2 seconds, or nearly 2 minutes, and nagios would report the downtime as 1 minute.

Could be a process that checks every minute with slightly inaccurate measuring which leads to 1h3m minus 1 second reported.

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

#94

Post by tetha »

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…

Yep, this is nasty to defend against.

Most of our internal infrastructure handling GDPR-data would be fine with this incident, since we encoded mutual validation and trust into a lot of systems. Clients need to authenticate to be authorized, obviously, but clients also authenticate the server against company-internal secrets. This is done using a bunch of secret, self-signed CA-Chains or managed ssh/known_hosts files.

But that kind of system is quite impossible to implement without control over the server and the client-side. And if the client has to get the information from somewhere, you have a tradeoff - flexibility vs security. You can either change the source of trust in a client quickly, as an attacker, or you can provide a secure connection which can be changed with 6 years of planning as a service provider.

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

#96

Post by manigandham »

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 generate as many certificates as you want for a given name. There is no master list of all the live certificates out there and there are no checks for existing certificates when generating new ones (otherwise we'd never be able to renew certs until the old ones expire, resulting in downtime).

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

#97

Post by triplenineteen »

an_account_name wrote: post #72
EE84M3i wrote: 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 does indeed prevent users from clicking through the warning - it makes handshake / trust chain failure fatal with no "proceed anyway" button.

Sorta. In most browsers you can manually delete the HSTS property on a per-domain basis. Presumably, anyone doing this knows the risks.

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

#100

Post by Manozco »

philjohn wrote: post #33
Diederich wrote: post #25

Earlier quoted context omitted.

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.

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