On 09/14, EOSPlay announced in their telegram account that they had noticed suspicious betting behavior and spikes of CPU usage on the EOS mainnet. Then, someone on Twitter reported that EOSPlay was attacked. PeckShield researchers analyzed the attack and found that it was a new type of transaction congestion attacks. Unlike the previous transaction congestion attack (CVE-2019-6199), this attacker rented large amounts of CPU from REX. Then, she created thousands of transactions to increase the price of CPU. As a result, most transactions signed by others were blocked because of lacks of CPU resource. Because of that, the EOSPlay’s random number generator was hacked resulting of about 30,000 EOS financial loss.


Figure 1: Announcement on EOSPlay Telegram

Details

EOSPlay uses the hash of a future block to compute its random number. In common scenarios, players do not know what transactions would be included in future blocks. So, it works fine. However, in the transaction congestion scenario, the attacker could manipulate future transactions and hack this mechanism.

Here is the timeline of this attack (UTC+8 time).

1) 09-14 02:47 The attacker began to test EOSPlay with 0.1~1 EOS.

2) 09-14 03:09 About 300 EOS used by the attacker to rent couple millions EOS equivalent CPU on EOSREX. The rate was equivalent to paying 0.00021 EOS for CPU resource worth of 1 EOS.

Figure 2: Attacker rented CPU on REX

3) 09-14 03:12 The attacker created lots of transactions to congest the EOSIO network.

4) 09/14 03:15 The attacker started getting tremendous payouts from EOSPlay with big bets.

5) 09/14 03:25 The CPU price raised to 3.125 EOS per ms. As illustrated in Figure 3 (provided by EOSPark), there are two spikes representing the two moments that the CPU resource reach extremely high price. The first spike occurred right at the time of EOSPlay hack. Four hours later, the attacker issued another congestion attack by sending lots transactions, which caused the second spike. According to this tweet, this attack was related to the gambling DApp Spinach.

Figure 3: CPU price between 09/14-09/16

6) 09/14 03:42 The attacker started transferring reward EOS to her sub-accounts: mumachayinm1, mumachayinm2, mumachayinm3, mumachayinm4, mumachayinm5, gotoworkhome.

7) 09/14 03:44 The attacker stopped betting to EOSPlay.

8) 09/14 03:51 EOSPlay suspended the smart contract at this transaction.

Figure 4: EOSPlay Suspended the Smart Contract

9) 09/14 22:37 EOSPlay re-deployed the smart contract at this transaction. In their announcement, the new random number generator will use the block hash as well. But, a private key would be used to sign the block hash such that the attacker cannot fabricate/predict the block hash.

Figure 5: EOSPlay Re-deployed the Smart Contract

In total, the attacker paid 211,694 EOS, received 240,480 EOS, and won 28,785 EOS as reward. Currently, most of the hacked EOS are parked at the gotoworkhome account.

Conclusion

This is a new type of transaction congestion attacks. Instead of scheduling lots of delayed transactions, the attacker rented large amounts of CPU from REX with a very low cost. Then, she can start a congestion attack by spamming lots of transactions. To mitigate this kind of attack, an EOS user can either stake more CPU or have spare accounts staking some backup CPU resource for her.

On the other hand, DApp developers should pay more attention on the random number generator mechanism. PeckShield researchers suggest developers to audit their smart contracts to avoid similar problems. Security is essential for DApp projects, therefore, before deploying smart contracts, make sure to contact security firms and conduct security audit.

About us

PeckShield Inc. is an industry leading blockchain security company with the goal of elevating the security, privacy, and usability of current blockchain ecosystem. For any business or media inquiries (including the need for smart contract auditing), please contact us at telegram, twitter, or email.



Published

16 September 2019

Tags