Infinite captured a new attack method on EOS DApp. An attacker with an account named fortherest12 attacked the EOS game Vegas town through a hard_fail state attack method, and caused a certain amount of losses.
Refer to the official documents, you can know that there are multiple execution states of EOS transactions, and the corresponding categories and corresponding descriptions are as follows:
- executed: The transaction was executed correctly without triggering the error handler
- soft_fail: The transaction failed objectively (not executed), but the error handler was triggered correctly
- hard_fail: The transaction failed objectively, but the error handler was not triggered
- delayed: the transaction is delayed/deferred/to be executed in the queue
- 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 it is impossible to query the relevant on the regular block browser. The transaction caused developers to lack awareness of this transaction status. The usual 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 project parties that use centralized lottery or exchanges and wallets that use centralized management, if the execution status of EOS transactions is not verified, there may be "false In the “recharge” attack, the attacker does not need to pay any cost, but can obtain a large amount of EOS. This is a brand-new attack technique, and it is also a point that everyone easily overlooks, but the harm it causes is huge.