01
DeFi is very hot, Compound is very hot, and the industry seems to be participating in this ecology like a chicken blood. The day of innovation, revolution, and the end of centralization seems to be coming soon.
Oracle, smart contract wallet, decentralized lending, decentralized trading, decentralized blah blah…
Many practitioners in the blockchain industry are optimistic that the golden building of DeFi has been basically completed.
02
However, in the clear sky of DeFi, there are still a few disturbing dark clouds.
On April 18, 2020, Uniswap revealed a smart contract vulnerability, which was exploited to steal hundreds of thousands of dollars in assets;
On April 19, 2020, Lendf.me was stolen tens of millions of dollars in assets by a programmer (non-hacker) due to the same vulnerability;
These two incidents caused an uproar in the industry, especially the theft of Lendf.me, which triggered a wider discussion:
"Who should be held responsible?"
"It seems that after decentralization, it is difficult to tell who to call if there is a problem?"
"Is it true that after DeFi, the loss of coins must be borne by the user?"
Fortunately, because the person who stole Lendf.me is just an ordinary programmer, not a professional hacker - he doesn't know how to better hide his whereabouts. Because it leaked IP and was further located, the programmer could only voluntarily return the assets to avoid legal punishment.
In this matter, Lendf.me's project party and users can be said to be extremely lucky. They have avoided the risk of huge asset losses and lengthy legal proceedings. From the perspective of the industry, it must be a good thing to get it back. But good things are good things. The dark cloud over the DeFi ecology has not dissipated. Is the future of DeFi still safe?
03
Regarding the security of smart contracts, there have been many accidents in history. In fact, this dark cloud has always been there. This is also the risk and challenge that the industry needs to face all the time.
But what we’re going to talk to you about today is another dark cloud, which is much less complex from a security perspective, but has a wider impact — affecting almost every user involved in DeFi.
Its influence is obviously serious, but it has been ignored by users and practitioners in the industry. This dark cloud is like the sword of Damocles, hanging over the top of DeFi, whether you ignore it or not, it is always there, watching you quietly, waiting for the opportunity to swallow you.
As the first article after the establishment of the Bitpie Security Lab, we will systematically explain this dark cloud to everyone, and will also include a complete smart contract case to demonstrate the assets that this dark cloud may cause to ordinary users. Security Risk. I believe that through this article, users will be able to clearly realize that when you participate in the DeFi ecosystem of Ethereum, many of the risks caused by your inadvertent operations may not be so simple, and the risks can be so large that there is no upper limit.
Before we start the discussion, let me ask you a question:
Suppose you have 1 million USDT in ether, and now you decide to transfer 10,000 to a centralized exchange. If something goes wrong (like the exchange gets hacked or the owner of the exchange runs away, etc.), what is your risk limit?
The answer is simple, the risk is only the 10,000 USDT you deposit. The remaining 990,000 is in your wallet, and neither the hacker nor the exchange owner can do anything about this money. All they can steal is the 10,000.
Well, now the same scenario is put into DeFi:
Suppose you have 1 million USDT, and now you decide to deposit 10,000 USDT in a decentralized DeFi contract. If something goes wrong (the DeFi smart contract/project party is also hacked or the DeFi boss runs away), your What is the upper limit of risk?
Is it still 10,000? wrong! Your current risk limit is likely to become 1 million USDT, even if the remaining 990,000 USDT is still lying quietly in your wallet, and you can even carefully keep these USDT in a place that never touches the Internet, The same is true in the absolutely safe hardware cold wallet, your millions of assets are very likely to be wiped out in an instant, BOOM!
Why is this so? The reason lies in the most basic authorization model of the Ethereum ecosystem.
When you access a smart contract, the smart contract may apply to you for authorization for the purpose of "manipulating your assets more conveniently", so what does this authorization call look like?
Now let's find an authorized transaction from the chain and take a look:
https://etherscan.io/tx/0x419d17e216cda75dd9635a752e9aedb8f43ed4bfe31a6f75ed8923779c73eb6e
This transaction is very simple. In fact, the address [0x3693] authorizes the [Uniswap V2: Router 2] contract to use all its USDT unlimitedly.
So what's the benefit of doing this?
After completing this authorization operation, Uniswap can easily operate your assets, with fewer subsequent calls and fewer visits. Some contracts can even help you exchange the ether miner fee, that is to say, you can still call this contract without ETH for the miner fee.
The advantage of this authorization method is actually convenience (mainly for the project side), so convenient that you don’t even need to open your wallet to transfer money for you.
"What? Can I transfer coins without opening my wallet? Who can transfer my coins?"
This is the problem, as long as you authorize, the contract can govern all your assets without your permission. Remember, this has nothing to do with how your private key is kept, even if you keep your private key in a hardware cold wallet and freeze it in the refrigerator, the contract can still wipe out your coins.
Well, now it is estimated that some people will say, although the contract can transfer my coins, but if the smart contract code is open source, and has been audited by a third party, and there is no code to transfer my coins, then I am Isn't it safe?
In fact, the security related to contract authorization has little to do with whether it is open source or not and whether it has been audited by a third party. Now most (basically all) complex smart contracts in the DeFi ecosystem can be upgraded. That is to say, today The code may indeed not be able to transfer your coins, but tomorrow, Owner will do evil and update the code, and your coins will be swept away.
(It should be noted here that the contract address will change after the contract code is upgraded, so if the Owner wants to transfer your coins, you need to authorize again, but considering the authorization operation in each DeFi project and each wallet software It is all done with one click, so no matter how many versions of the code the contract Owner changes, users will not actually pay attention. Therefore, ordinary users still face the same risks.)
After reading the sample authorization transaction, let's now look at the sample code of a contract:
https://github.com/bitpie-wallet/erc20-approve-issue-demo/blob/master/contracts/ExchangeDemo.sol
In this example, we simulate the situation of a smart contract vulnerability, assuming that the contract developer accidentally sets the access control permission of the transfer method of the ExchangeDemo contract to public. In this case, as long as you authorize the contract, even if you have not performed any transfer operations on the contract, others can directly transfer all the Tokens in your wallet. It's that simple.
Of course, the contract loopholes in the real situation may be very complex, and the specific manifestations are also various, but here we want to explain that if a loophole that can be used by a third party to use the authorizer's assets is accidentally written in the contract, then It is not only the contract itself that is destroyed, but the assets of all those who have authorized the contract will be stolen.
Some people may say, then let's not write a loophole that can transfer authorized assets, right?
It's true, but in reality it's almost impossible. Countless loopholes in the history of Ethereum have proved this, but most loopholes can only affect the assets in the contract or can only affect the execution method of the contract, while authorization-related loopholes will endanger all those who have done authorization. The safety of all your assets, now you understand how much risk you are taking?
Let's move on to the next sample code:
https://github.com/bitpie-wallet/erc20-approve-issue-demo/blob/master/contracts/ExchangeDemoV2.sol
In this example, the contract developer upgraded the ExchangeDemo contract. The claim method before the upgrade could only withdraw the balance of the token on the contract, but the developer modified it to transfer the token authorized by the user, that is, after the update, the user After the authorization operation, the developer can easily call the claim method to transfer the coins in the user's wallet. It's that simple.
The complete test case and code in the above sample can be found in
https://github.com/bitpie-wallet/erc20-approve-issue-demo/blob/master/test/ExchangeDemo.test.js
See above, interested students can try it.
From the smart contract examples of ExchangeDemo V1 and V2, we can see that due to abuse of authorization, even if the user does not or only transfers a small amount of assets to the contract, if the contract has loopholes related to authorized transfer, all authorized transactions The assets in the user's wallet will be at risk. Even if there is no loophole, the contract developer has the right to update the code and take all the assets in the authorized user's wallet.
Here we can go further and talk about a contract that asks you for unlimited authorization. The purpose is obviously to easily manipulate your assets, and the function of the contract itself will of course be related to the manipulation of your assets, whether it is trading. , borrowing, financial management, etc., must manipulate assets.
Therefore, the contract itself will at least have relevant interfaces to perform currency transfer operations. Of course, this currency transfer operation is functional, such as depositing 50,000 USDT to the contract address for the purpose of mortgage, or depositing 50,000 USDT to the contract address for the purpose of exchange. Enter 1,000 USDT, well, the problem now is that since the contract itself has such an interface, it is possible for the contract Owner (here you need to see how the contract code is written) to continue to use the same call without your permission to let you go to More assets are stored in the contract, that is to say, even if the code is not upgraded or there are no related loopholes, this possibility exists, especially for the contract that can pay the ether miner fee for you, indicating that even the call Initiating an audit may be the responsibility of the contract Owner.
That is to say, if a smart contract can have a method to transfer your 1,000 yuan to the contract address after you authorize it, it can also use the same method to transfer 10,000, 100,000, 1 million, and then transfer it to the contract After the address or other related addresses, the contract Owner actually has the ability to take these assets.
Here we want to explain that contracts like 0x have taken some precautions at this point. They verify the user's signature when calling the interface, which means at least they can ensure that the calling operation is initiated by the user. But this is actually very dependent on the writing method of the contract code. The user signature can be verified in the contract code, and the signature of the contract Owner can also be verified. Of course, it can be verified at all. The contract method can also be called by the user or by the Called by the contract Owner, different ways of writing will give control of the coins in your wallet to different characters. Does it sound scary?
It is estimated that someone else has to say, if the owner of the smart contract does not do evil, won't this problem be eliminated?
Here we have to make a point:
The first thing to do in decentralization is to not need third-party trust. If a decentralized project requires you to trust the contract Owner, what is the point of decentralization?
In addition, more importantly, you originally thought that the impact of the contract Owner on your assets was limited to the part you participated in the smart contract, for example, you transferred to dex for trading and decentralized lending for financial management. The currency of the contract, you think that the contract owner can only affect the part of the assets you have deposited. Now you should understand that the contract owner can affect not only this part, but also the remaining assets in your wallet, whether you It doesn't matter if my wallet is hot or cold, it can be mine.
Then, even if we assume that the contract owner is a morally perfect person, as smart contracts become more and more complex, the risk of vulnerabilities is known to increase. In the previous understanding, most people may think that If there is a loophole, the main asset risk is still in the contract, and the attacker will at most take away all the coins you have in the contract. But the example in this article tells you the fact that if the contract vulnerability happens to be related to authorized transfers, the risk will spread, and all addresses that have been authorized to the contract will be swept away, as long as the attacker scans All those addresses have been authorized, and then all the coins on these addresses are transferred one by one.
More importantly, this also puts forward higher requirements for smart contract developers on how to safely keep the Owner key. If one day your Owner key is lost, it is not just the coins in the contract that will be ruined. What is over is all the assets in the wallets of all authorized users, who can afford this?
Seeing this, do you understand why the title of this article is "The biggest security risk in the Ethereum DeFi ecosystem"?
04
Since the abuse of authorization in the Ethereum ecosystem has reached a very serious level, we can even say that almost all DeFi contracts are asking for unlimited authorization without restraint. The behavior of the DeFi project itself is understandable, but if you are told that the risk you are taking is all your assets, not just the few coins you use to participate in DeFi, how should you feel?
There has been a little voice about the abuse of authorization in the blockchain industry before, but it is not enough. Whether it is developers, practitioners, users and other groups, 99.9% of people know nothing about it , the abuse of authorization is almost all, it is time to change this situation.
Here we list some examples of projects abusing authorization (unlimited):
Compound
Uniswap
Kyber
Maker
0x
Balancer
dYdX
EtherDelta
IDEX
imToken Tokenlon
The first few Compound, Uniswap, and Kyber in the above list are the hottest star projects in the current DeFi world, but these projects, without exception, choose to allow users unlimited authorization to gain full control of user assets, and also That is to say, as long as any user has used the above items, the coins in your wallet may face the risks mentioned in this article at any time, which is actually a pity.
We screened some of the infinitely authorized addresses and found that most of them still have assets, and many of them have assets in the millions, tens of millions or even billions of dollars, and the owners of these addresses have already Giving control of assets to others without their knowledge.
All of the above contracts should adjust their authorization code and change it to on-demand authorization. For example, if you only need to exchange 1,000 USDT, then only 1,000 USDT will be authorized, and the additional authorization required is an ultra vires act.
Users who use these contracts should also change their DeFi contract usage behavior, and should put coins that do not participate in DeFi to another address that will not be authorized to any application to protect their assets.
Due to the rapid development and evolution of the ether ecosystem, we have specially designed the ether security center in Bitpie, which can be seen when you switch to the ether system. Whether your address in Bitpie has any abuse of authorization, you can also check the current authorization status of any external address. For abused authorizations, authorization recovery operations can also be performed.
Regarding the contract detection function of Bitpie, we will write an explanation article to guide you how to use it. Is your address safe now? Check it out and you'll know.
Speaking of licensing being widely abused, how does Bitpie do this?
Take the commonly used batch transfer function in Bitpie wallet as an example, our approach is limited authorization, that is, if you need to transfer 100 USDT to 50 addresses, Bitpie will only authorize 100 USDT, not generate any additional authorizations.
For another example, for Bitpie’s function of paying USDT miners’ fees, we did not use contract authorization at all. Even if it was easier to implement using authorization, we didn’t do it. In fact, for this reason, the project party should The rights and interests of users are put in the first place, and any behavior that increases the risk of users should be resisted.
05
Considering the security under this dark cloud, what precautions should ordinary users take when participating in DeFi?
1. Regularly use the authorization scan function provided in wallets like Bitpie to see which contracts have obtained your authorization (unlimited authorization);
2. Use multiple Ethereum addresses, separate the deposit address and the DeFi address, and put the coins only used for DeFi activities in the DeFi address, so that even if the dark cloud is over, the coins in the deposit address are still safe;
3. Reclaim the authorization of some applications to reduce risks. At least you should know which applications can directly transfer the coins in your wallet without your permission;
4. Call on project parties not to abuse authorization and authorize on-demand to reduce user security risks.