Be careful! Ethereum DeFi abuses authorization, your wallet may be stolen

Source: Bitpie Security Lab Original title: The biggest security risk in Ethereum DeFi ecosystem

DeFi is very popular, Compound is very hot, and the industry seems to be enthusiastically participating in this ecosystem. Innovation, revolution, and the day of ending centralization seem to be coming soon.

Oracles, smart contract wallets, decentralized lending, decentralized trading, decentralized blah blah…

Many practitioners in the blockchain industry have begun to optimistically believe that the golden building of DeFi has been basically completed.

01

However, there are still a few disturbing dark clouds floating in the clear sky of DeFi.

On April 18, 2020, Uniswap exposed a smart contract vulnerability, which was exploited to steal hundreds of thousands of dollars in assets;

On April 19, 2020, Lendf.me had tens of millions of dollars in assets stolen by a programmer (not a hacker) due to the same vulnerability.

These two incidents caused a stir 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 contact when problems arise?”

“After DeFi, does it mean that users will have to bear all the consequences of losing coins?”

Fortunately, the person who stole Lendf.me was just an ordinary programmer, not a professional hacker. He did not know how to hide his whereabouts. Because he leaked his IP and was further located, the programmer could only return the assets voluntarily to avoid legal punishment.

In this matter, the project owners and users of Lendf.me 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 is definitely a good thing to get the money back. But good things are good things, and the dark clouds hanging over the DeFi ecosystem have not dissipated. Is the future of DeFi still safe?

02

Regarding the security of smart contracts, many accidents have occurred in history. This dark cloud has always been there, and this is also the risk and challenge that the industry needs to continue to face.

But what we want to talk to you about today is another dark cloud. From a security perspective, the complexity of the other dark cloud is much lower, but its impact is more extensive - it affects almost every user involved in DeFi.

The impact is obviously serious, but it has been ignored by users and practitioners in the industry. This dark cloud is like a 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 up.

Today, we will systematically explain this dark cloud to you, and will also include a complete smart contract case to demonstrate the asset security risks that this dark cloud may cause to ordinary users. I believe that through this article, users will clearly realize that when you participate in the Ethereum DeFi ecosystem, many of the risks you inadvertently bring may not be that simple, and the risks involved can be so great that there is no upper limit.

Before we start the discussion, I would like to ask you a question:

Suppose you have 1 million Ethereum-based USDT, and now you decide to transfer 10,000 to a centralized exchange. If something goes wrong (for example, the exchange is hacked or the exchange owner runs away, etc.), what is your risk limit?

The answer is simple. The risk is only the 10,000 USDT you deposited. The remaining 990,000 USDT is in your wallet. Neither hackers nor exchange owners can do anything with this money. They can only steal the 10,000 USDT.

OK, now let’s apply the same scenario to DeFi:

Or suppose you have 1 million USDT, and now you decide to deposit 10,000 into a decentralized DeFi contract. If something goes wrong (the DeFi smart contract/project is hacked or the DeFi boss runs away), what is your risk limit?

Still 10,000? Wrong! Your current risk limit may have 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 hardware cold wallet that never touches the Internet and is absolutely safe, your million-dollar assets are very likely to be wiped out in an instant, BOOM!

Why is this the case? The reason lies in the most basic authorization model of the Ethereum ecosystem.

When you access a smart contract, the smart contract may ask you for authorization in order to "manipulate your assets more conveniently". What does this authorization call look like?

Now let’s take a look at an authorization transaction from the chain:

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 are the benefits 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 Ethereum mining fees, that is, you can still call this contract without ETH as mining fees.

The advantage of this authorization method is actually convenience (mainly for the project party). It is so convenient that you don’t even need to open your wallet to help you transfer coins.

“What? I can transfer coins without opening my wallet? Who can transfer my coins?”

This is the problem. As long as you authorize, the contract can control 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 sweep away all your coins.

Okay, now someone may say, although the contract can transfer my coins, 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 am I safe?

In fact, the security of contract authorization has little to do with whether it is open source or audited by a third party. Most (basically all) complex smart contracts in the current DeFi ecosystem can upgrade their codes. In other words, today's code may not be able to transfer your coins, but tomorrow the owner can maliciously update the code and wipe out all your coins.

(It should be noted here that the contract address will change after the contract code is upgraded. Therefore, if the Owner wants to transfer your coins, you will need to authorize again. However, considering that the authorization operation in each DeFi project and each wallet software is completed with one click, 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 looking at the example of 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 simulated a smart contract vulnerability. Suppose the contract developer accidentally set 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, real-life contract vulnerabilities can be complex and manifest themselves in a variety of ways, but what we want to point out here is that if a contract accidentally contains a vulnerability that allows a third party to use the assets of the authorizer, it will not only destroy the contract itself, but also the assets of all those who have authorized the contract will be stolen.

Someone might say, why don’t we just not write a loophole that can transfer authorized assets?

This is true, but it is almost impossible in reality. Countless vulnerabilities in the history of Ethereum have proved this point, but most of the vulnerabilities can only affect the assets in the contract or the execution method of the contract, while authorization-related vulnerabilities will endanger the security of all assets of all people who have authorized. Now you understand how big a risk you are taking, right?

Let's continue with 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. Before the upgrade, the claim method could only withdraw the balance of the token on the contract, but the developer modified it to be able to transfer the token authorized by the user. That is, after the update, when the user performs 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 cases and code for the above examples can be found in

https://github.com/bitpie-wallet/erc20-approve-issue-demo/blob/master/test/ExchangeDemo.test.js

You can see it on the website. Students who are interested can try it.

Through the smart contract samples of ExchangeDemo V1 and V2, we can see that due to abuse of authorization, even if the user has not transferred or only transferred a small amount of assets to the contract, if the contract has loopholes related to authorized transfers, the assets in all authorized user wallets will be at risk. Even if there are no loopholes, the contract developer has the power to take away all the assets in the authorized user's wallet after updating the code.

We can go a step further here. The purpose of a contract that asks you for unlimited authorization is obviously to facilitate the manipulation of your assets. The function of the contract itself will of course be related to the manipulation of your assets. Whether it is trading, lending, financial management, etc., assets must be manipulated.

Therefore, the contract itself will at least have relevant interfaces for currency transfer operations. Of course, these currency transfer operations are functional. For example, 50,000 USDT is deposited into the contract address for the purpose of mortgage, or 1,000 USDT is deposited into the contract address for the purpose of redemption. Now the problem is that since the contract itself has such interfaces, the contract owner may (here you need to look at the contract code) continue to use the same call to allow you to deposit more assets into the contract without your permission. In other words, even if the code is not upgraded or there are no related vulnerabilities, this possibility still exists, especially for contracts that can pay the Ethereum mining fee for you, which means that even the initiation review of the call may be the responsibility of the contract owner.

That is to say, if a smart contract has a method to transfer your one thousand yuan to the contract address after your authorization, it can naturally also use the same method to transfer ten thousand, one hundred thousand, or one million. After transferring to the contract address or other related addresses, the contract owner actually has the ability to take these assets away.

Here we need to explain that contracts like 0x have taken some precautions in this regard. They verify the user's signature when calling the interface, which means that at least they can ensure that the call operation is initiated by the user. But this actually depends on the writing method of the contract code. The contract code can verify the user's signature or the contract owner's signature. Of course, you can also verify nothing. The contract method can also be called by the user or by the contract owner. Different writing methods will give different roles the control of the coins in your wallet. Doesn't it sound scary?

Someone might say, if the owner of the smart contract does not do evil, then there won’t be this problem, right?

Here we have to explain one thing:

The first thing decentralization must do is to eliminate the need for third-party trust. If a decentralized project requires you to trust the contract owner, then what is the point of decentralization?

In addition, more importantly, you originally thought that the contract owner's influence on your assets was limited to the part in which you participated in the smart contract, such as the currency you transferred to dex for trading or to a decentralized lending contract for financial management. You thought the contract owner could only affect the part of the assets you deposited. Now you should understand that the contract owner can affect more than just this part. He can also affect the remaining assets in your wallet. Whether your wallet is hot or cold, it doesn't matter, it can all be mine.

Next, even if we assume that the contract owner is a morally perfect person, as smart contracts become more and more complex, it is well known that the risk of vulnerabilities is getting higher and higher. In the previous understanding, most people may think that if a vulnerability occurs, the main asset risk is still within the contract, and the attacker can at most take away all the coins you have in the contract. But the example in this article tells you such a fact, if the contract vulnerability happens to be related to authorized transfers, then the risk is spread, and all the addresses that have authorized the contract will be swept away. As long as the attacker scans which addresses have performed authorization operations, and then transfers all the coins on these addresses one by one.

More importantly, this also puts higher demands on how smart contract developers can safely keep the Owner key. If your Owner key is lost one day, it is not just the coins in the contract that will be lost, but all the assets in the wallets of all authorized users. Who can afford this?

03

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. In this case, there is nothing wrong with experimenting with various DeFi projects for the purpose of being a guinea pig. But if I tell you that the risk you take is all your assets, not just the coins you use to participate in DeFi, how would you feel?

There have been some voices in the blockchain industry about the abuse of authorization in the Ethereum ecosystem, but in fact it is far from enough. Whether it is developers, practitioners, users and other groups, 99.9% of people know nothing about it. Abuse of authorization is almost everything. It is time to change this situation.

Here we list some examples of projects that abuse the (unlimited) authorization:

Compound

Uniswap

Kyber

Maker

0x

Balancer

DX

EtherDelta

IDEX

imToken Tokenlon

The first few projects in the above list, such as Compound, Uniswap, and Kyber, are the hottest star projects in the current DeFi world, but these projects have all chosen to allow users to grant unlimited authorization to gain full control over user assets. In other words, as long as any user has used the above projects, the coins in your wallet may face the risks mentioned in this article at any time, which is actually a pity.

We screened a portion of addresses with unlimited authorization and found that most of them still have assets. Many of them have assets worth millions, tens of millions, or even hundreds of millions. The owners of these addresses have actually handed over the control of their assets to others without their knowledge.

The above contracts should adjust their authorization codes and change them to on-demand authorization. For example, if you only need to exchange 1,000 USDT, then only 1,000 USDT will be authorized. Any additional authorization is an unauthorized act.

Users who use these contracts should also change their DeFi contract usage behavior and put coins that do not participate in DeFi to another address that will not be authorized to any application to protect the security of their assets.

As the Ethereum ecosystem is evolving very quickly, we have designed an Ethereum Security Center in Bitpie. When you switch to the Ethereum system, you can see that we have developed a contract authorization detection function in the Ethereum Security Center. In addition to checking whether your address in Bitpie has any abuse of authorization, you can also check the current authorization status of any external address. For abused authorization, you can also perform authorization recovery operations.

Regarding Bitpie’s contract detection function, we will write a special article to guide you on how to use it. Is your address safe now? You will know after a test.

Speaking of widespread abuse of authorization, what does Bitpie do in this regard?

Taking 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 and will not generate any additional authorization.

For example, for Bitpie’s function of paying USDT mining fees, we did not use contract authorization at all. Even though it is obviously easier to implement using authorization, we did not do so. In fact, it is for this reason that the project party should put the rights and interests of users first, and any behavior that increases user risks should be resisted.

04

Considering the security under this dark cloud, what precautions should ordinary users take when participating in DeFi?

1. Regularly use the authorization scanning function provided in wallets such as Bitpie to see which contracts have obtained your authorization (unlimited authorization);

2. Use multiple Ethereum addresses to separate the coin storage address and the DeFi participation address, and put the coins used only for DeFi activities into the DeFi address . In this way, even if the sky is dark, the coins in the coin storage address are still safe;

3. Revoke 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.

05

Decentralized finance does represent the future and is also a very important application scenario of blockchain technology.

But what brings us together has never been earth-shaking concepts, profound and obscure codes, or fancy technologies, but has always been the belief in the sanctity and inviolability of private property .

Only it can keep us going until the clouds clear and the sun shines.