Thread by @anacoding

Day 74 of #100DaysOfDeFI 🚀 Today I learned about Delegate Call vulnerability in #Solidity 🦹🏼‍♀️  When using delegatecall opcode one should be careful because wrong usage will lead to unexpected results ⚠️
#womenwhocode #100DaysOfCode

How it works 🧵

1/ What delegatecall is? When contract A uses delegatecall to call contract B it means that the contract B code will be executed inside context of the contract A: storage, msg.sender, msg.value, msg.data, etc will be the A’s context.

2/ Storage layout must be the same for contract A and contract B → it means both contracts should declare the same state variables in the same order 👾

3/ Create a contract Lib that has a functionality of setting a msg.sender as an “owner” state variable 👇

4/ Then create a vulnerable contract HackMe → it uses delegatecall when calling Lib contract 👩🏻‍💻 When fallback function is called, it sends to the Lib contact msg data to execute 👇

5/ Then, implement an Attack contract that will exploit the vulnerability of HackMe contract 🦹🏼‍♀️ The attack tries to call pwn function in HackMe and since it doesn’t exist it redirects to fallback. The fallback delegates call to Lib and sets the attacker’s address as the owner 👾

6/ Let’s try it out in Remix! First deploy Lib contract, copy its address and use it for deploying HackMe contract. Then check the owner of HackMe → it should be the address that we used to deploy the contracts👇

7/ It’s time for a mischief! 🦹🏼‍♀️ Deploy the Attack contract with HackMe address. Then click on “attack” button and see what it’s done: the owner of HackMe contract has changed to the Attacker’s 👻