Ironsidesec - Collison attack on l2CollectionAddress

[sherlock-admin3]

Ironsidesec

Medium

Collison attack on l2CollectionAddress

Summary

The L2 collection address for a BAYC on L1 can be predicted because of weak salt usage. So, before the creation of L2 collection address, the attacker can deploy a malicious contract and change the state to his favor (like allowance, mints, owner of IDs) and then self-destruct it. After that wait till someone locks up their BAYC on Rift above on L1, and then backrun on the next block to unlock it by calling returnFromThreshold on Rift below on L2.

The previous issues with similar bug had more harder way to collide because salt is chosen from input param, so they had to brute force. But here, the salt is L1 collection address. So salt to all famous NFT collections are the collection addresses itself.

Go look at the latest issues with similar weak salt issues. scroll below the comment and go to the bottom

Vulnerability Detail

Likelihood :
The feasibility, as well as detailed technique and hardware requirements of finding a collision, are sufficiently described in multiple references:

1: A past issue on Sherlock describing this attack.
2: EIP-3607, which rationale is this exact attack. The EIP is in final state.

The hashrate of the BTC network has reached 6 × 10 ** 20 hashes per second as of time of writing, taking only just 33 minutes to achieve 2^80 hashes. A fraction of this computing power will still easily find a collision in a reasonably short timeline.

Issue flow :

1. since on L1 we all know the BAYC collection address, so _l1CollectionAddress is known to all, which is used as a salt to deploy the L2 collection address using create 2 clone library.
2. So fuzz or use your compulaton power to deploy a bot contract on the same address L2 BAYC collection going to be created, and change the state that can extract maximum value and self-destruct the contract deployed there.
3. Then officially call thresholdCross from l1, to deploy the collection genuinely. The maximum extraction that can be done is, for example, to mint token 6800 to the attacker and so that he can lock it in L2 and release it on l1. Or choose to change the state in a way mint all the tokens from 8000 tpo 10k on his address as owner.
4. Then as soon as your 9999 is locked in L1 by a victim, this attacker can lock his 9999 on L2 (that he got by changing the slot by deploying a malicious BAYC contract due to weak salt and create2 usage). He can lock in L2 and release it on L1.

So, by the end, he got a BAYC 9999 on l1, by manipulating the storage of BAYC collection on l2.

https://github.com/sherlock-audit/2024-08-flayer/blob/0ec252cf9ef0f3470191dcf8318f6835f5ef688c/moongate/src/InfernalRiftBelow.sol#L77-L82

https://github.com/sherlock-audit/2024-08-flayer/blob/0ec252cf9ef0f3470191dcf8318f6835f5ef688c/moongate/src/InfernalRiftBelow.sol#L242-L280

InfernalRiftBelow.sol

80:     function l2AddressForL1Collection(address _l1CollectionAddress, bool _is1155) public view returns (address l2CollectionAddress_) {
81:  >>>    l2CollectionAddress_ = Clones.predictDeterministicAddress(
82:             _is1155 ? ERC1155_BRIDGABLE_IMPLEMENTATION : ERC721_BRIDGABLE_IMPLEMENTATION,
83:             bytes32(bytes20(_l1CollectionAddress))
84:         );
85:     }


138:     function thresholdCross(Package[] calldata packages, address recipient) external {
 ---- SNIP ----
152:         for (uint i; i < numPackages; ++i) {
153:             Package memory package = packages[i];
154: 
155:             address l2CollectionAddress;
156:             if (package.amounts[0] == 0) {
157:    >>>          l2CollectionAddress = _thresholdCross721(package, recipient);
158:             } else {
159:                 l2CollectionAddress = _thresholdCross1155(package, recipient);
160:             }
 ---- SNIP ----
163:         }
164:     }

167:     function _thresholdCross721(Package memory package, address recipient) internal returns (address l2CollectionAddress) {
168:         ERC721Bridgable l2Collection721;
169: 
170:         address l1CollectionAddress = package.collectionAddress;
171:  >>>    l2CollectionAddress = l2AddressForL1Collection(l1CollectionAddress, false);
172: 
173:         // If not yet deployed, deploy the L2 collection and set name/symbol/royalty
174:         if (!isDeployedOnL2(l1CollectionAddress, false)) {
175:  >>>        Clones.cloneDeterministic(ERC721_BRIDGABLE_IMPLEMENTATION, bytes32(bytes20(l1CollectionAddress)));
176: 
177:             // Check if we have an ERC721 or an ERC1155
178:  >>>        l2Collection721 = ERC721Bridgable(l2CollectionAddress);
179:             l2Collection721.initialize(package.name, package.symbol, package.royaltyBps, package.chainId, l1CollectionAddress);
180: 
181:             // Set the reverse mapping
182:             l1AddressForL2Collection[l2CollectionAddress] = l1CollectionAddress;
183:         }
184:         // Otherwise, our collection already exists and we can reference it directly
185:         else {
186:             l2Collection721 = ERC721Bridgable(l2CollectionAddress);
187:         }
 ---- SNIP ----
203:     }

Impact

Loss of funds (high value NFTs). So high impact and the likelihood is medium (only computation power is needed). So, Medium severity

Code Snippet

https://github.com/sherlock-audit/2024-08-flayer/blob/0ec252cf9ef0f3470191dcf8318f6835f5ef688c/moongate/src/InfernalRiftBelow.sol#L77-L82

https://github.com/sherlock-audit/2024-08-flayer/blob/0ec252cf9ef0f3470191dcf8318f6835f5ef688c/moongate/src/InfernalRiftBelow.sol#L242-L280

Tool used

Manual Review

Recommendation

Implement salt by hashing the encoded values like, block time, block number, user-supplied custom salt, also the L1 collection address and also the gas left() for more randomness. Or deploy with create1 instead of create2.