EIDOS Airdrop Stifles the Liveness of EOSIO Network
[Update: (2019-11-11) Bad actors started to exploit the
bidname function of the system contract for obtaining the airdrop without CPU cost.]
On 11/1, enumivo team announced on their website that they’re airdropping free EIDOS tokens if you send any amount of EOS to the EOS address eidosonecoin. This resulted in a mining mania for EIDOS right after the announcement was released for one week so far. Also, the CPU resource of EOSIO network was forced into the saturated state, in which users need to stake enough EOS to utilize the portion of CPU time based on the staked amount. PeckShield researchers monitored and analyzed the transactions on EOSIO network as well as the CPU rental mechanism based on REX by the time the airdrop started. Here’re some interesting findings we’ve got.
At 16:00pm 11/1 (UTC+8 time), we started a robot sending
0.0001 EOS to
eidosonecoin in an infinite loop for monitoring the mining mania.
The first thing came into our radar is that there’s not enough RAM in the
eidosonecoin account so that new miners cannot get into the ballpark.
Fortunately, the RAM crisis was resolved in around 10mins.
At around 16:30pm 11/1 (UTC+8 time), our robot ran out of CPU time.
As shown in Figure 2, the CPU price was raised to
0.2 ms per EOS.
It means you get only
200 us after staking
1 EOS but one typical EOS transfer takes more CPU time than that.
Moreover, the CPU price was raised to
0.1 ms per EOS two hours after the airdrop was launched.
Compared to the CPU price in last 4 weeks as shown in Figure 2, the price reached historical high in last 7 days.
The historical high CPU price dramatically affected the EOSIO network users.
As shown in Figure 3, the number of active users dropped from
80k to below
20k in one day (blue line).
We believe it was caused by the fact that the CPU price was not affordable to many users.
However, the number of transactions raised as shown in Figure 4. It looks a little bit weird here because we have fewer and fewer active users using the EOSIO network. After analyzing the actions in each transaction issued in that time period, we know that the minority of active users, EIDOS miners, worked really hard to send out as many as possible transactions, which used up most of the CPU time and indirectly kicked out normal users.
As shown in Figure 5, the actions related to EIDOS consumed
56% of all CPU consumption as of 11/6.
The unaffordable CPU price made users start to rent CPU/NET from REX instead of staking their EOS tokens.
In particular, the top 5 EIDOS miners rent millions of EOS equivalent CPU time for mining.
The secret is that those top miners
rentcpu before the airdrop started, which allows them to get much cheaper rental CPU (i.e.,
1 EOS can rent for
~3,000 EOS CPU time for 30 days).
Although they can rent CPU from REX, only few users know how to do it such that the miners and rich services providers were the only users on EOSIO network.
As shown in Figure 6, a CPU/NET renter needs to
deposit some EOS tokens into the REX fund before performing
This is somewhat complicated for normal users such that many of them cannot use the EOSIO network because of CPU crisis.
As more new miners started to
rentcpu, the rental CPU price raised to around
1 EOS for
That’s not a good sign for making profit from EIDOS mining.
The worse thing was that the REX system ran out of money for CPU/NET rental as well as
sellrex at 6pm 11/4 (UTC+8 time).
Figure 7 is a screenshot of running this command:
cleos system rex rentcpu myeosaccount myeosaccount '0.0001 EOS' '0.0000 EOS'
As programmed in the REX smart contract, the loanable EOS is calculated as follows：
available_unlent = total_unlent - 2 * total_lent / 10
It means all
rentcpu actions are suspended when around
83 % of the pool is consumed:
available_unlent = 16.66666666% pool - 2 * 83.33333333% pool / 10 = 0
We need some EOS whales to
deposit more EOS tokens into the pool to make the REX system function normally!
As most users were looking for cheap CPU resources, some bad actors started to exploit the CPU resources of DApps.
At 7pm 11/5 (UTC+8 time), the gambling DApp, BigGame, was first exploited since BigGame was one of the DApps which pay CPU resources for their players.
Specifically, the attacker hijacked the transfer receipt and embedded inline actions in the
Since BigGame pay for the CPU time, the attacker could deposit some EOS into BigGame for 0 CPU cost and hijack the transfer receipt sent by
eosio.token for embedding malicious inline actions.
The transfer receipt hijacking could actually happens in any EOS token transfer.
At 3am 11/7 (UTC+8 time), BetHash was attacked in an alternative way.
Specifically, BetHash has a dice game which allows players to guess the number from 0 to 100.
After each run of the dice game, the
dicereceipt() function of BetHash’s smart contract would be invoked to notify the player.
Therefore, a malicious player can hijack the notification and embed malicious inline actions.
But, she need to pay for the bets.
The interesting part is that the attacker kept putting
0.1 EOS bets on
under 97, which made her always get
0.1011 EOS back and successfully hijack the notification.
Figure 8 illustrates a successful attack.
Until 3pm 11/8 (UTC+8 time), not only BetHash, but also other dice games including EOSBet, EOSMMM, Trust-Dice, WinPlay etc. were attacked. For example, EOSBet was attacked by several players (e.g., hotsexygames, cyscyscys235, and juyhgdf1234u) continuously. After analyzing those transactions, we found that almost 38 seconds of CPU resource was exploited in EOSBet in last two days. Typically, a malicious transaction consumes 52 ms of CPU on average while a normal transaction only consumes 2 ms. Although EOSBet claimed that they would raised the bet amount to increase the cost of an attack, while the reality is that it’s under attack all the time. Figure 9 shows EOSBet CPU consumption which is always 100%.
Starting at 3am 11/11 (UTC+8 time), bad actors found that the
bidname function of the system contract,
eosio, could be exploited to obtain the airdrop without CPU cost.
This is how it works.
If you want to get a short account name, for example,
baaa, you place a bit greater than
0.0001 EOS to start.
When someone places a
10% or higher bid on that short account name, you’re overbidded and the
0.0001 EOS would be refunded.
eosio::bidrefund would be invoked by
eosio to send the refund back, which could be hijacked while notifying the receiver as mentioned earlier.
The worse thing is that
eosio account has unlimited CPU time.
This could make the EOSIO network run a heavy workload with no staked or rental CPU resource.
Figure 10 shows an attack transaction.
As an opinion from the community, this issue could be easily solved by raising the minimum bid price.
Right after the BetHash hack for embedding EIDOS mining actions, more and more DApps, DEXs, and even Exchanges were exploited or identified to have such issues. An ultimate solution is checking if the destination account is a smart contract before sending EOS tokens, notifications, etc. out. Unfortunately, there’s no such API for checking the state of an EOS account in the smart contract on EOSIO network. We suggest smart contract developers to use services such as DAppShield to filter out contract accounts.
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.