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

121–130 of 291 posts

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

#121

Post by web007 »

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.

I thought HPKP was essentially deprecated - too many footgun scenarios and not enough specificity on "what to pin" since CAs can use / issue with multiple intermediates.

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

#122

Post by ascorbic »

caymanjim wrote: post #109
triplenineteen wrote: post #97

Earlier quoted context omitted.

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

In Chrome, it's a real pain in the ass, and it's buried deeply. It's not available at all in the settings UI (not even in advanced settings).

You can type "badidea" at the warning page to skip it.

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

#123

Post by deft »

tribune wrote: post #114

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?

Yes, multiple people on reddit have said that's exactly what they did.

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

#124

Post by tptacek »

AndyMcConachie wrote: post #115
tptacek wrote: post #108

Earlier quoted context omitted.

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…

In a BGP hijacking attack against a DNSSEC-signed zone, the attacker just looks at which IP address is in the signed A record, and then injects that prefix.

Note that "the auth servers hosting myetherwallet.com" aren't some random IP addresses in Tallinn, Estonia. It's Route53!

I get what you're saying with your counterfactual, that DNSSEC "breaks the exploit", requiring the attackers to use a slightly different exploit. But who cares? The slightly different exploit has the same predicates.

That's what's so funny about the narrative that DNSSEC has some role to play in today's attack. It would almost make sense if the narrative was "we could use DANE to get rid of all CAs and then it wouldn't matter if you could trick a DV validator". But, no, people are talking about how DNSSEC would help LetsEncrypt, in the event of a global BGP hijacking. Admit it! That's funny.

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

#125

Post by KirinDave »

pdimitar wrote: post #46
omarforgotpwd wrote: post #43

Wow. Just wow. These BGP vulnerabilities are ridculous. Imagine, someone taking over DNS for even a small subset of people and being able to basically just rewrite the internet as they see fit, completely taking control of anything. Even without being able to get a valid SSL certificate you could do a lot of damage. For example, let's say I rewrote requests for SomeNationalBank.com to my proxy server. I make a reques…

Check out IPFS' DNS alternative -- IPNS. No blockchain needed, it's pretty solid.

I did. It's not very useful or performant, unfortunately.

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

#126

Post by hkdobrev »

caymanjim wrote: post #109
triplenineteen wrote: post #97

Earlier quoted context omitted.

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

In Chrome, it's a real pain in the ass, and it's buried deeply. It's not available at all in the settings UI (not even in advanced settings).

In Chrome, clearing the cache, clears the saved HSTS records which are not preloaded in the browser.

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

#127

Post by web007 »

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…

> Slightly related: much to my annoyance, it seems that neither AWS ELB nor ALB support sending HSTS, which is a real bummer.

I didn't know that either one lets you set any kind of header - I've always set a passthrough on the upstream, so it's guaranteed no matter what the LB or routing framework is used.

    curl -sI -H 'Host: myhost.mydomain.com' https://long-alb-descriptor.us-west-2.elb.amazonaws.com/ | grep Strict
    Strict-Transport-Security: max-age=15552000; includeSubDomains; preload

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

#128

Post by ZeroCool2u »

caymanjim wrote: post #109
triplenineteen wrote: post #97

Earlier quoted context omitted.

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

In Chrome, it's a real pain in the ass, and it's buried deeply. It's not available at all in the settings UI (not even in advanced settings).

Had no idea about that 'badidea' work around in chrome. Just tried it and it actually worked.

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

#129

Post by Moter8 »

ascorbic wrote: post #122
caymanjim wrote: post #109

Earlier quoted context omitted.

In Chrome, it's a real pain in the ass, and it's buried deeply. It's not available at all in the settings UI (not even in advanced settings).

You can type "badidea" at the warning page to skip it.

Doesn't work for me (anymore) in Chrome 65. Used to work.

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

#130

Post by LinuxBender »

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…

If I control the network, I can strip off any security that might be in DNS. I can change or remove CAA records, DNSSEC, etc. Those things currently fail open, which exception to DNS replication which will take "refresh" time to fail. I can then get new certs for the DNS I now control. HSTS just means use HTTPS. It doesn't validate the previous cert. That is HPKP which almost nobody uses unless they control the client, such as mobile apps.
Post reply on HN