EOS “Transaction Congestion Attack”: Attackers Could Paralyze EOS Network with Minimal Cost
On 01/10, blockchain security company PeckShield detected that EOS gambling game EOS.Win was targeted by a new type of transaction congestion attacks. Unlike past popular attacks exploiting contract layer issues such as random numbers or transaction rollback attacks, This type of attacks exploits lower level, blockchain layer vulnerabilities. Further analysis by PeckShield researchers found that, this is a blockchain layer denial-of-service loophole, and attackers could start large amount of deferred trash transactions to stop BP producing blocks with valid transactions, i.e., stop transactions from normal users going into blocks, and paralyze the EOS Mainnet.
PeckShield researchers have detected and reproduced this issue, and we believe this is the most critical denial-of-service loophole ever found on EOS network so far. Once exploited by hackers in a large scale, it could affect the normal operation of all DApps, especially gambling games with large amount of digital assets, and it could lead to huge asset loss and severely affect the further development of the EOS ecosystem.
Right after the issue was detected, PeckShield immediately notified the block.one team (CVE-2019–6199), and started to help on fixing the issue. Since attacks have already happened and the attack cost is minimal, here we’d like to call on the EOS community to pay more attention to this loophole and seek protection if needed, so to minimize the overall cost to the entire EOS ecosystem.
Transaction congestion attack details
Figure 1 shows the execution procedure of a typical EOS transaction. A user uses cleos client or other ways to send a transaction request to an API node, API node processes the request, and eventually the request reaches to a BP and is included into a block.
Figure 1: The execution procedure of a typical transaction
As a feature, EOS allows an user-signed transaction scheduling another deferred transaction (i.e., a transaction to be executed in the future). The problem is, deferred transactions (including trash transactions) are given priority over user-signed transactions allowing them to deny access to user-signed transactions. Specifically, when deferred transactions are scheduled, they would circumvent the API node and reach BP execution queue directly. Since they have higher priority than user-signed transactions, they would be processed before any user-signed transaction. Furthermore, if a deferred transactions schedule another deferred transaction, other BPs would likely pick up the deferred transaction again, as shown in Figure 2:
Figure 2: The execution flow of deferred transactions
Therefore, an attacker could, in a transaction, start large amount of deferred trash transactions, include dead loops in these deferred transactions to cause timeout, use up all the CPU time, and finally paralyze the EOS network.
Attack cost estimation
If the large amount of deferred transactions from the attacker all go onto EOS chain, it would cost huge CPU time from the attacker. But BP’s timed-out transactions don’t go onto EOS Mainnet, instead the transactions would be rolled back, so there is not cost of CPU time to the attacker. Although in reality, the CPU time is used up and normal transactions cannot be executed. At Current price of 50ms/EOS token, staking one EOS can block the EOS Mainnet several seconds, and the owner may get that EOS back after 24 hours. Therefore, with small amount of EOS tokens, an attacker can attack EOS Mainnet repeatedly and get those tokens back later, so her cost is close to zero.
Attack reproduction test
Based on the above analysis, we did a short confirmation test. Our test transactions included 100 and 300 deferred transactions, every deferred transaction would execute a dead loop til time out. Figure 3 shows the effect caused by the 300 deferred transactions:
From block 36981513 to 36981782, for a total of 269 blocks in a duration of 134 seconds, most blocks produced by BPs only include 0 to 2 transactions, only a few blocks have more transactions. The CPU cost were 4.82ms and 16.5ms for sending 100 and 300 deferred transactions. At the price of 50 ms/EOS, it only costs 0.4 EOS to complete a 300 deferred transactions attack. The CPU price varies from time to time, but it’s safe to say that the cost to paralyze the EOS Mainnet is minimal.
Figure 3: Blocks produced after our congestion attack
Potential risk and effect
Unlike the security issues in the contract layer, loopholes in the blockchain layer could affect every participants in the ecosystem, including BPs, DApp developers, and every users.
Recently, PeckShield introduced blockchain security product, DAppShield, which can analyze hackers’ attack signatures, and warn DApp developers and provide repair suggestions. EOS.Win was the first victim of this type of attacks, but the attacker could try the attack on all other DApps and inflict much more damage.
Mitigations
We reported the issue to block.one soon after we identified it. They finished the patch in one day, which was efficient and impressive. With the patch, the denial-of-service loophole is fixed by limiting the CPU time of processing pending deferred transactions in each block, which reserves some CPU time for user-signed transactions. Now, most of the BPs of EOS Mainnet have been patched. We would like to point out that DApp developers should keep in mind that they cannot rely on TXs to be delivered and the timing of the delivery is not absolutely predictable.
Timeline
About us
PeckShield Inc. is a 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.
