Aurora Mainnet experienced an attack yesterday. It was timely stopped. Vulnerability fixed for all virtual chains. The attacker stole $240. If you think $240 isn't much, just imagine 40 delicious Big Macs. 🧵
At 20:05 UTC August 7, fewnode2790.near starts experimenting with calling different system methods in Aurora contract. nearblocks.io/txns/BKJF8e6gw…
It looks like he roughly understands what he wants to achieve, but he struggles to line up required execution order and find correct payloads.
At 20:59 he still didn’t achieve anything, but now his intention is clear: he wants to set his prepared address (0x9b1218a9Aab6555E3F5A491d587bBc6CCA855026) as ERC-20 fallback address via calling `set_erc20_fallback_address` method. nearblocks.io/ru/txns/7NzNp1…
At 21:12 he finally succeeds. Even though there’s no harm done yet at this point, this already goes beyond what users should be allowed to do. nearblocks.io/ru/txns/CWZNyr…
At 21:18 attacker successfully executed `set_whitelist_status` to basically disallow all actions for non-whitelisted addresses. Because of this change, ERC-20 token transfers are not able to be processed; instead, funds are redirected to ERC-20 fallback address.
At this point attacker starts stealing user money during bridging actions.
The whitelist functionality is a feature of Aurora engine that allows to launch virtual chains with permissioned access. You can learn more about this and other features of Aurora Cloud at auroracloud.dev
Over the course of the next ~2 hours attacker gets his loot 12 times, resulting in ~$240. explorer.aurora.dev/address/0xFa84…
At the same time, Aurora Mainnet becomes nearly non-operational. Because of whitelist being enabled, most of the user transactions are failing with ERR_NOT_ALLOWED error.
At 21:32 - Infra SRE Team gets an alert from automatic end-to-end test suite, that effectively complains about Aurora Mainnet being non-operational.
At 22:02 core team joined the call, thrilled and excited to unveil the mysteries of this night. And at 22:45 - Aurora contract is paused by security council.
However, that doesn’t stop money from flowing into the villain's pocket. Nonetheless, it prevents him from viciously executing administrative methods.
Within the next hour the team comes up with the solution to the problem: set the whitelist admin, unpause the contract, disable whitelist and remove the erc20 fallback address => and executes it at 00:21. The normal work of a contract is restored.
At 00:25 attacker notices the loophole being closed, and funds his account from another account (0xD21d9B71a97ea085b62C555e62A4f97d01979a80) to start rescuing his loot: explorer.aurora.dev/tx/0xfc27fdee4…
Around 00:34 - 00:45 - attacker quickly withdraws stolen funds via Rainbow Bridge and @Uniswap: explorer.aurora.dev/address/0xFa84…
Through our & Meteor wallet infra we've collected a bunch of the information about the attacker. Addresses used: fewnode2790.near 0xFa84dd7B28a9140D4f3aD6ede3b2F70d5950F2E5 0x9b1218a9Aab6555E3F5A491d587bBc6CCA855026 0xD21d9B71a97ea085b62C555e62A4f97d01979a80 0x891083A23A484DA1Ff3c8d681F43F658601f2F74 0x4444588443C3a91288c5002483449Aba1054192b 0x4473472f285D46492a4A700C3a1A6b7569866549 IPs: 97.91.28.168 62.93.176.102 8.217.96.126 45.87.212.54 2600:1007:b016:db07:20a5:6803:dd66:a182 2a02:810a:14ab:9800:cd1a:19e3:4aaf:6abe User Agent: "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 YaBrowser/25.6.0.0 Safari/537.36"
We're asking all the teams who work in the blockchain security to add the information about the attacker addresses to their databases. ☝️ @trmlabs, @elliptic, @HypernativeLabs, @CrystalPlatform, @scorechain, @chainalysis, @GlobalLedger