Amazon recently lost control of the IP addresses it uses to host cloud services and took more than three hours to regain control, a lapse that allowed hackers to steal $235,000 in cryptocurrency from users of one of the affected customers. shows analysis.
The hackers took control of approximately 256 IP addresses through BGP hijacking, a form of attack that exploits known weaknesses in a core Internet protocol. Short for Border Gateway Protocol, BGP is a technical specification that traffic routing organizations known as Autonomous System Networks use to interact with other ASNs. Despite its crucial role in routing large amounts of data around the world in real time, BGP still largely relies on the Internet equivalent of word-of-mouth for organizations to track which IP addresses rightfully belong to which ASNs.
A case of mistaken identity
Last month, Autonomous System 209243, which belongs to the UK-based network operator Quickhost.uk, suddenly started announcing that its infrastructure was the right path for other ASNs to access what is known as the /24 block of IP addresses belonging to on AS16509, one of at least three ASNs operated by Amazon. The hijacked block included 220.127.116.11, an IP address hosting cbridge-prod2.celer.network, a subdomain responsible for serving a critical user interface for the Celer Bridge cryptocurrency exchange smart contract.
On August 17, attackers used the hijack to first obtain a TLS certificate for cbridge-prod2.celer.network, as they were able to demonstrate to the GoGetSSL certificate authority in Latvia that they had control over the subdomain. With the certificate in hand, the hijackers then host their own smart contract on the same domain and wait for visits from people trying to access Celer Bridge’s real cbridge-prod2.celer.network page.
Overall, the malicious contract drained a total of $234,866.65 from 32 accounts, according to this description from the Coinbase Threat Intelligence Team.
Coinbase team members explained:
The phishing contract closely resembles the official Celer Bridge contract, mimicking many of its attributes. For each method not explicitly defined in the phishing contract, it implements a proxy structure that redirects calls to the legitimate Celer Bridge contract. The proxy contract is unique to each chain and is configured at initialization. The command below illustrates the contents of the storage slot responsible for the proxy configuration of the phishing contract:
The phishing contract steals users’ funds using two approaches:
- All tokens accepted by phishing victims are drained using a custom method with a 4-byte value of 0x9c307de6()
- The phishing contract overrides the following methods designed to immediately steal the victim’s tokens:
- send() – used to steal tokens (eg USDC)
- sendNative() — used to steal native assets (eg ETH)
- addLiquidity()- used to steal tokens (eg USDC)
- addNativeLiquidity() — used to steal native assets (eg ETH)
Below is an example reverse-engineered snippet that redirects assets to the attacker’s wallet: