Althea Liquid Infrastructure - 0xlamide's results

Lines of code

https://github.com/thegamepro21/tcoin/blob/7d5f0498a2f8bc2eeac1a421ceb88deec3748202/LiquidInfrastructureERC20.sol#L127-L146

Vulnerability details

Impact

Attacker will recieve multiple disbursement in the distribute funtion with just one account.

Proof of Concept

This issue occures _beforeTokenTransfer() which checks if the balance of reciever is 0 and then add him to holders array https://github.com/code-423n4/2024-02-althea-liquid-infrastructure/blob/bd6ee47162368e1999a0a5b8b17b701347cf9a7d/liquid-infrastructure/contracts/LiquidInfrastructureERC20.sol#L127-L146 . The flaw is it does not check if the reciever is still a pre-existing holder (i.e part of the holder array) thereby duplicating the users address in the holder array. User can burn his token directly on the erc20 contract since the burn function is not overiden (reimplented) and still have his approveHolder set to true, and then he'll have another user send him dust tokens. He'll keep repeating the step and have his address duplicated multiple times in the holders array.

example

1. user burns his token balance directly on the tokem contract setting his balance to 0, and he is still an approved holder. (this will be called from the erc20 token contract)

2. he'll then have another holder send him dust token which duplicates his address to the holders array without checking if his address is already there before as seen there in _beforeTokenTransfer() https://github.com/thegamepro21/tcoin/blob/7d5f0498a2f8bc2eeac1a421ceb88deec3748202/LiquidInfrastructureERC20.sol#L142-L145

3 He then burns the dust token and repeat process.

Tools Used

Manual Review

Recommended Mitigation Steps

Consider reimplenting the burn function and adding check to remove the users from holder array if they burn all thier tokens

Assessed type

Context