The solution Aurora has built as an EVM implementation on NEAR is called the Aurora Engine, and it is implemented as a smart contract on the NEAR blockchain. This allows for EVM compatible languages to be put on the chain, such as Solidity. It is just a layer 2 blockchain.
ERC20 is a standard for fungible tokens on the Ethereum blockchain. NEP-141 is an equivalent proposal to the ERC20 protocol. Since the NEAR is built on the EVM, ETH is the base currency. NEP-141 tokens are transferred to the EVM are converted into the equivalent ERC tokens then transferred back to the user.
The function responsible for doing this is receive_erc20_tokens takes a structure for &args. From the args, it parses takes out a msg field and validates the length. After this, the function parsers the recipients address out of the message to ensure its valid. It also checks if a fee that should be paid to the message relayer was also supplied in the message or not.
Finally, the function fetches the ERC20 that corresponds to the NEP-141 token. Once the function transfers the token, it checks to see if the receiver the needs to pay a fee.
So, what's the bug here? The flaw is within the logic of the application not considering permission boundaries.
-
Create a NEP-141 to ERC20 mapping. This is allowed by all users and doesn't pose any issues.
-
Transfer the NEP-141 token to the victim. When making this request, specify the maximum possible fee within the
args field. This gets send to the owner of the bridge, which we created ourselves.
-
Receive the funds from the recipient to their NEAR account.
In step 2, the transferring of the token to a user with a fee forces them to pay. This results in 18.4 ETH being transferred per exploit. The fix was simply removing this functionality entirely.
Overall, a fairly complex piece of functionality and a misunderstanding of permissions could have destroyed the platform. A million dollar bounty!