Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

The project being tested was from Alchemist. They developed the Fjord Foundry platform which has an ERC-20 token called MIST, a staking and rewards platform called Aludel and a smart wallet called Crucible.

Within the ERC-20 token, the function advance() mints a new inflation according to the newly set parameters. This is a two step process within a TimelockConfig which is controlled by a multi-sig admin wallet.

Changes are proposed in step 1 with the requestChange() with a waiting period of 7 days. This can be cancelled with cancelChange(). Both of these functions are only accessible to the administrators with the onlyAdmin modifier.

The confirmChange() function is used to enact the proposed change. This does not have an administrative modifier on top of it though. At first glance, this seems fine... the validation of the date works as expected. However, this does open up a new attack surface though!

The vulnerability is that confirmChange() assumes that a change has been proposed for a given ID via this two step process. In reality, an external user can call this function without any proposals for a given ID. The only validation is that the block.timestamp is greater than the proposed time.

Here's the problem: if the configID doesn't exist, this mapping of timestamp to configID will return 0! Since 0 is less than the current timestamp, the function believes this is a valid call. In most languages, a missing dictionary entry will crash the program... but not Solidity!

In the rest of the function call, it sets the new admin config. Since all of these are set to 0, it bricks some parts of the contract. In particular, it's impossible to call advance() on the smart contract now. Overall, a bad developer assumption caused a major security flaw.