Details and Solutions for False Top-up Attack (hard_fail status attack) on EOS

by SlowMist Security Team

Timeline

March 10,2019, we captured a new tyep attack on EOS DApp. The attacking account fortherest12 attacked EOS Vegas town through the hard_fail status attack and caused some damage.

March 10,2019, we noticed that there are more hard_fail attacks appeared

March 11,2019, we disclosed the related attack method,but did not disclosed the specific details, and contacted relevant exchanges and project developers in a timely.

March 12, 2019, we released the Red Alert to remind the exchange and wallet that the EOS transaction execution status should verified and the deposit-withdraw system can be suspended if necessary.

March 13,2019, the Red Alert was responded to and recognized by core members of EOS such as EOS New York and BM.

March 14,2019, the SlowMist Security team officially disclosed all details.

Details Of Attack

Refer to the official documentation to know that there are many execution status of EOS transactions. The corresponding categories and corresponding descriptions as follow:

executed: The transaction has succeeded, no error handler was triggered.

soft_fail: The transaction failed objectively (not executed), but the error handler was triggered correctly.

hard_fail: The transaction failed objectively and did not trigger an error handler

delayed: The transaction is delayed/deferred/scheduled for future execution

expired: The transaction is expired and the storage space refunded to the user

This attack method is to use the hard_fail state to attack. Many developers have never encountered such a transaction execution status before, and can not get any informations in common blockchain browers,which cause the lack of knowledge of this transaction staus.The usual thinking in development is that only contract can call a delayed transaction, but we can call a delay transaction by setting a parameter in cleos.

Through delay-sec set in cleos, even normal account can call a delay transaction, centralized exchanges and wallets who did not check the status are under the risk of this attack, which would cause a “false top-up” attack. The attacker can get a lot of EOS without any cost.This is a new type attack,and was ingored easily and cause a huge damge. As to this type of attack, we have captured the real attack, and successfully prevented a loss of hundreds of millions of yuan unit of attack and many large losses,but unfortunately,there still several attack was successed,that is over our ability, the ecosystem of EOS is so large that our customers and partnert is just a little part of it.

Based on the above, we released the Red Alert in March 12. But the wrong mistranslation caused the FUD in EOS community. The EOS community mistakenly thought this was a Red Alert of EOS vulnerabilities. We sincerely apologize for this misunderstanding. Some members of the EOS community believe that such issues do not arise as long as the exchange and the wallet rigorously verify the transaction. Unfortunately, it is impractical to require all programmers to write the safest code in practice. Attacks can occur when someone uses a less rigorous verification method.

We perfer it as a features of EOS though our analysis,there have been a number of feature-related “false top-up” vulnerabilities in history.

As we have lead to disclosure:

-USDT “false top-up” and risk analysis

-Details of ETH ERC20 “false top-up” and related solutions

And disclosure we participation in:

-XRP offical discloure of “false top-up” and related analysis

Problems listed above does not the vulnerabilities of the chain itself, but more on their fetures, and the unprecise checks of developers cause the attack. That’s why we release Red Alert, we are not making FUD, it more like an attack method that is easily overlooked. This type of attack did not have the same attack case on EOS before, but there are lots of imitate attack after we disclosed the related analysis. Combined with EOSPark data analysis system,more than a dozen accounts have been tested for attacks on DApps, exchanges and wallets. These accounts include:

bobukulabobu

cuancuan2323

testsuperdex

zhangjiayiba

justjiezhan1

wnze2qwdiyne

havls3k3iyge

ha11w4zzmpge

wkdoptxcjvdn

xmqukuailian

allosauruses

ccholr1ub2ku

walletthomas

fuckhakcer.x

johnwickteam

eosiotokenio

peospeospeos

eczpfezhvnrk

and many other accounts. There are many accounts with successful attacks. As for this, we relased the following alert, keep alerting the related project parities to make the related defense. In addition, Whale Alert’s official account tweeted on March 11 that the account fuckhacker.x was transferring $1 trillion in EOS,and was proved to be a fake transaction in later time, which can be known that a large area was affected by this attack and should sure to make enough attention.

Solutions

For this type of transaction, projects, exchanges or wallets should verify the status of EOS transactions, make sure its status is “executed”. Moreover, we should make sure we have done the following checks to prevent “false top-up” happening again when block irreversibled.

1. Check if the action is “transfer”

2. Check if the contract account is an official contract for eosio.token or other tokens

3. Check the symbol and its accuracy

3. Check the amount

4. Check if “to” is to your platform deposit account

Q&A

Q: Do nodes open read only mode can avoid this type of attack?

A: According to the description to read only mode of official document,

nodes with read only mode opened can query online record and existed confirmed transactions. This type of attack first issue a defer transaction which is saved on chain as real confirmed transaction, and then will change to hard_fail. So open read only mode cannot avoid such attack. It is not roll back, which should be paid attention to.

Q: Why I cannot query hard_fail transactions in other block explorer such as EOSX?

A: Current transaction query is based on history plugin, according to the code of history plugin.

Except executed and soft_fail, other transactions cannot be queried.

Q:If using history plugin to get transaction can avoid this type of attack?

A: There is no guarantee cause different nodes may have different implements of history plugin. It is not excluded that node provider modify the implement of history plugin which results in other status except executed and soft_fail.

Q: How should exchanges and wallets configure their own node from attacks?

A: Use default configuration of history plugin, and check the EOS transaction status to make sure it is “executed”. Also check the following points in case of other types of “false top-up”:

1. Check if the action is “transfer”

2. Check if the contract account is an official contract for eosio.token or other tokens

3. Check the symbol and its accuracy

3. Check the amount

4. Check if “to” is to your platform deposit account

All these points are related to some issues before. EOS ecosystem is brand new and strong, we have participated in many security emergency events since mainnet launched. It is a challenge for developer to develop safety in this ecosystem, we should have security check is all aspects to ensure our assets safe.

Conclusion

First of all, we have no intention to cause FUD in the EOS community, and we sincerely hope that users in EOS ecosystem do not copy the attack methods mentioned in this article. SlowMist Security Team disclosed details of relevant security incidents timely for the purpose of bringing more sense of security to the EOS ecosystem, and aim to let more members have security assurance. All projects should ensure the safety of deposit and withdraw system, implement corresponding risk control strategy, to secure own property.

Reference

-How to monitor state with State History Plugin:

https://developers.eos.io/eosio-nodeos/docs/how-to-monitor-state-with-state-history-plugin

-Official document of 3 kinds of nodeos modes:

https://developers.eos.io/eosio-nodeos/docs/read-modes

-USDT “false top-up” and risk analysis:

https://mp.weixin.qq.com/s/CtAKLNe0MOKDyUFaod4_hw

-Details of ETH ERC20 “false top-up” and related solutions:

https://mp.weixin.qq.com/s/3cMbE6p_4qCdVLa4FNA5-A

-XRP offical disclosure of “false top-up” and related analysis:

https://developers.ripple.com/partial-payments.html

-hard_fail status attack from new attacking methods:

https://medium.com/@slowmist/hard-fail-status-attack-for-eos-7cfa73ae7d4b

-Best security guide for EOS Smart Contract Development:

--

--

--

Focuses on Blockchain Ecosystem Security, have served over 1k+ customers.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Don’t Ignore the Upcoming Trends of Electronic Signatures

Have Zombies Attacked You Yet?

Why do we need Confidential Computing?

PvP mode: Plant vs Undead updates its ban policy | English

HA-Infinity Stones Walkthrough

How to keep your smartphone safe from spying

How To Build A Website With Bluehost

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
SlowMist

SlowMist

Focuses on Blockchain Ecosystem Security, have served over 1k+ customers.

More from Medium

Lunaray Token Security Scan Report

Crypto Compliance Series| What is Peel Chain

Sorbet Finance Vulnerability Post Mortem

A New Era of State-Backed DeFi Blackhats Is Upon Us