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?
Hijack of Amazon’s domain service used to reroute web traffic for two hours
171–180 of 291 posts
Re: Hijack of Amazon’s domain service used to reroute web traffic for two hours
#172Earlier quoted context omitted.
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. Thi…
Yeah you're correct. There was a great defcon presentation on this in 2015: https://www.blackhat.com/docs/us-15/materials/us-15-Gavriche...
Really the hardest part of the attack, and what makes it so infrequent, is the social engineering aspect of registering the AS and getting an influential peer to accept your advertisements. To really cover your tracks you would need fake identities, fake businesses, fake bank accounts...
Re: Hijack of Amazon’s domain service used to reroute web traffic for two hours
#173"Between 11am until 1pm UTC today, DNS traffic-the phone book of the internet, routing you to your favourite websites-was hijacked by an unknown actor." Is it worth keeping a record of the IP addresses for "your favorite websites"? For example, with IP addresses saved, would this enable reaching the websites ven if DNS is not working? How often do these "favorite websites" change IP addresses? Are they all the same i…
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 on your location.
Some IPs may stay stable for a long time, but virtually every change to them is going to be intended. And you can't tell easily which one want.
Re: Hijack of Amazon’s domain service used to reroute web traffic for two hours
#174What'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...
Re: Hijack of Amazon’s domain service used to reroute web traffic for two hours
#175Earlier quoted context omitted.
Sorry how does that help if the attackers purchase a new "valid" SSL certificate since they control the DNS and thus email?
Once you control DNS, it doesn't require email, you can just use lets-encrypt. The lets-encrypt verification does not check HSTS. Makes sense because it keeps HSTS from the lockout scenario that makes HPKP so scary.
Is it possible to get a TLD registrar to set a very short TTL like 5min on your NS record? Then you can switch to a backup DNS hosted on another network fast.
Re: Hijack of Amazon’s domain service used to reroute web traffic for two hours
#176Earlier quoted context omitted.
Wow, that's scary. I even told someone recently, jokingly of course, they forgot to add HSTS for their mvp app. But MEW doesn't have HSTS? I would never use it personally on a public Wifi, but many people will for sure and they have no idea they'd be MITM'd.
> But MEW doesn't have HSTS? I would never use it personally on a public Wifi, but many people will for sure and they have no idea they'd be MITM'd. Even without HSTS a bad actor would have to either trick a user to install a root cert or trick a certificate authority to generate a cert for the domain. Both of these are possible and have happened in the past, but they're also are a requirement for the attack you ment…
No they wouldn't, without HSTS a bad actor (public wifi) could just do an SSL strip attack. Sure, observant users would notice that the page isn't over https, and with browsers adding warnings on all http pages, that'll become more obvious, but it's still not something most people notice.
Are you thinking of HPKP?
Re: Hijack of Amazon’s domain service used to reroute web traffic for two hours
#177Earlier quoted context omitted.
CAA depends on CAs (all 650 of them) to respect it, and for all of them to implement everything perfectly (it was shown in 2017 that they don't). This also depends on DNS again, which again not everyone will do properly, so CAA requests from CAs can be hijacked. So CAA is stupid. The client should be getting the list of authorized CAs for the domain from DNS on first connection, and/or from inside the first cert, wit…
CAA support wasn't mandatory for WebPKI CAs until 2017-09-08 so it's likely that it's better supported now than it was last year.
Assuming every CA's support was perfect (again, 650 of them, so not likely), CAA still does not stop these attacks. Domains have to implement CAA. Most domains do not, so most domains remain vulnerable.
Even if the domain does, if either they or a CA screw anything up, they are vulnerable. The client will accept any cert signed by any CA. One rogue cert screws the security.
Compare this to if the client was verifying it using a blockchain. The blockchain provides a record that the client can verify, not only from multiple peers that share the same records, but at the sources of the original records, to verify a CA was authorized, and to verify a specific domain owner created a cert. This is a much higher barrier to attack than what CAA provides. Even if this verification were optional, it would be a much better authenticity guarantee than what clients get today.
The other thing a blockchain would provide is protection against state actors. If the FBI barges into Verisign waving a FISA warrant, they could possibly force Verisign to generate valid certs outside of the CT or CAA process. A blockchain could show the client that a cert it received was never in the blockchain. Comparing the blockchain to CT could further emphasize rogue certs.
Re: Hijack of Amazon’s domain service used to reroute web traffic for two hours
#178Earlier quoted context omitted.
Forgive my ignorance but I have a few questions: * Why would HSTS help in this case? While HSTS is active, does it prevent clicking through the warning (which was done here)? * How would a CAA record help against cert issuance in this case? Is it only helping against compromise of the authoritative during the remaining TTL of the record in recursives AND if the CAA record points to something that doesn't have on-dema…
HSTS wouldn't help users clicking through warnings, but it's a good thing to have (myetherwallet doesn't use HSTS). CAA record would only help in remaining TTL. Once expired, then it doesn't matter. So yeah, these seem like decent steps to help protect but certainly not going to 100% prevent an attack like this one.
I'm seeing HSTS on https://www.myetherwallet.com/
curl -I https://www.myetherwallet.com/
strict-transport-security: max-age=63072000; includeSubdomains; preloadRe: Hijack of Amazon’s domain service used to reroute web traffic for two hours
#179Earlier quoted context omitted.
Once you control DNS, it doesn't require email, you can just use lets-encrypt. The lets-encrypt verification does not check HSTS. Makes sense because it keeps HSTS from the lockout scenario that makes HPKP so scary.
Is it possible to get a TLD registrar to set a very short TTL like 5min on your NS record? Then you can switch to a backup DNS hosted on another network fast.
Yes, you can set a short TTL on your NS record, but that would not keep this attack from hijacking your site.
This attack intercepts the clients DNS lookup, so the DNS a browser is talking to is ill-behaved.
No amount of correct setup here will work because the ill-behaved DNS server will just replace your setup with whatever that server wants.
There is no strong defense against this as a website. With an app the solution would be certificate pinning. You could try HPKP but that comes with a host of issues and I think it is being deprecated.
Re: Hijack of Amazon’s domain service used to reroute web traffic for two hours
#180Earlier quoted context omitted.
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. Thi…
Confusion prevention squad:
> That is to get to 3.3.3.3 A 3.3.0.0/16 route takes precedence over a 3.0.0.0/32 route.
I think you mean:
> 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.
a /32 is _more_ specific.