#35707 [BC-Critical] Reusing old transaction receipt to rollback account balance
Submitted on Oct 4th 2024 at 04:43:18 UTC by @periniondon630 for Audit Comp | Shardeum: Core II
Report ID: #35707
Report Type: Blockchain/DLT
Report severity: Critical
Target: https://github.com/shardeum/shardus-core/tree/dev
Impacts:
Direct loss of funds
Description
Brief/Intro
Absence of transaction timestamp verification in the binary_repair_oos_accounts handler allows an attacker to reuse of old receipt to rollback account balance to a previous value.
Vulnerability Details
The binary_repair_oos_accounts P2P handler does not verify whether a transaction receipt has already been applied in the past. The timestamp is only checked in accountData, which is not signed by the consensus group. This oversight allows an attacker to use any old receipt for the same account to revert the account balance to its previous state after that receipt was initially applied. Consequently, the old receipt will be successfully pass verification, and the account update will be successfully propagated across the network.
Impact Details
An attacker can set the account balance to any previous value from old transaction receipts. The updated balance will be accepted as valid across the entire network.
References
https://github.com/shardeum/shardus-core/blob/23e06ded6744d8521cff9d749c1f1dd482c5fcb6/src/state-manager/AccountPatcher.ts#L490
Link to Proof of Concept
https://gist.github.com/periniondon630/39dc63dc1124e2975fd6efea732e4bbf
Proof of Concept
Apply the patch from the gist to the attacker's node, wait for it to become active, and then send two transactions from the same account (as shown in `poc.js` from the documentation). Also apply server_genesis.patch from documentation to shardeum repository. To launch the attack, run:
```bash curl http://ATTACKER_IP:ATTACKER_PORT/attack?accountId=e0291324263d7ec15fa3494bfdc1e902d8bd5d3d000000000000000000000000 ```
The exploit will roll back the account balance from the state after the second transaction to the balance after the first transaction by reusing the receipt from the first transaction. Run the attack only after you see the tx_removed message for both transactions in the output log.