Direct theft of any user funds, whether at-rest or in-motion, other than unclaimed yield
Direct theft of any user NFTs, whether at-rest or in-motion, other than unclaimed royalties
Description
Thunder Exchange
Theft of Deposited Funds
Description
A critical vulnerability exists that enables a malicious actor to steal all deposited non-unique tokens (e.g., tokens following the ERC1155 standard) listed for sale.
Root Cause
As discussed in our Discord exchange, the Order.amount field was introduced to accommodate ERC1155-style tokens:
Hi! Yes, amount is added in case of Erc1155 style token standard
However, when updating a sell order, there is no validation to ensure that the order maker has deposited the required additional tokens into the exchange.
In the code snippet below, you can see that the update_order function does not check if additional tokens have been deposited when modifying an existing order:
This vulnerability permits an attacker to artificially increase the amount in an order, and subsequently invoke the cancel_order function.
As a result, the exchange sends the inflated number of tokens to the attacker, effectively enabling theft from legitimate users.
Proposed fix
To mitigate this issue, it is recommended to enforce the following during an order update:
Increase in Amount: Require the user to deposit additional tokens if the amount is increased.
Decrease in Amount: Refund the corresponding tokens to the user if the amount is decreased.
Proof of concept
Proof of Concept
Due to the relatively new nature of the Sway language and the limited availability of reliable testing tools, the proof of concept (PoC) is complex.
Below is a pseudo-PoC followed by a detailed actual PoC.
Pseudo POC
An innocent user creates a Sell Order for some Asset
The malicious actor creates a Sell Order for the same Asset
The malicious actor updates the Sell Order amount to include the innocent user's deposit (for example, innocent user deposited X tokens, the malicious actor deposited Y tokens, the malicious actor updates the Sell Order to be X + Y)
To create an actual PoC, some modifications to the protocol are necessary.
The protocol currently only allows addresses to interact, which is generally fine. However, when transferring coins in the Fuel ecosystem, a Variable Output needs to be added to the transaction — this isn't supported by the current Sway testing tools.
Since this vulnerability is unrelated to the nature of who interacts with the protocol, adjustments will be made to allow contracts to interact, enabling the PoC. These changes are strictly for testing purposes and do not affect the core issue.
Changes to the protocol for the POC
Add the following changes to the thunder_exchange contract:
// line 141 change from:let caller =get_msg_sender_address_or_panic();// change tolet caller =Address::from(get_msg_sender_contract_or_panic().bits()); // changed for POC/* ------------------------------------------------------------------------------------------------------ */// line 162 change from:Identity::Address(unwrapped_order.maker),// change toIdentity::ContractId(ContractId::from(unwrapped_order.maker.bits())), // changed for POC/* ------------------------------------------------------------------------------------------------------ */// line 324 change from:require(input.maker ==get_msg_sender_address_or_panic(), ThunderExchangeErrors::CallerMustBeMaker);// change to require(input.maker == Address::from(get_msg_sender_contract_or_panic().bits()), ThunderExchangeErrors::CallerMustBeMaker); // changed for POC
/* ------------------------------------------------------------------------------------------------------ */// line 352 change from:require(taker_order.taker ==get_msg_sender_address_or_panic(), ThunderExchangeErrors::CallerMustBeMaker);// change to require(taker_order.taker == Address::from(get_msg_sender_contract_or_panic().bits()), ThunderExchangeErrors::CallerMustBeMaker); // changed for POC
/* ------------------------------------------------------------------------------------------------------ */// line 388 change from:Identity::Address(order.taker),// change toIdentity::ContractId(ContractId::from(order.taker.bits())), // changed for POC/* ------------------------------------------------------------------------------------------------------ */// line 408 change from:Identity::Address(order.maker),// change toIdentity::ContractId(ContractId::from(order.maker.bits())), // changed for POC/* ------------------------------------------------------------------------------------------------------ */// line 454 change from:transfer(Identity::Address(to), payment_asset, final_seller_amount);// change to transfer(Identity::ContractId(ContractId::from(to.bits())), payment_asset, final_seller_amount); // changed for POC
/* ------------------------------------------------------------------------------------------------------ */// line 474 change from:Identity::Address(from),// change toIdentity::ContractId(ContractId::from(from.bits())), // changed for POC/* ------------------------------------------------------------------------------------------------------ */// line 508 change from:transfer(Identity::Address(to), payment_asset, final_seller_amount);// change to transfer(Identity::ContractId(ContractId::from(to.bits())), payment_asset, final_seller_amount); // changed for POC
/* ------------------------------------------------------------------------------------------------------ */// line 521 change from: pool.balance_of(Identity::Address(account), asset)// change to pool.balance_of(Identity::ContractId(ContractId::from(account.bits())), asset) // changed for POC
In addition, To make an MakerOrderInput Struct, we need to make the ExtraParams Struct public, so in the order_types.sw file, lets add a pub in line 37.
The tests files.
Create forc.toml in contracts-v1 and add the below in the forc.toml: