ArkProject: NFT Bridge

Summary

When tokens are transferred (or "bridged") between the Ethereum network and Starknet, a unique identifier called a "hash" is generated from the details of the transaction request. However, there is currently no mechanism in place to check if this hash has already been used. This missing validation could potentially lead to a type of security threat known as a "replay attack," where an attacker could reuse the same hash to withdraw tokens multiple times, leading to unauthorized losses.

Vulnerability Details

The issue lies in the depositTokens function within the Solidity contract for the Ethereum bridge, and the deposit_tokens function in the Starknet bridge. These functions calculate a hash based on the transaction request data.

However, two critical oversights were identified:

1. Missing msg.sender in Hash Calculation: The hash does not take into account the address of the sender (msg.sender), which is a fundamental part of identifying who initiated the transaction. Without including msg.sender in the hash, it's possible for the same transaction data to produce the same hash, even if initiated by different users.

2. No Check for Reuse of Hash: There is no system in place to track whether a hash has already been used. This means that once a hash is generated, it could potentially be reused in subsequent transactions without being flagged as a duplicate.

These vulnerabilities open the door to a replay attack, where an attacker could generate the same hash more than once. By doing so, they might be able to withdraw tokens multiple times on the destination bridge, leading to unauthorized and repeated withdrawals.

Impact

The primary risk associated with this vulnerability is the potential unauthorized loss of tokens. This risk is particularly significant for ERC1155 tokens, which allow for multiple tokens to be managed under a single contract. In contrast, the risk appears to be less severe for ERC721 tokens, which represent unique assets, making it harder to exploit this vulnerability.

Tools Used

Manual Review

Recommendations

To mitigate the risk of a replay attack, the following steps are recommended:

1. Include msg.sender in the Hash Calculation: By incorporating the sender's address into the hash, each transaction would have a unique identifier, even if all other data remains the same. This would prevent different users from generating identical hashes.

2. Add a Check for Hash Reuse: Implement a validation mechanism that tracks whether a hash has already been used. If a hash has been used once, the system should prevent it from being used again in future transactions.