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.