Amazon recently lost control of IP addresses it uses to host cloud services and took more than three hours to regain control, a flaw that allowed hackers to steal $235,000 worth of cryptocurrency from users stealing one of the affected customers, as an analysis shows.
The hackers took control of approximately 212 IP addresses through BGP hijacking, a form of attack that exploits known vulnerabilities in a core Internet protocol. BGP, short for Border Gateway Protocol, is a technical specification that large network operators, called Autonomous System Networks, use to interoperate with other ASNs. Despite its critical role in routing large amounts of data across the globe in real-time, BGP still largely relies on the Internet’s equivalent of word of mouth to allow organizations to track which IP addresses legitimately belong to which ASNs.
A case of mistaken identity
Last month, autonomous system 209243, owned by British network operator Quickhost.uk, suddenly began to announce that its infrastructure was the right way for other ASNs to access a so-called /24 block of IP addresses belonging to AS-16509 heard from at least three shipping notifications operated by Amazon. The hijacked block contained 18.104.22.168, an IP address representing cbridge-prod2.celer.nethosting, a subdomain responsible for providing a critical smart contract UI for cryptocurrency exchange Celer Bridge.
On August 17, the attackers used the hijacking to first obtain a TLS certificate for cbridge-prod2.celer.net because they could prove to the GoGetSSL certificate authority in Latvia that they control the subdomain. With possession of the certificate, the hijackers then hosted their own smart contract on the same domain and awaited visits from people trying to access Celer Bridge’s genuine cbridge-prod2.celer.network page.
In total, the malicious contract drained a total of $234,866.65 from 32 accounts, according to this report by Coinbase’s Threat Intelligence team.
Coinbase team members explained:
The phishing contract closely resembles the official Celer Bridge contract, mimicking many of its characteristics. For all methods not explicitly defined in the phishing contract, it implements a proxy structure that forwards calls to the legitimate Celer Bridge contract. The proxy contract is unique for each chain and is configured at initialization. The following command illustrates the contents of the memory slot responsible for the phishing contract proxy configuration:
The phishing contract steals users’ funds using two approaches:
- All tokens approved by phishing victims are flushed using a custom method with a 4-byte value 0x9c307de6().
- The phishing contract overrides the following methods designed to instantly steal a victim’s tokens:
- send()- used to steal tokens (e.g. USDC)
- sendNative() — used to steal native assets (e.g. ETH)
- addLiquidity() – used to steal tokens (e.g. USDC)
- addNativeLiquidity() — used to steal native assets (e.g. ETH)
Below is an example of a reverse engineered snippet that redirects assets to the attacker’s wallet:
Hello Amazon? Anyone there?
As shown in the green sections at the top of this graph, created by Doug Madory of network monitoring company Kentik, the BGP fraudulent announcement began around 19:39 UTC on August 17 and was accepted worldwide within seconds. For reasons unknown, the announcement was withdrawn at 20:22, only to return and be withdrawn three more times over the next 68 minutes.
The announcement claimed that 22.214.171.124/24 came from AS-14618, one of Amazon’s other ASNs, and should be routed through AS-20943 from Quickhostuk. A new announcement like this — which within seconds causes the entire internet to route Amazon IP addresses through the Quickhostuk ASN — is the kind of event that should have prompted an immediate investigation by the cloud provider. For unknown reasons, Amazon only started posting the correct path for the /24 block (as indicated in purple in the graphic above) at 11:07 p.m., more than three hours after the fraudulent announcements began.
“The key detail here that would have differentiated this alert from the appearance of another Amazon peer would have been that the new upstream was seen by 100% of BGP vantage points,” Madory wrote Thursday. “In other words, this new Amazon prefix was exclusively carried over from this relatively unknown hosting provider. That should have raised some eyebrows from the Amazon NetOps team.”
Amazon representatives have not responded to any of the three emails requesting comment on this post that have been sent in the past nine days. Quickhostuk officials also did not respond to two emails asking how the fraudulent announcements came about. This post will be updated if someone replies later.
It’s not the first time that a BGP attack on an Amazon IP address has resulted in huge cryptocurrency losses. In 2018, an eerily similar event happened with Amazon’s domain name system service Route 53. The attack resulted in approximately $150,000 in cryptocurrency being withdrawn from account holders at MyEtherWallet.com. The amount stolen would likely have been higher if the attackers had obtained a browser-trusted TLS certificate, rather than using a self-signed certificate that required victims to click through an alert.
After the 2018 attack, Amazon added more than 5,000 of its IP prefixes on so-called ROAs, short for Route Origin Authorizations, i.e. public documents that show which ASNs are authorized to disclose which IP addresses. The move provided some protection against an RPKI, or resource public key infrastructure that uses digital certificates to associate ASNs with their legitimate IP addresses.
To circumvent the protections, last month the attackers added AS-16509 and the more specific /24 route to an AS-SET indexed in ALTDB, a free registry for autonomous systems to publish their BGP routing policies.
irrd.log-20220817.gz:31106306-descr: Quickhost set
irrd.log-20220817.gz:31106332 members: AS209243, AS16509
irrd.log-20220817.gz:31106392 – modified: crussell()quickhostuk net 20220816
irrd.log-20220817.gz:31106438 – Source: ALTDB
irrd.log-20220817.gz:31147560 – Route: 126.96.36.199/24
irrd.log-20220817.gz:31147606 – Origin: AS16509
irrd.log-20220817.gz:31147656 – modified: crussell()quickhostuk net 20220816
irrd.log-20220817.gz:31147702 – Source: ALTDB
An AS-SET is a registry entry that defines the allowed set of ASNs that a provider might encounter from that network.
Analyzing why the move failed to prevent last month’s hijacking, Madory noted that RPKI is intended to limit the impact of unintentional or accidental hijacking due to routing leaks or misconfigurations, and not as a security mechanism to prevent fraud prevent motivated attackers.
Besides that, it could still helped if the ROA were structured differently. As it stands, the ROA for the address space in question is pretty liberal. Basically, three different Amazon ASNs (16509, 8987, and 14618) can advertise all parts of this address space with prefixes ranging in size from /10 down to /24. Check out the Routinator web UI output:
An alternative approach to ROA creation would be to do what other networks like Cloudflare and Comcast have done: set the origin and maximum prefix length to be identical to how the prefix is routed. While this approach has an overhead cost, since an ROA must be updated each time a route is changed, it also leaves little room for alternative versions of the route to be circulated.
In fairness, Amazon is hardly the only cloud operator to lose control of its IP addresses in a BGP attack. BGP’s vulnerability to clumsy misconfigurations and outright fraud has been evident for more than two decades. Ultimately, uncertainty is an industry-wide problem that Amazon alone cannot solve.
But as a Tier 1 cloud provider that has now suffered at least two BGP hijackings that cost downstream users money, Amazon should be expected to acknowledge the event, explaining why it waited more than three hours, to take corrective action and a plan to prevent similar ones in the future. Rather than maintaining radio silence as has been the case for the past five weeks, Quickhostuk should also give an account of this incident and why it seems its ASN issued such a problematic announcement.