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

#161

Post by LinuxBender » Tue, Apr 24, 2018, 9:49 PM UTC

mehrdadn wrote: post #145

LinuxBender wrote: post #130

Earlier quoted context omitted.

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…

> 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. I thought HPKP is TOFU, not (necessarily?) preloaded? Meaning you don't need to control the client for the client to be able to take advantage of it?

This came up when the root servers for .io were hijacked. It's really the same problem. Short of monitoring for such anomalies, the only saving grace would be HPKP which is just too risky to use outside of mobile apps. Why the attackers in this case didn't get valid certs, I have no idea. It takes seconds to get a wildcard now.

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

#162

Post by rocqua » Tue, Apr 24, 2018, 9:50 PM UTC

tptacek wrote: post #108

knome wrote: post #57

Earlier quoted context omitted.

DNSSEC adoption would prevent a hijacker from manipulating responses.

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'd expect there are limits to BGP hijacking. Certainly not every BGP router can hijack any IP. Moreover, the more specific the hijack, the clearer the target.

At this point in this attack, we are not sure of which domains have been hit. With a BGP attack, the specific IPs would've been quite public.

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

#163

Post by dharma1 » Tue, Apr 24, 2018, 9:54 PM UTC

Also experienced this today - was doing user testing on an app, and suddenly our AWS hosted app that uses Route 53 stopped working, didn't resolve. When I checked http://status.aws.amazon.com/ it showed all green for Route 53 though.

Luckily I noticed the app kept on working on my own devices where I had previously switched the DNS to 1.1.1.1 (Thanks HN for the heads up on that a few weeks ago!) - otherwise would have been a waste of half a day in an expensive user testing lab.

Assumed it was Putin's blocking of Amazon and Google IP's that had been on the news, but guess it was just hackers after some ETH. Or was it?

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

#164

Post by viraptor » Tue, Apr 24, 2018, 9:57 PM UTC

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…

SomeNationalBank.com in my experience uses 1 or 2 ciphers which are not the most modern, but are secure enough. For a few reasons there are almost no banks which would allow you to drop lower than aes-128-cbc.

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

#165

Post by rocqua » Tue, Apr 24, 2018, 9:58 PM UTC

tptacek wrote: post #138

raldi wrote: post #134

Earlier quoted context omitted.

Wouldn't https://tools.ietf.org/html/rfc4025 and https://tools.ietf.org/html/rfc4398 cover those cases?

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 point out that the current CA system is also controlled by those who control the TLD, because domain validation depends on the DNS system. But that is an old argument.

There is some hope for the CA system through the use of certificate transparency logs. Notably, this system moves away from trusting the DNS system. Sadly, it is mostly a detection-after-the-fact system, but there is hope.

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

#166

Post by mercora » Tue, Apr 24, 2018, 9:59 PM UTC

I wonder why they did not reroute traffic for their targets directly. I assume the amount of traffic the Route53 servers get is quite a lot to handle and failure to do so would make a lot of people aware of some issue. Also, how is it possible to reach the original servers in order to forward non targeted lookups to them? Is it possible to have your own routes not affected by your own BGP announcements? Maybe they were able to do this by using EC2 internal DNS resolvers?

Maybe Route53 does use individual IP addresses for the nameservers of registered domains? Or at least are using them hihgly segmented? I guess this would help to handle the amount of traffic quite a bit if so. Otherwise it seems inplausible that the mentioned site is the only target or that there was just a few targets because that should be easier to pull off.

On the other hand i am not sure if these targets might share IP addresses with a large pool of websites and handling "only" authoritative DNS requests for them (and any other that happens to have the same IP addresses setup as nameserver) would be alot easier. How does Route53 handle delegation exactly? Would i have to handle all NS requests that happens to resolve to Route53 or just some specific set of domains? Only handling these delegation related NS requests might reduce the amount of traffic alot in any case. But maybe they setup glue records for registered domains. In this case the amount of traffic they would have to handle would be even larger and i guess disrupt quite alot of DNS clients because they would not be able to sign the zone properly.

I also wonder why they were not able to issue a new valid certificate. This appears to be very easy even without any interruption at this stage. Especially this feels like it was only done in order to direct the attention away.

Hopefully a more detailed writeup appears because this seems rather interesting.

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

#167

Post by mcqueenjordan » Tue, Apr 24, 2018, 10:01 PM UTC

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.

[5:49 AM PDT] We have identified the cause for an elevation in DNS resolution errors using third party DNS resolvers 8.8.8.8 / 8.8.4.4 and are working towards resolution. DNS resolution using other third-party DNS resolvers or DNS resolution from within EC2 instances using the default EC2 resolvers continues to work normally.

[6:10 AM PDT] 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

#168

Post by rocqua » Tue, Apr 24, 2018, 10:02 PM UTC

Already__Taken wrote: post #141

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?

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.

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

#169

Post by rocqua » Tue, Apr 24, 2018, 10:04 PM UTC

ceejayoz wrote: post #13

conistonwater wrote: post #9

> This traffic was redirected to a server hosted in Russia, which served the website using a fake certificate — they also stole the cryptocoins of customers. What does this sentence mean? Sorry if I'm being slow. I thought the whole point of certificates is that you can't generate a legitimate one for a domain you don't control, so messing with name resolution wouldn't affect it.

They rerouted DNS traffic, which would've let them point the domain at their own servers, which would've let them successfully get a new SSL certificate.

Apparently they didn't though. Reports are that they just served an unstrusted certificate and people clicked through all the warnings (or their browsers failed to detect the faulty cert, or some middle box proxy failed to)

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

#170

Post by rocqua » Tue, Apr 24, 2018, 10:10 PM UTC

chatmasta wrote: post #82

vasilipupkin wrote: post #61

can someone ELI5 how this works? like, how do they physically do this ?

I’m not an expert, but I think it goes something like this — You register an AS and get a dedicated server [0] at at an internet exchange point (IXP) and install a BGP router on it. Your router advertises a route to the original route53 IP, with a shorter AS path to the target IP than the route advertised by the “real” Amazon router. You peer your router with at least one provider who peers with the real route53 serv…

Not an expert either, but I think it was slightly different.

Firstly, I believe BGP hijacking works by announcing a more specific prefix rather than path-length. That is to get to 3.3.3.3 A 3.3.0.0/16 route takes precedence over a 3.0.0.0/8 route.

Secondly, this attack did not obtain a valid cert. They probably could have using spoofing (either of MX or just of A records and using lets-encrypt), but they did not. This might be because the BGP hijack did not affect any CA, or it might just have been laziness.