This year has seen an epidemic of cryptocurrency scams, with the teams behind them claiming to be hacked. It is hard to prove with complete certainty that these were exit scams from the get-go but they certainly follow a common pattern that would lead us to question whether incompetence alone is a sufficient explanation for their failure to prevent proxy smart contract exploits that have been discussed since 2018, 2019, and even in a paper published last October.
In January, before the $PAID token ‘hack,’ its vulnerability was publicly known: “The owner can mint tokens and did mint tokens to fresh wallets who never bought the presale. Contract is behind a proxy.” ‘Behind a proxy’ means that the functions (that carry out transactions) of the smart contracts are accessed, or ‘called’, through a proxy. Also the upgradable proxy can be ‘updated’, for example by adding new functions in the proxy.
Although the functions of the smart contract themselves can not be changed, using certain exploits (discussed below), function calls to the original smart contract can be diverted to malicious functions within the proxy. Thus, you should never trust a proxy blindly even if it points to a trusted implementation because it may still be able to direct you to malicious implementations or be updated to do so in the future.
It is hard to believe that platforms such as Meerkat, Furucombo, IYF & PAID, DODODex were hacked because even if the developer was not behind the rug-pull, he/she certainly made sure that the code was vulnerable to it by implementing his smart contract behind an upgradeable proxy. It is safe to assume that if the developer had the foresight to implement this complex Ethereum proxy mechanism for future bug-fixing or updating his platform, then he/she would also have the wherewithal to take measures to protect his/her private key that allows access to upgrading the proxy. At the very least, therefore, these appear to have been ‘exploit-tests.’
All of the attacks on platforms involved updating the deployer’s smart contract by leveraging the upgradeability mechanism offered by proxy pattern smart contracts (explained here). Without multi-signature contract control, the attacker can use proxy upgradeability to ‘update’ the smart contract to burn and mint tokens or add any new functions to the code. The proxy contract was intended for developers to be able to delegate function calls to other contracts and upgrade delegates without breaking dependencies.
However, with exploits like function clashing, the proxy contract can be easily manipulated by the deployer or someone with access to the deployer’s private key to divert functions being called through the proxy.
A more detailed explanation on the inner workings of upgradeable proxy smart contracts can be found here.
Binance-based token Meerkat’s exploit put the attacker in a difficult position: Binance controls on and off-ramps to Binance Smart Chain (it’s easy with only 21 validator nodes), meaning any stolen funds were locked on the chain and impossible to convert to profits. Thus, the Meerkat team has now decided to return the $31 million in stolen user funds. The hacked Ethereum-based tokens’ users are still trying to find a resolution.
