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

231–240 of 291 posts

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

#231

Post by quickthrower2 »

artursapek wrote: post #113
kentt wrote: post #95

Wow myetherwallet is trusted for transaction very non-trivial amounts. What would a good mitigation strategy be for these types of attacks.

Making sure the cert is valid.

Also do a dry run before each usage, generating a throwaway wallet, and inspect the network tab / use fiddler to check if there is any suspicious sending of data.

Even this isn't 100% as they could seed keys if bad person gets control of the website. This has been done many times in the IOTA community for example, albeit those sites were dodgy from the get-go.

So I'd probably get a snapshot of their client code when you trust it, and serve it to yourself locally thereafter.

It's a sad state of affairs that people use services like this. I have done so myself :-(

The reason is that the Ethereum desktop clients suck. More than suck, they are untenable. The official client never synced even after running for 2 weeks. I tried this twice. It is awful.

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

#232

Post by cjbprime »

peterwwillis wrote: post #229
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…

It doesn't matter how many DNS resolvers you have. If you can spoof BGP, and use it to spoof the DNS resolvers, and the authoritative name server, you can stand up your own DNS that says anything you want it to say. The only thing you cannot do is fake out DNSSEC. If you use a TLD which supports DNSSEC, you can make sure records have to be signed with your key. If fake DNS records aren't signed with your key, and the…

And if you lose the key, as thousands of people would every day at a large registrar?

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

#233

Post by dgemm »

925dk wrote: post #214
fooblitzky wrote: post #211

Earlier quoted context omitted.

It seems like either the title is misleading, or the article does a poor job of explaining the situation. From my reading of the article text, it seems DNS traffic was rerouted to Route53, which the attackers then used to serve false DNS records. That does not sound like Route53 was hijacked at all, just that the attackers happened to use the service it provides.

Traffic to Route 53 was rerouted to an alternative DNS server. But that has nothing to do with my question re. AWS calling out Google in particular in their status update.

Some Route53 traffic was redirected somewhere else. Traffic can only be hijacked from neighbors that actually accept the routes. You would think Google of all networks would have effective ingress filtering to prevent this, but it seems like they did accept it in this case.

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

#235

Post by peterwwillis »

cjbprime wrote: post #232
peterwwillis wrote: post #229

Earlier quoted context omitted.

It doesn't matter how many DNS resolvers you have. If you can spoof BGP, and use it to spoof the DNS resolvers, and the authoritative name server, you can stand up your own DNS that says anything you want it to say. The only thing you cannot do is fake out DNSSEC. If you use a TLD which supports DNSSEC, you can make sure records have to be signed with your key. If fake DNS records aren't signed with your key, and the…

And if you lose the key, as thousands of people would every day at a large registrar?

Use the same method you use to pay for the domain to reset the key. This would require logging into your account at the registrar, or contacting support and providing enough verifiable material to reset it.

If the registrar signed a message that had your key in it, they could re-sign it with a replacement key. So now you can 1) verify who originally assigned the domain, 2) record the public key, and 3) see a verifiable history of changes as long as the old history is included in successive signing. This could be used as part of a public record ala Certificate Transparency, or a blockchain-style system. If the attacker spoofs BGP and SE's your registrar, you (or whomever) can see if anyone creates a new key.

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

#236

Post by jaas »

erulabs wrote: post #218
mlosapio wrote: post #215

Wonder if services like Let’s Encrypt were affected. I imagine a scenario where a small hijack of DNS could allow for properly signed certificates for domains that are not owned. If I operated a CA service, I would carefully examine the requests received during this time frame. Maybe someone can audit the Transparency Logs during this period for anomalous activity.

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 an early version of multi perspective validation which doesn't work well enough to promote to production. There are some performance issues, and the external validation points are all on AWS, which uses the same autonomous system (AS) across datacenters. In order to effectively defend against BGP attacks we're probably going to have to deploy validation servers on 3+ different ASes so that our network perspectives are sufficiently diverse.

If multi perspective validation is effective and nothing is done to significantly improve BGP security (we're not holding our breath) then I expect multi perspective validation to be a requirement for all CAs down the line.

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

#237

Post by eastdakota »

fernandotakai wrote: post #17
zegl wrote: post #8

We experienced the same thing. DNS lookups via Googles public DNS servers where failing for one of our hosted zones. Interestingly this only seemed to be a problem with Google DNS, other large providers as well as smaller ones where not affected.

we saw the same thing. dns stopped resolving while using google's dns for about 2h. there's a route53 status update on their page that says basically that -- only affected google dns.

That’s simply wrong. Best case, this is ignorance on the Route53 marketing team. Worst, it’s actively misleading. Disappointing either way.

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

#238

Post by lathiat »

xraystyle wrote: post #213
chatmasta wrote: post #171

What separates BGP hijacking from BGP anycast? Amazon is already advertising a bunch of routes to its route53 IP's for BGP anycast. How can an upstream peer tell if a new advertisement is another anycast route vs. a hijacked prefix? Is the only way to tell by validating the advertisement came from Amazon?

The issue here is that the attackers were advertising more specific prefixes, and when doing route selection, routers pick routes to these over less specific prefixes that cover the same ranges. e.g. if Amazon was announcing 205.51.192.0/21, that would cover all the /24s that were announced in the hijack. Not sure what Amazon actually announces, this is all just examples. Say I'm trying to get to 205.51.192.12, for e…

As much as it's bad for routing table inflation, given how much content they host Amazon should probably consider de-aggregating their DNS resolver prefixes to /24 announcements which would limit the effect to be much more local for the majority of the Internet.

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

#239

Post by lathiat »

jsmthrowaway wrote: post #174
mcqueenjordan wrote: post #167

What's with the clickbait title? It is simply a falsehood. Here's the update from the horse's mouth: [5:19 AM PDT] We are investigating reports of problems resolving some DNS records hosted on Route53 using the third party DNS resolvers 8.8.8.8 and 8.8.4.4 . DNS resolution using other third-party DNS resolvers or DNS resolution from within EC2 instances using the default EC2 resolvers are not affected at this time. […

The horse's mouth, in this case, speaks nonsense. Multiple /24s were announced more specifically to the DFZ , and that has absolutely nothing to do with Google's DNS resolvers. "Simply a falsehood," indeed. https://twitter.com/InternetIntel/status/988792927068610561 https://arstechnica.com/information-technology/2018/04/suspi...

The horses mouth actually does say it, you'll note they said

"This issue was caused by a problem with a third-party Internet provider."

As soon as I read this and saw the myetherwallet announcement I called it last night that's exactly what they did, and today I find out that was the case.

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

#240

Post by lathiat »

notyourday wrote: post #47

This is another one of the articles that says absolutely nothing. The only reason why such attack was possible is because some of the providers did not filter announcements from hobos claiming to be able to advertise AWS space. That could have only happened if: a) AWS did not register all their policy prefixes b) providers did not apply filters on the transit announcements from those that announced AWS prefixes based…

If you think the majority of BGP speakers world-wide are applying these announcement filters you are sadly mistaken.
Post reply on HN