Understanding the details of the EOS mortgage vulnerability in one article

In response to the EOS vulnerability issue some time ago, this article will review the overall details. I hope everyone will raise their security awareness, but don’t panic too much and look at security issues correctly.

1. Overview of the incident

In the early morning of June 22, the EOS official community announced that an EOS vulnerability was discovered, and the tokens pledged by users for voting could not be redeemed before the vulnerability was fixed. We then verified the vulnerability based on relevant information and confirmed that the vulnerability did exist, and that before the vulnerability was fixed, a carefully constructed attack caused specific users' assets to be pledged indefinitely and could not be redeemed.

We know that EOS uses the DPoS consensus mechanism, which maintains the EOS network through community voting to elect 21 super nodes, providing computing power, bandwidth and storage support for the EOS network. Users do not need to consume EOS to vote, but EOS will be locked. Users can apply to redeem the mortgaged EOS at any time, and the redemption will be received in 72 hours after the application. At the same time, the vote will be deducted.

This vulnerability occurred during the EOS redemption process. If other users pledged EOS to the redeeming user, the system would first re-pledge the EOS in the redemption process of the redeeming user. We already know that it takes 72 hours for the EOS applied for redemption to arrive. As mentioned above, through a carefully constructed attack, it is theoretically possible to make the designated user's assets pledged indefinitely, causing serious harm to the user.

2. Vulnerability Attack Process

1. Assume that the attacked user has 0.0005 EOS that is in the process of redemption.

2. At this time, the attacker pledges 0.0001 EOS to the redeeming user.

3. After the transaction took effect, we saw that the attacker’s balance did not change, while the 0.0001 EOS that the redeeming user was redeeming was forced to be pledged again.

3. Analysis of vulnerability principle

The attack commands in the attack flow chart are as follows:

cleos --wallet-url http://localhost:6666 --url http://mainnet.genereos.io:80 system delegatebw (attacker) (victim) "0.0001 EOS" "0.0000 EOS" --transfer

Because the attacker added the --transfer parameter when calling the command, the changbw function will be called when the mortgage function delegatebw is called, and transfer is true at this time

When the transfer variable is true, the from address becomes the address of the attacked object.

Next, the data of the attacked object was modified and EOS was pledged again.

4. Vulnerability Mitigation Solutions

Based on the above analysis, this article suggests modifying some business logic to mitigate and fix the mortgage vulnerability.

1. Regardless of whether the transfer parameter is true or not, it should be directly deducted from the balance of the mortgage initiator (the redemption process is not subject to this restriction);

2. Sort out the relevant business logic and check whether there are similar vulnerabilities.

Vulnerability Analysis Summary

Through the above analysis, a carefully constructed attack can cause specific user assets to be mortgaged indefinitely and cannot be redeemed. Patching the code using the mitigation measures can effectively mitigate and repair the vulnerability.