Full Report
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!
Analysis Summary
# Vulnerability: Aurora Engine Permission Bypass Leading to Fee Manipulation
## CVE Details
- CVE ID: Not specified in the source material. (Reported as a critical vulnerability via Immunefi by a whitehat.)
- CVSS Score: Not specified in the source material. (Described as critical, leading to a significant bounty.)
- CWE: CWE-284 (Improper Access Control) / CWE-840 (Improper Neutralization of Input During Web Page Generation - *Applicable due to logic flaw/improper input bounds checks*)
## Affected Systems
- Products: Aurora Engine (EVM implementation on NEAR Protocol)
- Versions: Undisclosed specific vulnerable versions. (Identified and patched as of June 29, 2022.)
- Configurations: Any configuration utilizing the `receive_erc20_tokens` function logic responsible for handling NEP-141 to ERC20 token conversion and fee handling within the message parsing (`msg` field).
## Vulnerability Description
The flaw existed within the `receive_erc20_tokens` function, which processes incoming NEP-141 token transfers to convert them to ERC20 tokens on Aurora. The function parsed several fields, including a recipient address and a fee amount, from a user-supplied `msg` string within the transaction arguments (`args`).
The vulnerability stemmed from a **misunderstanding of permission boundaries**. An attacker could exploit this by:
1. Mapping an NEP-141 token to an ERC20 token (which was allowed for all users).
2. Initiating a NEP-141 transfer to a victim.
3. Crucially, specifying the *maximum possible fee* within the `msg` field intended for the message relayer (who was also controlled by the attacker, in this scenario the "owner of the bridge" setup).
4. This malicious structure forced the recipient (the victim) to pay the unintended maximum fee associated with the transfer back to the attacker's specified relayer due to flawed logic that did not correctly delineate who was obligated to pay the fee based on the transfer context.
This resulted in the attacker extracting **18.4 ETH** per exploited transfer from the victim.
## Exploitation
- Status: Successfully exploited in a simulated or controlled environment leading to the bounty payout. (The article implies it was disclosed before wide misuse, but the mechanism was proven effective, leading to a $1M bounty.)
- Complexity: Medium to High (Requires deep understanding of the token bridging/conversion logic, data structures like `NEP141FtOnTransferArgs`, and precise construction of the exploitative `msg` field).
- Attack Vector: Network (Transaction submission to the Aurora smart contract).
## Impact
- Confidentiality: None (Not directly impacted).
- Integrity: High (Unauthorized transfer of fees/ETH from users to the attacker).
- Availability: Low (No direct Denial of Service, but financial integrity threatened).
## Remediation
### Patches
- The fix involved **removing the entire functionality** that parsed the fee requirement from the user-supplied message (`msg`) field when processing the transfer, thus eliminating the source of the permission misunderstanding and fee manipulation. (Specific patch version is not provided.)
### Workarounds
- The most direct workaround was the removal of the vulnerable code path, as described above. No external temporary mitigation was detailed.
## Detection
- Indicators of Compromise: Transactions to the Aurora bridge function that involve unusually high fee allocations being diverted, or large transfers associated with the NEP-141 to ERC20 conversion logic where the recipient unexpectedly loses a significant fee portion.
- Detection methods and tools: Auditing transaction logs for anomalous fee structures within the `msg` payload passed to the relevant transfer handler function.
## References
- Vendor Advisories: Immunefi Disclosure Timeline (Reported June 10, 2022).
- Relevant links - defanged: hxxps://medium.com/immunefi/aurora-improper-input-sanitization-bugfix-review-a9376dac046f