See the attached document [Report.pdf] for more information.

VeChain smart contracts are vulnerable to a form of replay exploit where an attacker uses a to-be-revoked approval to transfer VTHO Tokens to her own account twice. This attack is based on the ERC20 approve and transferFrom methods.

More specifically, someone (“A”), owning a total of X VTHO tokens, authorizes with a smart contract a third party (“B”) to transfer Y (with Y < X) VTHOs to another address. Later, A changes her mind and authorizes B for Z VTHOs (with Z < X and Y + Z ≤ X). B quickly (realistically: programmatically) notices this change and does two transfers. First, Y tokens based on the first approval, just before its revocation; then, Z tokens based on the second approval, as soon as it becomes effective. In the end, B gets Y + Z tokens where A only wanted to grant her Z tokens. The approved transfer is thus duplicated for the benefit of B.

See the attached document [Report.pdf] for more information.

1. As a victim, authorize an attacker's address to transfer at any time 100 VTHO tokens (contract method approve).
2. As an attacker, modify the VeChain source code in order to monitor the pending transactions (for example: txpool.go ~> func (pool *TxPool) Pending(sort bool) tx.Transactions), build it, and run the modified node. If a new approval to your address from the approver appears in a pending transaction, call (directly or not) the transferFrom contract method for the initial amount of VTHO tokens. Meanwhile, get the new value of the amount of tokens of the new approval and call again transferFrom for the new value once the new approval is registered on the blockchain.
3. As the victim, call the approve contract method, like the previous one, but this time for 50 tokens. Sign the transaction.
4. The attacker's node identifies the pending transaction, and calls transferFrom for 100 VTHOs. It prioritizes it on the network.
5. Once the second victim's approval is no more pending, the attacker call transferFrom for 50 VTHOs.
6. Victim has lost 150 VTHOs.

The attacker can remotely duplicate a third party authorization to steal VTHO Tokens.

See the attached document [Report.pdf] for more information.

Modify the ERC20 API to make the approver to automatically and temporarily approve for 0 token when she changes her mind about the number of tokens to be transferred on her behalf:

• First approval for X tokens.
• Second automatic approval for 0 tokens if the first approval is modified.
• Third approval for Y tokens.

Then, the attacker cannot use the second approval to steal the approver.

Attack Vector: Network ~> this attack is done remotely. Attack Complexity: High ~> the attacker must create a modified version of a VeChain node. But programmatically speaking this is not a complex task in this context. Privileges Required: None. User Interaction: Required ~> the attacker must convince the victim to contractually approve her beforehand. Scope: Unchanged. Confidentiality: Low ~> a restricted information is obtained: the pending change of will of the victim regarding the amount of VTHO to send. Integrity: High ~> the attacker can change the amount of VTHO that someone else owns. Availability: None. The victim's environment is not directly impacted.