Hats.finance TimeController implementation vulnerability — Postmortem

Since the moment we created Hats Finance, we lived by the motto that security is the building block of strong protocols, and throughout our journey, we have been able to help projects easily access security talent.

In line with this motto, we have been working hard to ensure that we keep the highest security measures in place ourselves. This includes a commitment to remain transparent in all of our efforts to keep Hats Finance safe because, at the end of the day, we are a security protocol in which you have placed your trust.

On December 27, we announced the start of a process that we call “Raising the hacker reward ceiling”. This process came after we added a time lock to our governance system, which is a standard way of reducing governance risk factors by adding a delay between governance decisions and its execution, which allows users to exit if they are not happy with the decision.

We implemented the TimeLock with the intention of adding an additional security layer to governance decisions. However, on January 16th, one of the Hats developers found that the implementation of the HatTimeLockController was based on a vulnerable version of the OpenZeppelin’s TimeController implementation.

Summary

A few weeks ago we were notified by one of our developers of an existing vulnerability in the deployed version of our Time Lock controller. After being notified, we immediately took action, and we were able to update to a newer version of the timelock. No funds were compromised, and at no time the vulnerability was at risk to be exploited by third parties different from the Hats multisig signers.

The vulnerability

• on December 20, 2021, Hats deployed an instance of HatTimelockController.sol to main net at the address 0x66922e992e07030CEaC25E1919E9C31153F85b6f, and gave it the Governance role in the HatVaults contracts deployed on 0x571f39d351513146248AcafA9D0509319A327C4D.
• Permissions on the Timelock were configured as follows:
• PROPOSER_ROLE: The Hats Governance contract at 0xBA5Ddb6Af728F01E91D77D12073548D823f6D1ef
• EXECUTOR_ROLE: All signers of the Hats Governance contract, namely the following addresses: [ “0x2B6656e212f315D3C2DD477FE7EBFb3A86bb1c94”, “0x9Fb3d86157a9e2dC2a771C297f88FA9784fa4e31”, “0xF6aEF099e4473E08bed75E0BB1252C4cdAd96416”, “0xb3E7828EC7Ce2B270E3008B6400597C3a203809e”, “0xd714Dd60e22BbB1cbAFD0e40dE5Cfa7bBDD3F3C8”, ]
• TIMELOCK_ADMIN_ROLE is held by the HatTimelockController instance itself
• On January 16, Hats was made aware that the implementation of HatTimelockController was based on a vulnerable version of OpenZeppelin’s TimelockController implementation. The vulnerability is clearly described here: https://forum.openzeppelin.com/t/timelockcontroller-vulnerability-post-mortem/14958. The vulnerability consists in the fact that any account with the EXECUTOR_ROLE can gain control over the Timelock — in particular, an attacker can obtain the PROPOSER_ROLE and set the minDelay value to 0, which allows the attacker to execute any transaction without the timelock.

Resolution

• A new, patched, version of the HatTimelockController was deployed at 0xFd4255F16378306CA83E37015Df01a1700DAc296
• On January 18, the exploit was used by one of the executors (namely 0xb3E7828EC7Ce2B270E3008B6400597C3a203809e) to call setPendingGovernance on the HatVaults contract, to set governance to the new HatTimelockController. The HATVaults contract implements a kind of timelock of 2 days itself.
• On January 20, the exploit was used to change the governance to the new contract, and the vulnerability was patched.

We are grateful that one of our talented developers was able to find the vulnerability and patched it. No funds were at risk as all executors were trusted. However, this is a useful reminder that we must be more cautious in the contracts we implement, checking for vulnerabilities and contract updates.

We remain committed to revolutionizing the future of Ethereum security.

Looking to the future…

This incident serves as a lesson for us and helps us be better equipped in the future. We will use this experience to review and improve our internal review processes and QA standards.