Hijack of Amazon’s domain service used to reroute web traffic for two hours • Hacker News Board

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

#201

Post by tialaramex » Tue, Apr 24, 2018, 11:29 PM UTC

tptacek wrote: post #124

AndyMcConachie wrote: post #115

Earlier quoted context omitted.

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

DNSSEC plus CAA today would let you tell Let's Encrypt "No thanks, automation is too dangerous for my high-value names". If the hijacker fakes the answer, DNSSEC fails, Let's Encrypt says "DNSSEC failed, no issuance". If the hijacker allows the real answer, Let's Encrypt says "CAA says forbidden, no issuance".

I posted in response to pfg's comment above a mechanism that high value targets could choose, which is modelled on how Facebook behave today but (since we're proving a point here) more extreme. Make a deal with a CA, forbid all other CAs from issuing.

The other thing about Let's Encrypt is that they wouldn't be a good target for such an attacker because they are seeing the world from more than one place. You specify particularly a global BGP hijack, but those are hard, which is why this wasn't global. Tricking just, say, the original San Francisco office of Let's Encrypt doesn't get the job done.

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

#202

Post by ryao » Tue, Apr 24, 2018, 11:29 PM UTC

tialaramex wrote: post #195

pfg wrote: post #181

Earlier quoted context omitted.

One could argue that in a perfect world the combination of DNSSEC and CAA should stop attacks of this nature. However, this only holds up under a rather limited set of circumstances: 1. The targeted domain would need to make use of both DNSSEC and CAA in the first place. I doubt that's true for more than a tenth of one percent of all domains out there. 2. The attackers would have to only target DNS resolution, and no…

If you have DNSSEC with CAA, you can use that to choose a CA which has a contractual relationship with you. That contract can say anything you both like, for example it can say: "All issuances under example.com shall first be approved by telephone call to our security office on 1-234-567-8900, and the certificate issued shall have a notBefore timestamp no earlier than 24 hours after an SCT included in the certificate…

If the DNS servers providing that message are hijacked due to BGP, the hijacker can simply not serve that notice and the registrar doing the lookup would never see it.

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

#203

Post by ryao » Tue, Apr 24, 2018, 11:34 PM UTC

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.

Use cloudflare. Unlike Amazon, their DNS is free and it is supposed to be among the fastest.

Then again, DNSSEC is useless against a BGP hijack where the nameservers for the domain are replaced with malicious ones.

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

#204

Post by tomc1985 » Tue, Apr 24, 2018, 11:38 PM UTC

dcbadacd wrote: post #193

tomc1985 wrote: post #146

Earlier quoted context omitted.

Too many people have foot-gunned themselves with that one. As someone who has to readily fight technical fires for other people (when they should have googled their problems) I am glad to see HPKP go.

Honestly there are a lot of ways for people to foot-gun themselves when dealing with providing a service. HPKP isn't perfect, but deprecating it just for the sake of keeping some incompetent people safe is just silly. Might as well remove HSTS and not roll out Expect-CT because everything allows someone to foot-gun themselves.

That sounds nice and all but you don't have to support it

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

#205

Post by viraptor » Tue, Apr 24, 2018, 11:38 PM UTC

textmode wrote: post #186

viraptor wrote: post #173

Earlier quoted context omitted.

Depends on how the website is hosted. If it's a tiny website on a single server/VPS, then it's going to be fairly stable with the IP. For anything else, you're out of luck. Shared hosting or PaaS will change ips when needed internally, or to rebalance the traffic, or when new hosts come up. Anyone with large enough traffic will use some edge network like CloudFlare which would also get a different address depending o…

"Anyone with large enough traffic will use some edge network like Cloudflare which would also get a different address depending on your location." What if the request is always sent from the same location? What if when the user moves location, e.g., from one country to another, she updates her stored IP addresses? "And you can't tell easily which one want." Personal experience as a user is that when it is an "intende…

> What if the request is always sent from the same location?

Then you may get the same IP.

> What if when the user moves location, e.g., from one country to another, she updates her stored IP addresses?

It doesn't have to be a different country. Different ISPs with different peering may get different results. Moving between your home wifi and you phone tethering may get different results. So depending on your usage style, it's between "change multiple times a day" and "no change".

> Personal experience as a user is that when it is an "intended" change, the previous IP address no longer hosts the content.

In some cases I'm sure it's true. In others, it isn't. Basically it's not a reliable indicator.

> If this was a BGP hijack, why did the hijackers target the IP addresses of DNS servers, rather than the target IP addresses of the websites?

Haven't seen the site's announced block, but it's possible that it's announced as /24 block. This attack was possible because Amazon announced /23 and the attacker could announce something more specific.

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

#206

Post by pfg » Tue, Apr 24, 2018, 11:39 PM UTC

ryao wrote: post #202

tialaramex wrote: post #195

Earlier quoted context omitted.

If you have DNSSEC with CAA, you can use that to choose a CA which has a contractual relationship with you. That contract can say anything you both like, for example it can say: "All issuances under example.com shall first be approved by telephone call to our security office on 1-234-567-8900, and the certificate issued shall have a notBefore timestamp no earlier than 24 hours after an SCT included in the certificate…

If the DNS servers providing that message are hijacked due to BGP, the hijacker can simply not serve that notice and the registrar doing the lookup would never see it.

This is under the assumption that CAs fail closed when they encounter DNSSEC errors (which, by some interpretations, is mandatory according to the Baseline Requirements).

Merely hijacking the authoritative DNS for a domain does not defeat DNSSEC, which chains from the root to TLDs to registered domains. In other words, and assuming all CAs are perfect w.r.t DNSSEC, you cannot spoof a "No CAA record here" response for a DNSSEC-enabled domain merely by hijacking the authoritative DNS or a resolver.

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

#207

Post by tialaramex » Tue, Apr 24, 2018, 11:40 PM UTC

rocqua wrote: post #165

tptacek wrote: post #138

Earlier quoted context omitted.

I don't know what IPSEC has to do with this. Your second link is a reference to what is now called DANE. There is an alternate universe in which DANE helps this problem. In that universe, there are no CAs anymore (otherwise, DANE is effectively just another CA, and attackers will just choose whichever CA allows them to execute their attack). But DANE is already dead on arrival. Both Mozilla and Chrome flirted with DA…

> There is an alternate universe in which DANE helps this problem. In that universe, there are no CAs anymore There is another, even less likely, universe where DANE works. Here, every cert needs to be validated by both DANE and a CA. Security wise, this would be an improvement over just CAs. However, the large governments would still be able to MitM TLDs in their control (just patriot act some CA). This is where I p…

The TLS WG is currently haggling about, effectively, DANE's future. The thing up in the air was, should this technology for saying "Hi, I can do DANE" be pinned? e.g. a client sees "I can do DANE" and it says to itself "OK, I will now expect DANE certificates from this TLS service for... 24 hours? 10 minutes? 10 years? An amount of time defined in some new parameter?" Or maybe it never does this. Last I looked at the thread, it seemed like "Never do this, make yet another TLS extension to specify if you want pinning" is the choice of the working group.

(The reason this isn't an application header like HSTS is that DANE advocates want to bake this into TLS itself, so that it works without needing new application features in every single TLS-using application)

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

#208

Post by sokoloff » Tue, Apr 24, 2018, 11:43 PM UTC

LinuxBender wrote: post #130

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

Yes, but under such a scheme, once I’ve wrestled control back of DNS, your ability to use those ill-gotten certs is reduced/eliminated.

Today, if I got a basic cert for your domain by temporarily hijacking DNS, I can later use it to MITM you even without DNS poisoning/takeover.

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

#209

Post by 925dk » Tue, Apr 24, 2018, 11:50 PM UTC

Why do AWS http://status.aws.amazon.com say that only Google resolvers were affected?

Between 4:05 AM PDT and 5:56 AM PDT, some customers may have experienced elevated errors resolving DNS records hosted on Route 53 using DNS resolvers 8.8.8.8 / 8.8.4.4. This issue was caused by a problem with a third-party Internet provider. The issue has been resolved and the service is operating normally.

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

#210

Post by tialaramex » Tue, Apr 24, 2018, 11:56 PM UTC

rocqua wrote: post #168

Already__Taken wrote: post #141

Earlier quoted context omitted.

In addition they could be behind rubbish proxy's that aren't passing the warning forward. I know ours in work will happily resign that expired cert to mitm you for compliance and the user will see that green padlock.

I get that companies need to control access to their internal networks. But surely when you do it this badly you have to realize you are only making your network less secure.

So far as we've been able to tell all the middleboxes on the market for this sort of purpose are worse than useless. If you remember that NCSC blog post that annoyed Adam Langley, its author Ian Levy insists that "there are some good products out there" I actually replied to that comment, requesting a list of these "good products" which presumably are warranted by the NCSC not to actually be worse than useless. Unsurprisingly Ian has elected not to in fact list any such products. There aren't any.