EOS fake deposit red alert details and repair plan

- Disclosure timeline -

• On March 10, 2019, we captured a new attack method on EOS DApp. An attacker with the account name forwardest12 attacked the EOS game Vegas town through the hard_fail state attack method and caused a certain amount of losses.

• On March 10, 2019, we noticed an increase in the number of hard_fail type attacks.

• On March 11, 2019, we disclosed the relevant attack methods, but did not disclose the specific details of the attack, and contacted the relevant exchanges and project parties in a timely manner.

• On March 12, 2019, we issued a red alert to remind exchanges and wallets that they need to verify the execution status of EOS transactions and suspend the deposit and withdrawal system if necessary.

• On March 13, 2019, the warning was responded to and recognized by core members of EOS New York and Block.one, including BM.

• On March 14, 2019, the details were officially released.

- Vulnerability Details -

Referring to the official documentation, we can know that there are many execution states of EOS transactions, and the corresponding categories and descriptions are:

Executed: The transaction was executed correctly and no error handler was triggered

soft_fail: The transaction objectively fails (not executed), but the error handler is correctly triggered

hard_fail: The transaction objectively failed, but the error handler was not triggered

delayed: The transaction is delayed/deferred/is in the queue for execution

expired: transaction expired

The attack method this time is to use the hard_fail state in the above state to attack. In the previous development process, many developers have never encountered this transaction execution state, and related transactions cannot be queried on conventional block browsers, resulting in developers' lack of understanding of this transaction state. The conventional thinking in development is that only contracts can initiate delayed transactions. However, the delay-sec parameter is configured through specific parameters in cleos:

Even if a non-contract account is used, delay transactions can be initiated normally. For DApp projects that use centralized lottery or exchanges and wallets that use centralized management, if the execution status of EOS transactions is not verified, "fake recharge" attacks may occur. Attackers do not need to pay any cost, but can obtain a large amount of EOS. This is a new attack method, and it is also a point that is very easy to ignore, but the harm caused is huge. For this method, we have captured real attacks and successfully prevented an attack with a loss of RMB 100 million and many huge losses. But unfortunately, there are still several successful attacks, which is beyond our ability. Our customers or partners are only a small part of this ecosystem.

Based on the above situation, we issued our red alert on March 12, but due to our inaccurate translation, it caused panic in the EOS community, causing the EOS community to mistakenly believe that this was an EOS vulnerability. We apologize for this. Some members of the EOS community believe that as long as exchanges and wallets do relevant checks, such problems will not occur. However, it is difficult for us to require all programmers to write code that follows the best security practices. When there is an inaccurate verification method, attacks will occur.

After our analysis, we are more inclined to believe that transaction status is a feature of EOS. In history, there have been many cases of "fake recharge" vulnerabilities related to this feature.

As we lead the disclosure:

• USDT Fake Transfer Security Risk Analysis

• Details of Ethereum token "fake recharge" vulnerability and repair plan

And we participate in the disclosure of:

• XRP official disclosure of fake deposit vulnerability and related analysis

These problems are not loopholes in the chain itself, but due to the characteristics of the chain itself and the developers' lax verification of such characteristics, attacks have occurred. This is why we issued a red alert. This is not intimidation (FUD), but more like an attack method that is easily overlooked. There have been no similar attack cases on EOS before with this type of attack method, but after we announced the relevant attack method, according to our joint EOSPark data analysis system, we found that more than a dozen accounts have begun to conduct attack tests on DApps, exchanges, and wallets. These accounts are:

bobukulabobu;cuancuan2323;testsuperdex;zhangjiayiba;justjiezhan1;wnze2qwdiyne

havls3k3iyge;ha11w4zzmpge;wkdoptxcjvdn;xmqukuailian;allosauruses;ccholr1ub2ku

walletthomas;fuckhakcer.x;johnwickteam;eosiotokenio;peospeospeos;eczpfezhvnrk;

And so on for other accounts.

There are many accounts that have successfully attacked. Therefore, we continue to issue follow-up warnings to remind relevant project parties to take preventive measures. In addition, the Twitter account Whale Alert has also paid attention to this type of attack. On March 11, the official account of Whale Alert tweeted that the account fuckhacker.x transferred 1 trillion EOS, which was later proved to be a fake transaction by the official. It can be seen that the scope of this attack is wide. It should be given enough attention.

-Repair plan-

For this type of transaction, the relevant project parties, exchanges and wallets need to verify the execution status of the EOS transfer to ensure that the transaction execution status is "executed". In addition, in the case of irreversible blocks, the following points must be achieved to prevent other types of "fake recharge" attacks.

• Determine whether the action is transfer

• Determine whether the contract account is the official contract account of eosio.token or other tokens

• Determine the token name and accuracy

• Judgment amount

• Determine whether to is the deposit account of your own platform

-PostscriptQ&A-

Q: Can turning on the read only mode on the node prevent this type of attack?

A: According to the official documentation on read only mode

After the node turns on the read only mode, it can query the online records and confirmed transactions. However, this type of attack method is to issue a defer transaction first. The defer transaction is a real transaction saved on the chain, and then the transaction will be transformed into a hard_fail. Therefore, turning on the read only mode cannot defend against this type of attack method. The status of the transaction is changed from delay to hard_fail, not rollback, which is something that needs to be noted.

Q: Why can’t I find the hard_fail transaction on other block browsers, such as EOSX?

A: The existing query transactions are queried through the EOS history plugin and implemented according to the code of the history plugin.

It can be found that except for executed and soft_fail transactions, other transactions cannot be queried.

Q：Can we avoid this kind of attack by using history plugin to obtain transactions?

A: It cannot be guaranteed. Different nodes have different implementations of history plugins. It is possible that the node provider modifies the history plugin implementation, resulting in the queried transactions having other states besides exectued and soft_fail.

Q: How should project platforms such as exchanges and wallets configure their own nodes to protect themselves from attacks?

A: Use the default history plugin configuration. In addition, check the transaction status of the EOS transfer to ensure that the transaction execution status is "executed". At the same time, you also need to judge the following points to prevent other types of "fake recharge":

• Determine whether the action is transfer

• Determine whether the contract account is the official contract account of eosio.token or other tokens

• Determine the token name and accuracy

• Judgment amount

• Determine whether to is the deposit account of your own platform

These points are all points where problems have occurred in history. We believe that the EOS ecosystem is a very powerful and flexible new ecosystem. Since the launch of the EOS mainnet, we have participated in many security emergencies. It is indeed challenging for developers to develop safely in this ecosystem. Security checks in all aspects are required to ensure that assets are not lost.

Conclusion

We hope that users in the EOS ecosystem who read this article will not imitate the attack methods in the article. We have no intention of causing panic in the EOS community. The SlowMist security team aims to bring more security to the EOS ecosystem and discloses the details of relevant security incidents in a timely manner in order to ensure the safety of more members in the EOS ecosystem. Relevant project parties should promptly ensure the security of the charging and withdrawal systems, implement corresponding risk control strategies, and ensure the safety of their own property.

Related reference How to monitor state with State History Plugin: https://developers.eos.io/eosio-nodeos/docs/how-to-monitor-state-with-state-history-plugin

The official document describes the three modes of nodeos: https://developers.eos.io/eosio-nodeos/docs/read-modes

USDT Fake Transfer Security Risk Analysis: https://mp.weixin.qq.com/s/CtAKLNe0MOKDyUFaod4_hw

Details of the Ethereum token "fake recharge" vulnerability and its repair plan: https://mp.weixin.qq.com/s/3cMbE6p_4qCdVLa4FNA5-A

XRP official disclosure of fake deposit vulnerability and related analysis: https://developers.ripple.com/partial-payments.html

EOS new attack method: hard_fail state attack: https://mp.weixin.qq.com/s/qsqqPB24fEjBgnq3Xr3xjQ

EOS Smart Contract Best Practices Guide:

https://github.com/slowmist/eos-smart-contract-security-best-practices

Acknowledgements

EOSPark; IMEOS; jerry@EOSlive wallet

(Author: SlowMist Security Team; Source: SlowMist Technology)