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 the Aurora contract.
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.
At 21:18, the 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 the ERC-20 fallback address.
At this point, the attacker starts stealing user money during bridging actions.
The whitelist functionality is a feature of the Aurora engine that allows launching virtual chains with permissioned access. You can learn more about this and other features of Aurora Cloud at
Over the course of the next ~2 hours, the attacker gets his loot 12 times, resulting in ~$240.
At the same time, Aurora Mainnet becomes nearly non-operational. Because of the 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, the core team joined the call, thrilled and excited to unveil the mysteries of this night. And at 22:45, the Aurora contract is paused by the 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 the whitelist, and remove the ERC20 fallback address => and executes it at 00:21.
The normal work of a contract is restored.
At 00:25, the attacker notices the loophole being closed and funds his account from another account (0xD21d9B71a97ea085b62C555e62A4f97d01979a80) to start rescuing his loot:
Around 00:34 - 00:45 - attacker quickly withdraws stolen funds via Rainbow Bridge and @uniswap:
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
Whilst other Aurora virtual chains were untouched we ensured that vulnerability was patched in less than 15 minutes across all 241 active instances.
Aurora Labs would compensate the stolen funds to all users.
The attacker was leaving lots of traces, including numerous reuse of addresses and there's a chance that one can trace the origin of his funds up to a centralised platform, thus allowing to recover his identity.
The low impact of the attack decreases our desire to invest in the investigation here and we are not continuing it with internal resources.
However, we would like to set up a bounty of 100 Big Macs for anyone who will trace the attacker up to the centralized entity and compose a document, so he can't get away. The evil should be punished.
I would like to thank the team of @auroraisnear for the prompt reaction to the problem. For some, the incident happened in the middle of the night. A fast reaction during the attacks is the most crucial thing to be able to limit the impact. đđđ
For everyone who's building contracts (especially complicated) please know: attacks will happen. It is your detection of the attacks that matters. Even the existing Aurora Bug Bounty didn't stop the attacker (but would certainly lead to a higher payout!).
Your infra should have e2e test for various cases and detection mechanisms of strange behaviours. It is a must. You cannot omit it, especially in the era of very capable AIs that can be used to find loopholes. I won't be surprised that this attack vector was discovered with AI.
Attack is a stress. The best thing that helps you deal with the stress is a prepared plan. Don't hesitate writing it down beforehand. You will be grateful for doing it.
Don't hesitate reaching out to professionals, especially when you really don't understand what's happening and you see that it is serious.
@_SEAL_Org is the place to go.
They helped us in previous (thankfully, false positive) instances.
4.41K
63
The content on this page is provided by third parties. Unless otherwise stated, OKX is not the author of the cited article(s) and does not claim any copyright in the materials. The content is provided for informational purposes only and does not represent the views of OKX. It is not intended to be an endorsement of any kind and should not be considered investment advice or a solicitation to buy or sell digital assets. To the extent generative AI is utilized to provide summaries or other information, such AI generated content may be inaccurate or inconsistent. Please read the linked article for more details and information. OKX is not responsible for content hosted on third party sites. Digital asset holdings, including stablecoins and NFTs, involve a high degree of risk and can fluctuate greatly. You should carefully consider whether trading or holding digital assets is suitable for you in light of your financial condition.