Detailed disclosure and repair plan for the “False top-up” vulnerability in the Ethereum token

Disclosure Timeline

The “False top-up” vulnerability in the Ethereum token has a very wide influence. The affected objects include at least the following: Related centralized exchanges, centralized wallet, Ethereum token smart contracts, etc. For the single token smart contract, 3,619 of our incomplete statistics have the risk of “False top-up”, among which there are some famous tokens. The relevant project parties should check themselves as soon as possible. Because it’s not just a vulnerability, it’s a real attack! Due to the influence, we adopted a responsible disclosure process. The relevant timeline before and after the disclosure of this attack is as follows:

2018/6/28 SlowMist Zone intelligence, disclosure of the USDT “False top-up” vulnerability attack event

2018/7/1 SlowMist Security Team began to analyze whether there are similar problems in the well-known public chains.

2018/7/7 SlowMist Security Team captured and confirmed the vulnerability attack event for the “False top-up” in the related Ethereum.

2018/7/8 SlowMist Security Team analyzed the possibility that the impact of this attack might be greater than that of the USDT “False top-up” vulnerability attack, and promptly informed the relevant customers and the partners in the slow fog area.

2018/7/8 The first warning was sent by SlowMist Zone.

2018/7/10 SlowMist Security Team synchronously sent the details to at least 10 blockchain eco-security counterparts.

2018/7/11 The detailed report was officially released.

Vulnerability Details

Whether the status field in the Ethereum token transaction receipt is 0x1(true) or 0x0(false) depends on whether an exception is thrown during the transaction execution(such as using the require/assert/revert/throw mechanism etc.). When the user calls the transfer function of the token smart contract for transfer, if the transfer function is running normally and no exceptions are thrown, the status of the transaction is 0x1(true).

The code as shown in the figure, the transfer function of some token smart contracts is used to check the balance of the transfer originator (msg.sender) by if judgment way. When balances [msg. sender] < _value, to enter the else logic parts and return false. In the end, no exception of throwing. We think that the mild judgement of if/else only is an inexact coding method in transfer sensitive function scenarios. The transfer function of the most token contracts will adopt the mode of require/assert, as shown in the figure below:

When the condition is not satisfied, an exception is thrown directly, which interrupts the execution of subsequent instructions of the contract, or it can also be displayed by using the if/else + revert/throw function combination mechanism recommended by EIP 20, as shown in the figure below:

It’s hard for us to ask all programmers to write the best code for the security practices. This kind of inexact coding is a kind of security defect, which may lead to security problems in special scenarios. The attackers can use the defective token contract to initiate recharge operations to service platforms such as centralized exchanges and wallets. If the exchange only determines that the TxReceipt Status is success (that is, if the status mentioned above is 0x1(true)), it thinks that the coin has been successfully charged, there may be a “False top-up” vulnerability. As shown in figure:

Reference example TX

Sorry, We no longer make this tx public.

Repair scheme

In addition to judging transaction transaction success, you should also determine twice whether the balance of the loaded wallet address is accurately increased. In fact, this second judgment can be made through the Event log. Many central exchanges, wallets and other service platforms will get the transfer amount through the Event log so as to judge the accuracy of the transfer. However, it is important to pay special attention to the evil situation of contracts, because the Event can be written at will, which is instead of forcing the default untampered option:

emit Transfer (from, to, value); //value can be defined arbitrarily.

As a platform party, strict security audit should be carried out before the new online contract of tokens is connected. Such security audit must force the parties to implement the best security practice.

As a contract party, the code should strictly implement the best safety practice, and the third party occupational safety audit institutions should complete the rigorous and complete safety audit.

FAQ

Q: Why do we take this way of disclosure?

A:The essence is to run with an attacker, but the ecology is too big. Our strength can’t cover all of it. We can only cover it as far as we can. For example, we first inform our customers, then the customers of the slow foggy zone partners, and then the customers who pay attention to this ecological security colleague, and eventually have to show up the details.

Q: Why the disclose not just vulnerabilities, but attacks?

A: In fact, in our style, we usually don’t just mention vulnerability, vulnerability, which is too common for us. It’s not a good way to make a high-profile operation with vulnerability. Unlike an attack, which has already happened, we must race against the attacker. Disclosure is an art, and nothing is perfect. We can only do our best to make this ecology feel safe.

Q: At least 3,619 of them are at risk of a “False top-up” vulnerability. What should they do?

A: It’s a struggle. In general, the best way for these tokens is to reissue them and then “map” the old and new tokens. Because such tokens if you do not, like a “time bomb”, you can’t expect all centralized exchange, such as centralized wallet flat island’s docking can do a good job in security, once didn’t do a good job in this “False top-up” vulnerability judgment, the loss but the island’s. And if the platform side loses badly, it will certainly be a loss for the whole market.

Q: What famous tokens have “False top-up” vulnerability?

A: We will not make a name disclosure.

Q: How many exchanges and purses have been attacked by “False top-up” vulnerabilities?

A: I’m afraid no one will mention it publicly, nor will we call the roll.

Q: Is it possible for these tokens not to be reissued again?

A: Maybe, but it’s not perfect. The tokens that do not choose to reissue are either “mapping” soon after releasing the main network, or they have to inform all the platform providers who are connected to the token.

Q: Why can SlowMist capture such attacks?

A: We have a robust threat intelligence network. When we catch an exception, we default intuition that it is an attack.

Q: In addition to the USDT, the Ethereum token exists the risk of “False top-up” vulnerability, what other chains exist?

A: For the time being, no disclosure will be made, but believe us, the “False top-up” vulnerability has become a kind of vulnerability that cannot be ignored in the block chain ecology. This is an important step in the history of the slow fog security team’s discovery of vulnerabilities and attacks.