Signature Validation Bypass in Token Burn Operations Enables Unauthorized Token Destruction #114
Labels
invalid
This doesn't seem right
Comments
geaxed
added
invalid
|
Confusing and probably gpt generated, no value added |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Github username: @0xbrett8571
Twitter username: 0xbrett8571
Submission hash (on-chain): 0x822a41d01842f514f2f8ca872ee03c81abfabb3ec33e356dabcaee7e1da64295
Severity: medium
Description:
Description
USDE and InvestToken contracts implement a signature-based burn mechanism that contains a flaw in the validation sequence, allowing potential bypass of role-based access controls.
The issue is in the USDE.sol and InvestToken.sol contracts where the burn function can be called in two ways.
The vulnerability lies in the access control implementation where:
In USDE.sol#L126-L140
In InvestToken.sol#L149-L163
While the direct burn function properly checks for BURN_ROLE, the signature-verified burn function can bypass this check due to how the role verification is implemented.
Description: The burn functions in both USDE and InvestToken have access control vulnerability. The role check (onlyRole modifier) is performed before signature verification, allowing bypass of the BURN_ROLE requirement. An attacker could craft a valid signature without having the proper role permissions.
Impact
Attack Scenario
Think of it like a security checkpoint where they check your badge (BURN_ROLE) before checking if you have permission to access someone else's locker (signature). The correct sequence should verify ownership (signature) before allowing privileged actions (BURN_ROLE).
1. Initial Setup
• Alice holds 1000 USDE/InvestTokens
• Bob has the BURN_ROLE but should not be able to burn Alice's tokens without her consent
2. Attack Execution
• Bob identifies the validation sequence vulnerability in the
burn()functions• Bob crafts a signature using Alice's message parameters
• Bob uses his BURN_ROLE access to call
burn()with the crafted signature• The role check passes first due to Bob's BURN_ROLE
• The signature verification happens after the role check
• Bob successfully burns Alice's tokens without her authorization
3. Impact
• Alice's balance is reduced to 0
• The attack bypasses intended access controls
• Bob can repeat this for any token holder
We can see in the test traces show this flow, with both USDE and InvestToken contracts being vulnerable to the same attack pattern. The logs show Alice's balance going from 1000e18 to 0 through Bob's unauthorized burn operation.
Attachments
1. Proof of Concept (PoC) File
This POC both tests demonstrates how a validation sequence vulnerability, allowing an attacker with BURN_ROLE to bypass ownership controls and burn any user's tokens.
Logs
For USDE:
For InvestToken:
The traces show the exact sequence:
Role check passes (onlyRole modifier)
Signature verification occurs after role check
Tokens are burned without proper authorization
Revised Code File (Optional)
We can either
function burn( address from, uint256 amount, bytes32 h, bytes memory signature ) public returns (bool) { + require(hasRole(BURN_ROLE, msg.sender), "Missing burn role"); + require(msg.sender == from || hasRole(OPERATOR_ROLE, msg.sender), "Unauthorized"); require(from.isValidSignatureNow(h, signature), "Invalid signature"); _burn(from, amount); return true; }Or
function burn( address from, uint256 amount, bytes32 h, bytes memory signature ) public returns (bool) { + require(hasRole(BURN_ROLE, msg.sender), "Missing burn role"); + require(msg.sender == from || hasRole(OPERATOR_ROLE, msg.sender), "Unauthorized"); require(from.isValidSignatureNow(h, signature), "Invalid signature"); _burn(from, amount); return true; }The text was updated successfully, but these errors were encountered: