[Lines of code](https://github.com/code-423n4/2022-05-opensea-seaport/blob/4140473b1f85d0df602548ad260b1739ddd734a5/contracts/lib/Consideration.sol#L76-L84) # Vulnerability details ## Impact Conduits play an important role for the proper functioning of Seaport. Both offerers and fulfillers can elect to use the conduit contract to fulfill token transfers. The conduit contract also receives approvals from offerers and fulfillers in order to perform these transfers. The Seaport contract should be a valid channel for the conduit contract, as only valid channels can call the functions in the conduit contract to execute such token transfers. However, there is no check in the code base that the user provided conduitKey, fulfillerConduitKey or offererConduitKey derives to a proper conduit contract that is created by the official conduitController used in the constructor of the Seaport contract. This is very dangerous because token transfers are handled by the derived conduit contract (if used in lieu of direct transfer between the offerer and the fulfiller), and it could contain malicious implementation of the relevant token transfer functions, including not transferring tokens at all. The lack of verification on the conduit key and the conduit could invite scammers to list their items and trick fulfillers into entering transactions, causing loss of fulfillers’ funds to the benefit of the malicious offerers. It could also invite fulfillers to use malicious fulfillerConduitKey to receive offered items without actually paying the consideration items, harming offerers and benefitting the malicious fulfillers. This is a critical security vulnerability, as it could cause the loss of all user assets that are offered on the Seaport platform. ## Proof of Concept For basic orders, both offererConduitKey and fulfillerConduitKey are included in the struct BasicOrderParameters. The BasicOrderParameters is used as the input to the fulfillBasicOrder() function. Throughout the entire call stack of the _validateAndFulfillBasicOrder() function in the BasicOrderFulfiller contract, the conduitKey is taken as is, and is eventually used to derive the conduit address, and finally an external call to the derived conduit address is performed via the _callConduitUsingOffsets() function in the Executor contract. The signature verification only checks that the offerer has signed off on the order, but there’s no check anywhere that the derived conduit address is indeed a legit conduit address, created by the conduitController contract that is used in the constructor of the Seaport contract. For BasicOrderRouteType of ERC20_TO_ERC721 and ERC20_TO_ERC1155, a malicious offerer could deploy his own conduit contract, and use a conduitKey that would derive to the malicious conduit contract. A unsuspecting fulfiller sees the order, and would reasonably trust the Seaport protocol and not inspect the conduitKey that the offerer has included in the BasicOrderParameters, and call the fulfillBasicOrder() function, anticipating that the he would receive the offered item in return for providing the consideration item. The malicious conduit contract could simply return true for a successful call and the EIP-1271 magic value without actually transferring the offered item to the fulfiller. If the BasicOrderRouteType is ERC721_TO_ERC20 or ERC1155_TO_ERC20, the fulfiller conduitKey is used instead. A malicious fulfiller could deploy his own conduit contract, and use a conduitKey that would derive to the malicious conduit contract. Then the malicious fulfiller could call the fulfillBasicOrder() function, and the offerer’s ERC20 would be transferred to the fulfiller, without the fulfiller actually transferring the ERC721 or ERC1155 to the offerer, if the malicious conduit contract simply returns true for a successful call and the EIP-1271 magic value without actually transferring the item. For the advanced orders, several functions in the Consideration contract can be used, including fulfillOrder(), fulfillAdvancedOrder(), fulfillAvailableOrders(), and fulfillAvailableAdvancedOrders(). In these functions, the fulfillerConduitKey is used as a function input, and the Order and the AdvancedOrder structs contain OrderParameters which contains a conduitKey. We now trace the fulfillerConduitKey variable in the call stack. The fulfillerConduitKey is used in the _validateAndFulfillAdvancedOrder() function of the OrderFulfiller contract, which calls the _applyFractionsAndTransferEach() function, which calls the _transferConsiderationItem() function which is really the _transfer() function in the Executor contract. In the Executor contract, the _callConduitUsingOffsets() function is eventually called to derive the conduit address and call the conduit address. All that is needed is that the call is successful and the return value is the same as the EIP-1271 magic value, which a malicious conduit contract could easily pass without actually transferring any tokens. Again there is no check on the user provided fulfillerConduitKey variable to see if it derives to a legit conduit contract that corresponds to the conduitController used in the Seaport constructor. The exploit could therefore also happen in which a fulfiller uses a fulfillerConduitKey that derives to a malicious conduit contract, and receives the offerer items without actually paying the consideration items. Lastly, we trace the conduitKey variable in the OrderParameters for fulfilling advanced orders. Similar to transferring consideration items, the _transfer() function in the Executor contract is used, without checking if the conduitKey derives to a legit conduit contract that corresponds to the conduitController used in the Seaport constructor. Therefore, a malicious offerer could again trick a fulfiller into fulfilling advanced orders without actually transferring the offer items by using a malicious conduitKey. ## Tools Used Manual Review, Remix ## Recommended Mitigation Steps There should be a check that the conduitKey, offererConduitKey, and fulfillerConduitKey being provided and the derived conduit addresses are indeed legit conduit contract addresses. This could be done by using the _assertConduitExists() function of the ConduitController contract. As part of order verification, all the order fulfillment functions in the Consideration contract should include a call to the _assertConduitExists() function of the ConduitController contract to ensure that the derived conduit address is indeed created by the official ConduitController contract. --- The text was updated successfully, but these errors were encountered: All reactions