Intelligent security contract - delegatecall (2)

This time, let's talk about a more complex contract vulnerability case when using the delegatecall function.

Target Contract

vulnerability analysisThe target of this attack is stillIt is to obtain the owner permission in the HackMe contract. We can see that in the two contracts, except for the constructor in the HackMe contract, which can modify the owner of the contract, there is no other place to modify the owner function, but it can modify the value of slot0, while the HackMe contractThe slot slot0 in the middle represents the address of Lib, then we first modify the address of Lib to our address, and when we call the HackMe contract again, the logic in our contract will be run, so the value of the slot we want to change is not the same.Is it all under our control?

Attack contractThe following is our attack contract:

Next, let's look at the entire logic of the attack:

1. The Attack.attack() function first converts its own address to uint256 type (this step is to be compatible with the data type in the target contract) and calls the HackMe.doSomething() function for the first time;

2. The HackMe.doSomething() function uses the delegatecall function to call the Lib.doSomething() function with the address of the incoming Attack contract;

3. You can see that the Lib.doSomething() function changes the parameter stored at slot0 in the contract to the incoming value, so that when the HackMe contract uses delegatecall to call the Lib.doSomething() function, it will also change its location in the contract.The value of the variable stored in slot0, that is, changing the lib parameter (stored here is the address of the Lib contract) to the address of the Attack contract we passed in.At this point, the address of the Lib contract previously stored in the HackMe.lib parameter has been modified to the address of the Attack contract we passed in;

4.Attack.attack() function calls the HackMe.doSomething() function again. Since we have modified the HackMe.lib variable to the address of the Attack contract in the previous step, the HackMe.doSomething() function will no longer be used.Instead of calling the previous Lib contract, use delegatecall to call Attack.doSomething() function.At this point, let's observe the writing of the Attack contract, and find that the storage location of its variables is deliberately consistent with the HackMe contract, and it is not difficult to find that the content of the Attack.doSomething() function is also written by the attacker as owner = msg.sender, this operation is modifiedThe variable in the contract is stored in slot1.So the HackMe contract uses the delegatecall to call the Attack.doSomething() function to change the variable owner whose storage location is slot1 in the contract to msg.sender, which is the address of the attacker. At this point, the attacker has completed his attack.

Repair suggestion When we use delegatecall in the development of the contract, we should always pay attention to the contract address that it is called to always run within the logic we designed, and it cannot be allowed to exceed the applicable scope of our design.Scope, once there is a situation beyond our expected design, the contract may be used by criminals.

If you want to know more about smart contracts and blockchain knowledge, welcome to the blockchain exchange community CHAINPIP community to communicate and learn together~Community address: https://www.chainpip.com/