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

281–290 of 291 posts

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

#281

Post by tptacek »

raldi wrote: post #273
tialaramex wrote: post #221

Earlier quoted context omitted.

So, you should not be surprised (but perhaps you are anyway) that how to work around not having DNSSEC on end systems is exactly what this work was about. Specifically, the idea is you shove DNSSEC RRs into TLS. Now the client doesn't need working DNSSEC, because the DNSSEC records were delivered with the connection. Hence the pinning question.

There's also https://tools.ietf.org/html/rfc4956 , which allows a domain to sign that a range of DNS entries does not exist; under this system, a client resolver could demand cryptographic proof that a domain was missing certain records, which stops the MitM RR-stripping attack.

You're describing authenticated denial, which has been a characteristic of DNSSEC since 1994.

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

#282

Post by raldi »

tptacek wrote: post #281
raldi wrote: post #273

Earlier quoted context omitted.

There's also https://tools.ietf.org/html/rfc4956 , which allows a domain to sign that a range of DNS entries does not exist; under this system, a client resolver could demand cryptographic proof that a domain was missing certain records, which stops the MitM RR-stripping attack.

You're describing authenticated denial, which has been a characteristic of DNSSEC since 1994.

Yes, exactly. The RFC I linked to specifically refers to Authenticated Denial in the Security Considerations section.

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

#283

Post by notriddle »

xnyanta wrote: post #101
24gttghh wrote: post #54

Earlier quoted context omitted.

For some reason I thought CA's at least talked to each other to see if someone else had issued a valid cert for a given domain along the lines of owning a domain name itself through a registrar. Clearly that only works when DNS isn't being abused like this...

Why should websites be limited to having only one certificate? For example, if you have a service running on multiple backed servers, you might want to have once certificate per server for all of your domains.

That use case still wouldn't explain a domain having certs from two different CAs.

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

#284

Post by zjs »

rphlx wrote: post #263
pawal wrote: post #248

Earlier quoted context omitted.

We should not "give up on BGP". What we should do is to improve security in all layers. This includes BGP, and as you mention DNS. DNSSEC should be mandatory, just as TLS, for any business that take themselves seriously.

Not to start another DNSSEC melee (as I start another DNSSEC melee..) but for it to be effective we really need browsers to a) be able to tell whether a DNS response was properly DNSSEC signed or not, b) produce some large, scary, red warning for ones that aren't, mark them "Not Secure", etc. [1] There is a major chicken-and-egg/game-theoretical problem though: any browser that does that today will piss off/irritate…

> There is a major chicken-and-egg/game-theoretical problem though: any browser that does that today will piss off/irritate its users, forcing them to use other browsers or older versions of the same browser, as DNSSEC is not widely deployed on the corporate side. And until most/all browsers do something major to make the current DNS security crisis obvious to large numbers of users, most companies won't care enough to deploy DNSSEC.

This seems analogous to the problem browsers faced with Flash. Perhaps they can leverage the same incremental approach here.

For example: 1) Validate DNSSEC. If present and valid, the HTTPS "green lock icon" gets a bonus glow. 2) 6 months later, not having a DNSSEC response gives a little red X badge on the "green lock icon". 3) 6 months later, not having a DNSSEC response graduates to a little ignorable info/warning box near the location bar. 4) 12 months later, you have to click through a big scary warning to access the site.

Essentially, start by providing a carrot and then introduce a progressively larger stick. Communicate the whole plan up front so that large organizations can get the ball rolling.

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

#285

Post by Kalium »

ryao wrote: post #203
Kalium wrote: post #64

Earlier quoted context omitted.

> * 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.

Believe me, I'd very much like that. I'm better aware than most of their technical capabilities and speed.

When I say "a lot of people running services", I don't mean me. I mean a lot of people I know and associate with. A lot of them have grown to rely on close integration between DNS and all their other infrastructure services. That CF covers them technically isn't helpful - they expected it all under one roof and they need to not spend cycles on thinking about something marginal to them like DNS.

One of the biggest selling-points of AWS is that it puts all your services in one spot. It limits orchestration work and makes life simpler. Asking people to leave that for security improvements may be necessary, but it's not a small ask.

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

#286

Post by ruddell »

7ewis wrote: post #250
adamb_ wrote: post #219

Earlier quoted context omitted.

> How would you see this in ThousandEyes? Checkout this video analysis from the team on the hijack: https://youtu.be/YXm4GJMUlP0

Thanks! Do you know how I can access that page he is on? I'd like to have a click around myself.

Here's the link he starts on in the video:

https://webysvi.share.thousandeyes.com/view/tests/?roundId=1...

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

#287

Post by technion »

kchr wrote: post #270
technion wrote: post #246

Earlier quoted context omitted.

I'm going to assume that Lets Encrypt wasn't impacted for the reason that there are several discussions that the hijacked myetherwallet website apparently had a self signed SSL cert running - and people were actually clicking through the warnings before handing over passwords. Surely they would have realised they could make the whole thing a lot more profitable if any SSL provider was impacted.

But if you route all traffic for a specific domain through your own web server, surely you could complete the Letsencrypt verification steps as well. They just check for a specific file on the remote web server, right?

Yes, but they weren't routing traffic for that web server to their own server. They were routing the IP of the DNS servers to their own server, and then just handing out the DNS address that suited them.

In turn, if your own DNS wasn't configured to use a DNS server with a poisoned fraudulent address, a web server based verification landed on the valid server, not the attackers.

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

#288

Post by jnw2 »

jaas wrote: post #236
erulabs wrote: post #218

Earlier quoted context omitted.

I would assume they go far out of their way to resolve the address from a large number of distributed DNS resolvers - the question is if they're just round robin instead of multiple simultaneous queries, but I would hope that's part of why the DNS test usualy takes >60 seconds. If they're not treating DNS as a consensus protocol instead of as an immutable database, they'll always be open to poisoning attacks. If any…

Let's Encrypt does not currently validate from multiple perspectives but we're working on it. We're cooperating with a research team at Princeton to make sure our strategy is an effective mitigation against BGP attacks. Any given production validation right now may come from one of two of our datacenter locations, but not both. You may see multiple validation requests if you use our staging servers, but that's just a…

If you can do validation from a perspective where your ISP can send you a full BGP table, you should be able to keep track of how recently the most specific route to that destination has changed; something that has changed recently or that currently has an AS path different than what has historically been typical may be suspect.

AWS does have some network diversity in different regions; they apparently do not operate their own backbone to interconnect the different AWS regions.

(And for all that Hurricane Electric seems to have not been doing a great job of filtering BGP announcements from peers, they do seem to have pretty aggressive pricing on colo space in their Fremont data center where they can provide a full BGP feed.)

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

#289

Post by kchr »

technion wrote: post #287
kchr wrote: post #270

Earlier quoted context omitted.

But if you route all traffic for a specific domain through your own web server, surely you could complete the Letsencrypt verification steps as well. They just check for a specific file on the remote web server, right?

Yes, but they weren't routing traffic for that web server to their own server. They were routing the IP of the DNS servers to their own server, and then just handing out the DNS address that suited them. In turn, if your own DNS wasn't configured to use a DNS server with a poisoned fraudulent address, a web server based verification landed on the valid server, not the attackers.

Okay, thanks for clarifying!

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

#290

Post by YouKnowBetter »

rodionos wrote: post #260

If you use Route53, I encourage to you to check crt.sh if any SSL certificates were issued for your subdomain over the last few days. Example: https://crt.sh/?Identity=%.MyEtherWallet.com Keep in mind that crt.sh has a certain time lag between the time a certificate is issued and a certificate entry is inserted into the crt.sh database.

Your advice should get much much more attention. You got mine, thanks.
Post reply on HN