Critical Vulnerability in a New AirSwap Smart Contract (Updated Oct. 3)

Published in

Fluidity

6 min readSep 13, 2019

Our team discovered a critical vulnerability in a new AirSwap smart contract. Read on to understand the steps we’ve taken to prevent the vulnerability from being exploited, and to determine whether you need to take immediate action.

Updated Oct. 3 with technical details below.

On September 12th, our internal security review processes identified a potential exploit in a newly released mainnet AirSwap smart contract. The vulnerability would allow an attacker, under certain conditions, to perform a swap without requiring a signature from a counterparty. The affected code was present in the AirSwap system for under 24 hours, and only affects some users of AirSwap Instant between midday September 11th and early morning of September 12th. We initially identified 20 vulnerable addresses matching this pattern and quickly reduced it to 10 accounts. As of October 3, there are only 5 accounts that remain affected.

When the issue was detected, the team immediately rolled back AirSwap Instant to use the original smart contracts. Both the AirSwap Instant and Trader products are no longer affected by the vulnerability.

The following accounts used the exploitable functionality during the vulnerable time period:

0x64ae361c1c55f61a02d2c67a4c78457d5169ac56
0x133acc82d6eaaec2a12e7547835219860551c570
0x2b13d1463b3821dd8a625e8935ab079251f1376d
0x669e01245cc4e8229d8c9cc753a4d14319877122
0xbd33caaedf06e436932522a9284d8312f325cae8

If your account is not listed, no action is required. If your address is listed, immediately visit https://authorizations.airswap.io/ to revoke authorizations for the vulnerable contract. Any new tokens deposited in the at-risk accounts above remain vulnerable to the exploit, and are not guaranteed safe, until authorizations are revoked.

Remediations

The following actions were taken by the AirSwap team immediately after discovering the vulnerability:

High-value user contacts: Immediately after discovering the vulnerability, the AirSwap team began to enumerate and identify all affected users who had used the vulnerable contract. One user was particularly vulnerable, with the vast majority (95%+) of affected funds. We were able to contact this user, who has provided product feedback in the past, via internal communication channels. This user’s funds were de-risked without alerting the user or other network actors to a potential vulnerability.
Modification of the AirSwap system: All vulnerable components and contracts were removed from the production AirSwap UI and related tools, and new addresses can only be exposed to the vulnerability if a user manually uses the affected, vulnerable contract.
Draining of at-risk funds: After de-risking the above user’s funds, the AirSwap team developed exploit code to proactively drain all vulnerable funds in the AirSwap contracts. If your account was drained by this script, your funds have been placed in a withdrawal contract available only to the account that held the original tokens. More information is below. AirSwap did not and does not currently hold custody of the funds.
Monitoring infrastructure: We are attempting to communicate with the remaining affected users towards the above actions. Note that this monitoring infrastructure is not a guarantee that funds are safe, as other users could potentially remove funds before our infrastructure detects this.Therefore, we strongly recommend any affected users immediately apply the above remediations.
Public communications: A public description as well as steps for remediation were released in this blog post. More technical details regarding the exploit will be released after we are confident that the probability of exploitation is low.
Evaluating security procedures: Smart contracts and decentralized finance remain a nascent, adversarial, and complex development environment. At AirSwap, we are strongly committed to providing the maximum possible security to our users. Towards this end, we have multiple internal security processes responsible for continuously reviewing both AirSwap’s overall threat surface and specific AirSwap artifacts for code security. It was one of these internal processes that originally discovered the exploit. Nonetheless, we recognize that our processes are imperfect, and will complete a full internal post-mortem analysis recommending changes to our security and deployment processes. We intend to require stricter standards for funds and authentication flow analysis in future internal reports, creating a rigorous process for evaluating these flows that prevents future authentication bugs. We also intend to weigh the benefits of installing centralized circuit-breakers to halt trading on any affected contracts until maximal confidence is achieved through automated verification or other techniques. We hope these analyses and changes will provide an even greater level of security for our users going forward.

Conclusion and what’s next

Smart contracts remain an exciting and new arena of software development, and require continued diligence and analysis to ensure defense against sophisticated and constantly-evolving attackers. We remain committed to a continuous security and monitoring process designed to identify vulnerabilities before they are openly discovered. We would like to deeply apologize to our affected users for any inconvenience these vulnerabilities may have caused, and hope that the important lessons we continue to learn throughout these processes form the basis for a more open, secure, and efficient trading environment.

Updated Oct. 3: Technical Details

This update is to provide more technical detail on the vulnerability, having given at-risk accounts two weeks to take protective actions by revoking their authorizations.

Two important notes:

the new Swap contract only supports swapping ERC20 tokens, not Ether.
the Wrapper contract was created so that traders can use their Ether (ETH) for Wrapped Ether (WETH) ERC20 trades.

The specific mechanism is an “authorization” feature that enables one peer to delegate swapping ability to another peer. In some scenarios, if the maker on an order has delegated to a peer that sends a transaction, a signature is not required.

For convenience, the new AirSwap smart contract system includes a “wrapper” contract that automatically wraps and unwraps ether (ETH) to and from “wrapped ether” (WETH). To use this feature, the user authorizes the Wrapper contract to swap on its behalf.

The vulnerability is an example of a flaw in authentication flows, believed to be the most common type of security vulnerability in production smart contracts today. Our team performed an internal security assessment to define invariants, write tests with full statement and branch coverage, and consider every possible angle of attack or disruption. Even with this, it was not until after deployment that this vulnerability was discovered.

The Wrapper contract now both requires that the message sender is the order taker, and that the order has a signature, which is then verified by the Swap contract.

Normal trading scenario

Under normal circumstances, every order requires a signature. In this sequence, Alice and Bob would both authorize the Wrapper on the Swap contract. Bob would then request an order from Alice and execute it through the Wrapper. An order with Alice’s signature would be returned to Bob. Bob would then provide the order to the Wrapper to swap. The signature would be deemed valid and the swap would complete.

Compromised trading scenario

In the compromised scenario, Bob does not need to request an order from Alice. Instead, Bob creates an order with Alice as the maker but without a signature. When Bob provides the order to the Wrapper, the swap will complete, because Alice has also authorized the Wrapper.

Alice is the victim, and Bob is the attacker.

Alice wants to use AirSwap Instant.
Alice Authorizes the Wrapper contract on the Swap contract.
Bob sees that Alice has authorized the Wrapper.
Bob constructs an order with Alice as the maker and Bob as the taker without a signature, and sends it to the Wrapper.
The Wrapper does not require a signature. Because Alice has authorized the Wrapper, the Swap contract does not require a signature.
The trade completes without Alice’s involvement and her funds are gone.

Due to the nature of the vulnerability Bob can monitor Alice’s wallet and drain funds at any time. This vulnerability is permanent until the Wrapper authorization is revoked. We implore any of the remaining at-risk accounts above to revoke your authorization.

Future updates

We are constantly monitoring the remaining accounts and will update this post with further details if they emerge. If you discover any potential issues going forward please reach us at bounty@airswap.io.

About AirSwap

AirSwap enables peer-to-peer trading on the Ethereum blockchain. Built on a decentralized protocol, traders can add or remove liquidity through a suite of trustless products that are easy to use and free. Our mission is to empower the world with frictionless trade.