Introduction to Smart Contract Security Audit

Background overview

In the last article, we learned what the delegatecall function is and a basic vulnerability. The purpose of this article is to deepen everyone’s impression of delegatecall and take everyone to play something exciting and win an advanced version of the vulnerability smart contract audit services contract.

Vulnerability Analysis

The target of this attack is still 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 function to modify the owner . How do we complete the attack? A little skill is needed here. You can think about it, and you can just verify your mastery of previous knowledge and whether your thinking is active.

Attack Contract

Let’s first look at the attack flow:

1. Alice deploys the Lib contract;

2. Alice launches the HackMe contract and adds the Lib contract’s address to the function Object() { [native code] };

3. The hacker Eve launches the Attack contract and feeds the function Object() { [native code] } the address of the HackMe contract;

4. The attacker calls the Attack.attack() function to change the owner in the HackMe contract to himself.

What’s the matter? In fact, this attack method is a very clever use of the characteristics of the delegatecall function when modifying the storage type variable: the execution environment of the delegatecall function is the caller’s environment and the modification of the storage type variable is based on the location of the slot where the variable of the called contract is stored. Modified.

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 in slot0 in the contract to the incoming value, so when the HackMe contract uses delegatecall to call the Lib.doSomething() function, it will also change the parameter stored in slot0. The value of the variable, 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; smart contract audit

4. The Attack.attack() function calls the HackMe.doSomething() function again. Since we have changed the HackMe.lib variable to the address of the Attack contract in the previous step, the HackMe.doSomething() function will no longer call the previous one. Instead, the Lib contract uses delegatecall to call Attack.doSomething() function. At this point, we will observe the writing of the Attack contract, and find that the storage location of its variables is intentionally 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 modified The variable in the contract is stored in slot1. Therefore, 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 Eve. So far, the attacker has completed his attack.

Repair suggestion

As a Developer

1. It should be noticed that the address of the called contract cannot be controlled when using delegatecall;

2. You must be mindful of the declaration sequence and variable storage location in a more sophisticated contract context. Because when using delegatecall to make an external call, the data stored in the corresponding slot of the contract will be modified according to the data structure of the called contract, bsc smart contract audit which may cause unexpected variable coverage when the data structure changes.

As Auditor

1. In the audit process, when the delegatecall is used in the contract, it is necessary to pay attention to whether the called contract address is controllable;

2. When the function in the called contract modifies the storage variable, it is necessary to pay attention to the location of the variable storage slot, so as to avoid the storage variable stored in the contract being incorrectly overwritten due to inconsistent data structures.