Detailed AirSwap Smart Contract Vulnerability: User assets can be maliciously eaten by attackers?

On September 13, 2019, the AirSwap team announced a fatal flaw in an AirSwap smart contract that could cause a user's assets to be stolen by the opponent in some cases. PeckShield security personnel independently analyzed the vulnerability. And communicated details and fixes with the AirSwap team.

Overview of vulnerability impact

PeckShield security personnel analyzed the AirSwap smart contract and found that the vulnerability only affected the recently launched Wrapper. The AirSwap team first rolled out the current contract after discovering the problem and rolled back the AirSwap website to the previously used contract. The entire process from contract launch to problem repair lasted only 24 hours, showing the AirSwap team's emphasis on contract security.

PeckShield security personnel independently analyzed the vulnerability details and communicated details and fixes to the AirSwap team, naming the vulnerability "ItchySwap."

PeckShield hereby reminds that because this vulnerability can cause users' assets to be maliciously stolen by attackers, there are 18 accounts affected by this, some of which have tens of thousands to hundreds of thousands of dollars of assets, these accounts need to be as soon as possible Complete the upgrade or contact the AirSwap team.

ItchySwap vulnerability detailed

First, AirSwap contract

Before the analysis, for the sake of convenience, we first define several concepts:

1. maker: the party that sells the assets;

• Monetary policy for cryptocurrency
• US stocks fell gold, bitcoin is farther away from “safe haven assets”
• Cook: Apple has no intention of pushing digital cryptocurrencies, hoping that trade barriers in Europe and the United States will return to normal.

2. taker: the party that purchased the asset;

3. order: an order for the delivery of the asset between the maker and theaker;

4. Indexer: The order book in AirSwap, which aggregates information about assets currently being sold and purchased.

The following figure illustrates the interaction process between maker, shiper, and Indexer:

AirSwap is an Ethereum-based peer-to-peer decentralized exchange that integrates the Swap Protocol as an automated hosting service that allows both sides of the transaction (ie, maker and the maker) to securely trade any asset on Ethereum. Unlike many decentralized exchanges, AirSwap does not have a custody control over funds, but there is still a centralized order book for matching purposes that implements a fully peer-to-peer model for trading and order matching.

In particular, there is an underlying service called Indexer that aggregates transaction intents from makers and takers and then provides them with matching services. In particular, once the bearer finds the right maker, they start negotiating the off-market price. Once the agreement is reached, the order will be filled and asset delivered by the Taker via the Swap Protocol.

In the AirSwap smart contract, taker processes the order winding and asset delivery in the AirSwap swap(Types.Order calldata _order) function. This function is implemented as follows:

1) Verify order validity

The order order parameter validity check, which is specified by the shipper when it is wound, also means that this information can be tampered with by the shiper, including:

1. The order is still valid;

2. The order has not been eaten by other tapers;

3. The order has not been cancelled;

4. The nonce of the order is greater than the minimum value;

5. Set the order status to TAKEN status.

2) Verify the taper information

Establish a valid shiper, according to the caller msg.sender specified in the order or equivalent to the contract.

3) Verify the maker information

To verify the validity of the maker, the verification here is divided into two cases:

1. An order without a maker signature: you need to ensure that msg.sender has permission to operate this maker address, that is, the order initiator has permission to operate the maker's assets;

2. The signature information of maker is specified in order: verify the validity of the signature.

4) Asset delivery

If there is no problem with the above verification process, then the asset delivery of maker and taker is executed directly.

Second, the Wrapper contract

In the AirSwap contract described above, the user performs asset swapping through the swap() function, which is very clear and has no problems. However, there is a slight imperfection in this contract. Users can only exchange assets through Token and cannot participate directly with ETH platform currency. Users can convert ETH to WETH first, then use WETH to participate in the exchange, but in any case, the user experience is one step further.

In order to reduce the user experience friction, the AirSwap team launched the Wrapper contract on September 12, 2019. The use of the Wrapper contract is to automatically convert the user-transferred ETH into WETH and then participate in the asset swap process. The key processes are as follows:

1. Verify that the swap() initiator is the same as the shiper;

2. If the user initiates swap() to carry the ETH asset and the token to be converted is WETH, then ETH is automatically converted to WETH;

3. Call the swap() operation of the AirSwap contract directly.

Considering a special scenario, Alice hopes to perform an AirSwap asset swap through a Wrapper contract. This process requires Alice to authorize the Wrapper contract in the AirSwap contract to allow the Wrapper contract to execute their respective asset delivery processes.

Due to the transparency of the blockchain, Eve saw Alice's authorized operations, so he could initiate a malicious order to the Wrapper contract with the following contents:

1. The effective time in order, nonce is a very large value;

2. The account corresponding to the maker in order is Alice's account number;

3. The shiper in order is empty;

4. The signature of order is empty.

Substituting the above constructed order into AirSwap's swap() function, where the two-step verification of 1,2 is controlled by theaker, there is no problem, let's focus on the third step to verify the maker information:

Since the AirSwap contract is invoked by the Wrapper contract at this time, msg.sender is the address of the Wrapper contract. As mentioned earlier, the Wrapper contract is authorized by Alice to directly control Alice's assets. Although Eve does not have permission to operate Alice's assets, But at this point, it can be controlled by Wrapper, which indirectly controls Alice's assets.

Safe avoidance

PeckShield security personnel analysis found that as of September 28, 2019, a total of six accounts had performed the revoke() operation to deauthorize the Wrapper contract, and 12 accounts had security risks. All remaining accounts. The revoke() operation should be performed immediately, or the assets in the account should be transferred to a secure account that has not been authorized by the Wrapper.

Any code should be fully tested and validated before it goes live, especially the DEX platform that carries user value. When adding new features to the product, it is important to consider the compatibility and security of the old features. The introduction of new features should not trigger the incomplete design of the old products.

appendix

Remarks:

AirSwap official vulnerability details (original) link: https://medium.com/fluidity/critical-vulnerability-in-a-new-airswap-smart-contract-c1204e04d7d3

We will continue to update Blocking; if you have any questions or suggestions, please contact us!