The biggest security risk of the Ethereum DeFi ecosystem
DeFi is hot and exciting. Recently a large number of users have poured into Ethereum’s DeFi project. They have begun to participate either out of their optimism about DeFi or the pursuit of revenue from yield farming. Decentralized lending, DEX, oracles, synthetic assets, innovations continue to emerge. These projects connect and form a DeFi universe through a combination of building blocks. However, before the DeFi universe truly matures, there is a huge obstacle to be overcome — crypto asset security.
On April 18, 2020, 300K$ was drained from Uniswap by a hacker because of a contract compatibility issue; on the next day, 25 Million US$ worth of assets were stolen from Lendf.me due to the same type issue and shock the entire crypto world. This is only a small part of the DeFi smart contract vulnerability incident. What’s worse is that smart contract vulnerabilities are only a small part of DeFi security vulnerabilities.
Today we want to discuss another security issue in the DeFi world. This hidden danger is not as complicated as code vulnerabilities in smart contract, but its impact is very extensive and has been ignored by users and practitioners in the DeFi world. And one day, this hidden danger may cause a security incident far more serious than the loss of assets in the contract.
As the first research article of Bitpie Security Lab, this article will try to analyze this security issue and demonstrate the potential asset loss to users could be caused by two smart-contract demo cases. We hope to remind the DeFi users that many operations can be very risky when using Ethereum’s DeFi application.
We all know that in the crypto world, assets in non-custodial wallets are the safest. If a user has 1 million USDT in his wallet and he transferred 10,000 USDT to an exchange, he only needs to worry about that 10,000 USDT because rest 990,000 USDT are under his control. But in the world of DeFi, there is one action that could put all assets in the user’s wallet at risk of loss — Authorization (Approve).
Users who have used any DeFi contract might be familiar with authorization (Approve). When users use ERC20 tokens to interact with Ethereum smart contracts, they must first click “approve” (or “activate”) to make an authorization. Taking USDT as an example, authorization is to tell the USDT Token contract that in the future this approved smart contract (such as Compound) is allowed to transfer a certain amount of USDT from the user’s account.
In a word, the approved smart contract could have the ability to transfer assets from the user account without further user’s consent.
Let’s take a look at an authorization:
https://etherscan.io/tx/0x419d17e216cda75dd9635a752e9aedb8f43ed4bfe31a6f75ed8923779c73eb6e
This transaction is very simple. The address 0x369378f65bea… authorizes the “Uniswap V2: Router 2” contract account to spend unlimited USDT from the user account. The advantage of asking unlimited authorization is that Uniswap does not need to ask authorization in the future, which can improve the user experience and save some miner fees. Since then, the USDT in the user’s wallet is not only under users’ control but also the Uniswap contract can transfer all USDT as well because of the unlimited allowance from the user.
Most of the smart contracts are open-sourced and code has been audited by a third party. In most cases, there is no code or vulnerability for malicious transfer of user tokens, but this does not mean 100% safe. The code of the smart contract can be upgraded from no vulnerability to code containing vulnerabilities and exposures. Although users need to re-authorize after the upgrade, it is clear that no one will carefully check the updated code before re-authorizing it.
The following link is a sample code of smart contract:
https://github.com/bitpie-wallet/erc20-approve-issue-demo/blob/master/contracts/ExchangeDemo.sol
In this example, we simulated a smart contract vulnerability. Suppose the contract developer accidentally set the access control permission in the “transfer” method of the “ExchangeDemo” contract to the public. In this case, as long as the user authorizes the contract, hackers can directly transfer the token out from the user’s wallet.
Demo V2
https://github.com/bitpie-wallet/erc20-approve-issue-demo/blob/master/contracts/ExchangeDemoV2.sol
Following the previous example, the contract developer upgraded the “ExchangeDemo” contract. The “claim” method before the upgrade could only withdraw tokens from the smart contract address. After the developer modified the contract and gave it the ability to transfer the token authorized to the contract address by the user. Now the contact owner can call the “claim” method to transfer the maximum amount of token from the user’s wallet address.
The complete test cases and code in the above sample can be found on https://github.com/bitpie-wallet/erc20-approve-issue-demo/blob/master/test/ExchangeDemo.test.js.
Even if the contract code is not updated, many smart contract owners can transfer assets from addresses who gave them token allowance because of a lack of protection mechanism. We found 0x has a mechanism to check user signature before trigger token transfer which is a very good design. But a lot of contracts do not perform user signature verification as 0x did. For example, some contracts for paying miners’ fees for users can directly transfer user assets without the user’s consent. Once the owner of the contract acts badly or the owner key is obtained by a hacker, the consequences will be disastrous.
The example demonstrates the fact that if a contract has vulnerabilities that are related to unlimited allowance, or the contract Owner key is stolen, then it is possible that all addresses who have interacted with that small contract will lose their assets and this will far exceed the common loss within the contract. That is why we think it is “ The biggest security risk of the Ethereum Defi ecosystem “.
At present, the abuse of authorization (unlimited allowance) by DApp/DeFi developers of Ethereum has reached a very serious level. Although ZenGo has created a new word “baDAPProve”, the community had little discussions on the abuse of authorization, and most of the developers and users don’t care about it. It’s time to make changes.
Here we list some DApp that ask users for unlimited allowance:
Compound
Uniswap
Kyber
Maker
0x
Balancer
dYdX
EtherDelta
IDEX
imToken Tokenlon
Most of the popular DeFi projects are listed here and this is only a tip of the iceberg. All the above contracts should adjust their authorization code and change it to on-demand authorization. For example, if the user needs to exchange 1000USDT, only 1000 USDT should be authorized.
To help users understand and manage authorization, we have developed an allowance management tool in Bitpie Wallet which can be found on the Ethereum page. It will indicate if the current address has an unlimited allowance, and provides a method to revoke allowance. We also include the feature to check the allowance status of any Ethereum address created by other wallets.
We will have a more detailed tutorial article to guide users on how to use and manage their allowance authorization. Everyone who has used DeFi/DApp is highly recommended to check all their accounts and make necessary moves to keep assets safe.
As a wallet, Bitpie uses smart contracts for some advanced features, such as batch sending which are popular among our users. Our approach is to strictly limit the token allowance amount. For example, if a user needs to transfer 100 USDT to 50 addresses using our batch sending contract, we will only ask for 100 USDT approval, so that the allowance goes to zero automatically after the user’s transfer. Our other popular feature — USDT miners’ fees helper(help users who have not enough ETH in their address to send out USDT) does not use smart contracts, but a more complex technical model instead, the purpose is not to abuse authorization.
Regarding the abuse of authorization issue, Bitpie Security Lab has the following suggestions for users:
1. Use the Bitpie allowance management tools regularly to check your allowance status.
2. Revoke unnecessary allowance to reduce risks.
3. Use dedicated addresses for DeFi, and do not keep assets in that address if you don’t need them in DeFi. Keep your major assets in a clean address to avoid risk. Bitpie’s multiple Ethereum addresses model may help you.
4. Talk to the project team and tell them to stop asking for an unlimited allowance.
DeFi has a bright future, the DeFi universe will continue to grow and eventually form a parallel financial world, and bringing borderless finance to all mankind. Before that happens, we should pay more attention to the security issues of the DeFi world, and work together to eliminate hidden risks in the early stage and embrace the new era.
Bitpie Security Lab
