can someone ELI5 how this works? like, how do they physically do 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 servers (they accept your route advertisements).
Then you redirect incoming traffic on port 53 to a mitm dns proxy, where you either do nothing or return an IP address you control, which could be anywhere.
At the IP address you control, you run a transparent HTTP proxy that signs HTTPS responses with the valid DNS cert you obtained by spoofing MX replies in the dns proxy. You then either do nothing, or modify the page to return arbitrary content (like rewriting bitcoin addresses).
[0] or you get a VPS at a provider willing to advertise BGP routes on your behalf without validating them
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.
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...
BGP Path to Target IP prefix = ordered list of autonomous systems to reach target IP prefix
The point of BGP is to find the shortest AS path to an IP. Each AS has at least one router, and each router has at least one other AS peer. A router will forward the packet as far as it can given the peers it knows, until the AS list is length 0, at which point the controlling AS routes traffic to its destination.
Basically, a top level Internet shard. You need to become a Real ISP to pull off this attack.
Then you need to find other ASes to peer with you of course.
Also note that technically all you need is the ability to advertise routes. That could be mutually exclusive from AS status if your server provider is willing to advertise routes from their AS on your behalf (like vultr does, I think). In that case the provider is acting irresponsibly and should validate the routes.
> 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.
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)
https://stat.ripe.net/205.251.192.0%2F24#tabId=routing
As far as I know, most of ASNs only filter routes coming from their direct customers (if even that and even in that case they are likely to accept those prefixes from their own peers), so once route gets into the tier 1 ISPs routing tables, it's going to be propagated pretty much everywhere.
They should also be constantly monitoring views of AWS network from other BGP speaking networks, allowing them to immediately detect such poisoning. If other important BGP speaking network does not want to provide them the view, they can go to a single-homed with BGP customer of such network and buy the view.