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

101–110 of 291 posts

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

#101

Post by xnyanta »

24gttghh wrote: post #54
jerf wrote: post #41

Earlier quoted context omitted.

Step one: Hijack the DNS entries so they point at your site. Step two: Obtain a certificate from Let's Encrypt using website validation. Step three: Proxy traffic through a proxy you provide that SSL cert for and capture anything you like. In the event that a website legitimately has a higher-class Extended Validation cert or other such thing, hope users don't notice the downgrade from Extended Validation correct SSL…

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.

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

#102

Post by ryanlol »

cowkingdeluxe wrote: post #56
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…

How similar was this to the BGP attack by Russia in late 2017? https://arstechnica.com/information-technology/2017/12/suspi...

>by Russia

Sounds like xenophobic bullshit.

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

#103

Post by notyourday »

vasilipupkin wrote: post #61

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

It is extremely unlikely that they did what this article claimed.

If they did, this is what would have happened (this ignores specific implementations which may make certain parts of this impossible which in turn would completely block this kind of attack):

1. Attackers would have noticed that either AWS does not register their prefixes or some of the prefixes were not registered or their registered policies did not match the views of AWS from the location that was to be attacked.

2. Attackers identified transit networks that did not enforce AWS registered policies for routes advertised by AWS as well as their peers that had the same flaw.

3. Attackers obtained credentials to the router(s) and monitoring/provisioning systems used by the transit networks that would have been attacked.

4. After obtaining access to the (3) and disabling monitoring/provisioning/version control systems(!)/automated backups/verification(!) the attackers brought up a GRE-type tunnel to some destination that the attackers controlled.

5. Attackers shimmed a static route for the address space that the attackers needed to attack pointing it to the local side of the GRE-type tunnel thereby sending the traffic to the servers controlled by the attackers.

6. Using a few other techniques ( most likely another GRE-type tunnel ), the attackers created a way for MITM traffic to get back to the attacked router.

7. Attackers added the route that was being MITM into IGP protocol of the router they got credentials to. Attackers adjusted outbound filters between this router and other routers from (2) to allow this route to be announced to the routers in (2).

8. Networks in (2) would not filter AWS announcement, so anyone who would be single-homed to networks in (2) would be no wiser that their traffic never reached the affected prefix. Those that receive transit from (2) via BGP and do not do a full policy based prefix filtering would be affected if those networks did not engage in hot potato-type routing.

All in all, it is extremely unlikely that a full global BGP hijack happened.

All of this needed to be done without configuration changes being picked up or overridden by management systems which is extremely unlikely on non-hobo ran networks identified in (2)

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

#104

Post by disiplus »

philjohn wrote: post #33
Diederich wrote: post #25

Earlier quoted context omitted.

Update: see other comment chains invalidating the security I'm claiming HSTS provides. APIs will probably go directly to https:// , and hopefully cert failures will cause the API to blow up with minimal harm. If you want to visit my web site, and you need to type it in, you'll probably just put realms.org into the URL bar of your browser. Most secure websites, such as paypal.com, have something called HSTS https://en…

Except, it would have been trivial for them to get Lets Encrypt to issue them a valid cert.

i assume that did not work because the challenge would fail because it looks that only google dns would return invalid results.

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

#105

Post by OJFord »

Surely related (and warning!):

During this period I received an email from:

    ship-confirm@amazon.com
purporting to notify me of the despatch of a non-existent order; with an attached .zip.

Nothing about the message, except the .zip and suggestion of an order's existence, was at all suspicious - all links point to amazon.com.

I checked on amazon.com (without following a link) and on amazon.co.uk (where I would usually shop) and an order with the given number does not exist for my account.

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

#106

Post by tptacek »

toast0 wrote: post #68
EE84M3i wrote: post #45

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

> * Why would HSTS help in this case? While HSTS is active, does it prevent clicking through the warning (which was done here)? Yes, HSTS (if preloaded or cached by the browser) prevents clicking through the warning, although there's a secret code you can type in chrome? to get around it still. > * CAA record Yeah, a CAA record wouldn't help. Presumably the CA in question is going to want to get that record freshly,…

DNSSEC only "helps" if you can get CAA working reliably with it, because otherwise, it's only role in this attack is to lock CAs to a particular IP address. But this is a BGP hijack: attackers control IP.

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

#107

Post by zokier »

vasilipupkin wrote: post #61

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

Physically? Hammering on the keyboard sitting in a dark room wearing a hoodie. Its not like you need to start pulling cables to do this sort of thing, internet routing is all software and configuration based which is pretty much its core characteristic.

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

#108

Post by tptacek »

knome wrote: post #57
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…

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.

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

#109

Post by caymanjim »

triplenineteen wrote: post #97
an_account_name wrote: post #72

Earlier quoted context omitted.

HSTS does indeed prevent users from clicking through the warning - it makes handshake / trust chain failure fatal with no "proceed anyway" button.

Sorta. In most browsers you can manually delete the HSTS property on a per-domain basis. Presumably, anyone doing this knows the risks.

In Chrome, it's a real pain in the ass, and it's buried deeply. It's not available at all in the settings UI (not even in advanced settings).

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

#110

Post by notyourday »

nodesocket wrote: post #89
noselasd wrote: post #87

Earlier quoted context omitted.

There's an informal trust chain. You only set up BGP peering with companies you trust, and you implement filtering of it's traffic and advertised routes that you know can be trusted. You know that if you do something nefarious, or if someone at your downstream does something nefarious, your upstream will identify it and block your traffic, or the part of it that they identify to be the issue. Thus as long as you need…

So if BGP is trust based and hard to compromise then how were these Russians able to? > They re-routed DNS traffic using a man in the middle attack using a server at Equinix in Chicago.

Because large networks do not register all their prefixes or enforce policies on what they accept from other large networks. So a large network can do this. Allowing a small network to do this demonstrates incompetence. Frankly, I am having a hard time believing that HE.NET failed that badly.

AS7007 incident demonstrated this being a bad idea in the nineties.

Post reply on HN