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!

This article goes into the security problems that can occur while using proxies. This website is meant to be all the research to do with proxies in the blockchain space.

The first vulnerability mentioned is unintialized proxy. When updating the proxy to use a new implementation, there's a problem: the constructor will not be evaluated on the contract. Naturally, we need to initialize state when adding a new implementation. So, the implementation contract should have an initialize() function. The initialization step must happen separately from the deployment. So, there is a race condition where the function could be called. If an attacker called this, or the function was forgotten about, an attacker could cause major havoc.

To test for the uninitialized contract, a few cases should be run:

• Is the contract initialized?
• Can it be reinitialzied?
• Is there a race condition between implementation deployment and initialization execution?
• Is there a access control on this function?

Wormhole and OpenZeppelin are great examples of this.

The second vulnerability is storage collision. When calling delegateCall the implementation contract is using the storage of the proxy contract. If there is a collision between these two contracts for variables, then havoc can ensure. In the case of Audis, proxyadmin was stored in the initializable field for the contract. This allowed the contract to be reinitialized and steal the funds.

To test for this vulnerability, sol2uml can be used to visualize the storage slots from proxy to implementation. Additionally, using the artifacts between compilations of different versions would work too. This vulnerability can be particularly common with updates, since this could reorder the variables.

Function clashing occurs when the 4 byte identifier of a function selector is the same. If a proxy function and an admin function have the same selector, this can cause problems. Slither is able to detect this problem automatically.

The next two vulnerabilities are with using delegateCall. Redirecting to an arbitrary contract allows for the contract to alter internal variables. The next issue is figuring out a selfdestruct call from the initial call in the proxy. By doing this, the address and variables are ruined forever.

The final issue is calls with delegateCall not checking the result. By not checking the result, the function would have executed without anything happening. delegateCall doesn't revert on not calling a contract; it only returns a boolean to mention this.

Overall, a good read into proxy based vulnerabilities.