SharkTeam：十大智能合约安全威胁之合约升级漏洞

SharkTeam：十大智能合约安全威胁之合约升级漏洞 问：我们常提到的智能合约漏洞真的是实际中威胁最大、发生最频繁的安全漏洞吗？ 答：完全不是那样。例如“溢出”、“外部调用”等常提到的智能合约安全漏洞并不是最常发生，威胁最大的。 到底哪些安全威胁从发生频率和危害性上能称为Top10的呢？SharkTeam合约安全系列课程之【十大智能合约安全威胁】和您一起讨论和深入。第五课【详解合约升级漏洞】。

一、什么是合约升级？

智能合约部署后默认是不可变的，一旦你创建了它们，就没有办法改变它们。每个智能合约都有一个唯一的地址，用户将交易发送到智能合约的地址，来执行存储在该合约中的代码。但是，在实际应用中，开发者通常因为业务升级或安全升级的需求需要通过技术的手段来更新合约逻辑，因此合约升级的开发模式应运而生。常见的几种合约升级模式如下。

1.1继承存储模式

继承存储模式通过为代理合约和逻辑合约所需的状态变量提供严格的存储顺序来解决状态碰撞问题，代理合约委托逻辑合约进行调用。因此，只有代理合约的存储在使用。继承了公共存储合约的代理合约可以访问其父合约的所有状态变量，每个状态变量根据其索引占据适当的内存位置。

初始化流程如下： （1）部署Registry合约 （2）部署合约的初始版本 （v1），确保它继承了“可升级”合约 （3）将初始版本的地址注册到Registry （4）请求Registry合约创建UpgradeabilityProxy实例 （5）调用UpgradeabilityProxy来升级到合约的初始版本 升级流程如下： （1）部署从初始版本继承的新版本的合约 （v2），以确保它保留代理的存储结构和合约初始版本中的存储结构 （2）将合约的新版本注册到Registry （3）调用UpgradeabilityProxy实例以升级到新的注册版本 虽然继承存储模式解决了可升级合约的存储碰撞问题，但这种方法也有自己的缺点。由于所有先前声明的状态变量都需要被复制到新部署的版本中，因此升级变得昂贵。其中一些可能没有被使用，最终会不必要地占用内存。由于公共存储模式，逻辑合约变得与代理合约紧密耦合。因此，不可能将这些逻辑合约用于不继承公共存储合约的任何其他代理。

1.2非结构化存储模式

在这种模式中，代理合约往往是具有一些基本函数的最小化合约，大部分的业务逻辑都在逻辑合约里面完成，新的逻辑合约保持了最新的实现合约中存在的状态变量的顺序。代理合约一般需要所有者和实现变量来维持所有权和版本控制，代理合约将这些属性指定为常量，它们被设置在合约的字节码内。OpenZepplin在其可升级的合约服务中使用了非结构化的存储模式。

初始化流程如下： （1）部署OwnedUpgradeabilityProxy实例 （2）部署合约的初始版本 （v1） （3）调用OwnedUpgradeabilityProxy实例来升级到初始版本的地址 （4）如果逻辑合约依赖它的构造函数来设置一些初始状态，那么在它与代理链接后，就必须重新进行设置，因为代理的存储不知道这些值。OwnedUpgradeabilityProxy有一个函数upgradeToAndCall，专门用来调用逻辑合约上的一些函数，在代理升级到它之后重新进行设置 升级流程如下： （1）部署新版本的合约 （v2），确保它继承以前版本中使用的状态变量结构 （2）调用OwnedUpgradeabilityProxy实例来升级到新合约版本的地址

1.3永久存储模式

这种模式的目标是尽量减少存储复制的要求。在这种模式中，一个单独的合约被维护为永久存储合约。因此，所有的逻辑版本都利用这个永久存储合约来满足其存储需求。因此，存储复制的要求被从升级模式中移除，这种方法大大降低了升级成本。

初始化流程如下： （1）部署一个EternalStorageProxy实例 （2）部署一个初始版本的合约（v1） （3）调用EternalStorageProxy实例来升级到初始版本的地址 （4）如果逻辑合约依赖其构造函数来设置一些初始状态，那就必须在其链接到代理后重新进行，因为代理的存储不知道这些值。EternalStorageProxy有一个函数upgradeToAndCall，专门用来调用逻辑合约上的一些函数，在代理升级到它之后重新进行设置 升级流程如下： （1）部署一个新版本的合约（v2），确保它拥有永久存储结构 （2）调用EternalStorageProxy实例来升级到新版本

1.4Diamond 模式

Solidity 合约的最大限制为 24KB。因此，每个合约的大小永远不能超过 24KB。Diamond 模式使开发人员能够编写没有大小限制的智能合约。此模式还支持升级，而无需重新部署现有功能，详细Diamond 标准可见EIP 2535。 Diamond 是一个合约，它将调用委托给称为面的实现合约。Diamond 合约实现了一个 diamondCut 函数，它提供了添加/替换/删除的能力。除了 diamondCut 函数之外，还实现了一组 loupe 函数。这些函数显示了关于所实现的Diamond 的信息。Diamond 合约维护了一个selectorToFacet的映射，这基本上是一个函数签名到实现合约地址的映射。当用户调用一个函数时，Diamond 代理的回退函数使用函数签名来寻找这个映射中的实现地址。在找到函数签名的地址后，回退函数只是将调用委托给实现合约，并将响应返回给用户。 Diamond 代理依靠的是一种存储模式。该代理被一些被称为面的实现合约所共享。理想情况下，每个切面都有自己的存储。然而，根据实施要求，面可以与其他面共享存储。DiamondStorage和AppStorage是一些流行的存储模式，分别用于隔离和共享存储。 Diamond 模式为创建模块化的智能合约应用程序提供了一种简洁的方式，没有任何最大尺寸限制。因此，它似乎是那些希望在未来扩大规模的大型智能合约应用程序的完美选择。

1.5 create2

create操作码用于在以太坊区块链上部署合约。合约地址是通过散列部署者的地址和该地址的nonce来生成的。Nonce是一个标量值，等于从部署者的地址发送的交易数量。同样，在合约账户的情况下，nonce是该账户创建合约的数量。nonce有助于保持交易的顺序（来自一个地址的低nonce交易会先被开采），并防止重入攻击。nonce是一个递增的数字，防止create操作码产生重复的地址。只要在当前和下一个nonce之间没有新的交易发生，就有可能通过简单散列下一个nonce和地址来知道下一个合约的地址。 create2操作码被添加到以太坊虚拟机中，作为君士坦丁堡硬分叉的一部分，这个操作码也被用来部署智能合约。create2使用一些用户控制的输入来推导出智能合约的地址。换句话说，这个操作码提供了一种方法，在将智能合约部署到区块链之前计算其地址。这个操作码不是对部署者的地址和nonce进行散列，而是对部署者的地址、salt（由部署者提供的32字节的字符串）和合约的字节码的哈希进行散列。由于这个操作码的所有参数都由用户控制，create2提供了一种预先确定合约地址的方法。这个方法在推导出优化gas的合约地址和实现像状态通道这样的扩展解决方案时非常有用。在可升级性方面，create2提供了创建可变合约（metamorphic contract）的能力，这些合约可以用新的字节码重新部署到同一地址。 EVM包含一个selfdestruct 操作码，智能合约可以通过这个操作码来删除。为了在原始地址上部署一个新的字节码，该地址必须是自由的，因为智能合约是不可改变的。有几种方法可以将新的字节码部署到原始地址上，一个低效的方法是找到salt的参数，与新的字节码相结合，生成原始地址，寻找正确的salt参数的计算可以在链下完成。然而，这并不是一个很好的方法。另一个选择是部署一个可变合约。如上所述，可变合约可以使用不同的字节码重新部署到原始地址。 建立一个良好的升级模式，需要一个可变合约工厂。这个可变合约工厂的目的是通过改变其实现而不改变其地址来促进升级。在部署合约时，对应的部署函数使用create2预先计算可变合约的地址，实现合约是使用传统的create操作码部署的。这个操作码使用地址和nonce来生成地址，并将合约部署到该地址。要求实现地址不能为零。否则，实现合约没有被正确部署，函数必须返回。部署完实现合约后，工厂状态被更新来存储当前的实现合约。 值得注意的是，实现合约必须是自毁的，这也会使可变合约自毁。在重新部署可变合约之前，要确保可变合约使用selfdestruct操作码进行自我销毁。由于create2操作码的存在，可变合约的地址总是提前知道的。此外，由于它能够改变其实现，可变合约每次都可以用不同的实现重新部署。 使用create2是有优势的，但它也有自己的风险。最重要的风险是，每次合约被重新部署时，其存储都会被抹去。另外，带有selfdestruct操作码的实现合约可能不是一个可靠的资金存储方式。因此，在采用这种智能合约升级模式之前，开发者必须谨慎行事。

二、攻击事件分析

2.1 Uranium Finance

2021年4月28日，币安智能链上区块链项目 Uranium Finance在流动性迁移过程中被攻击，涉及资金为 5000 万美元。攻击合约地址：0x2b528a28451e9853F51616f3B0f6D82Af8bEA6Ae。 我们从攻击合约中找到的项目合约地址并进行了攻击原理分析，攻击流程如下： （1）首先查看攻击合约的代码发现，这个合约的源码没有公开，通过反编译查看其源码

（2）通过浏览器查看最早的攻击交易 0x5a504fe72ef7fc76dfeb4d979e533af4e23fe37e90b5516186d5787893c37991,可得到攻击者调用的合约方法对应的签名为52f18fc3

（3）从反编译代码中寻找这个编码后的合约方法，可以找到这个合约攻击的项目方合约地址，也就是 Uranium 项目所在的地址：0xa943ea143cd7e79806d670f4a7cf08f8922a454f

（4）通过分析，Uranium 项目合约中的漏洞出现在 UraniumPair.sol 合约中的 swap 函数中，这个漏洞会导致任何人可以随意的转出合约中的数字资产，而只需要付出一点点的代价。可以看到 swap 中，最后是一个10的8次方数和一个10的6次方数的比较，这是一个几乎是恒等的判断，这就意味着只要按照一定的套路不断的执行 swap 函数，就可以清空这个合约中所有的数字资产。

我们看到UniswapV2Pair.sol的合约中的写法是相同的，但是它是两个10的6次方数字的比较。

问题分析：造成这次事件的原因应该是项目方更新升级这个合约的时候，忘记了将后面的1000的2次方改为10000的二次方。

2.2 Audius

2022年7月24日，黑客从音乐流媒体协议Audius转移了1800万个AUDIO代币。攻击者发起了两次攻击，其中第一次攻击失败，第二次攻击成功。我们主要来分析第二次攻击，攻击者在创建了攻击合约后，通过攻击合约发起了攻击，包含4笔交易： （1）txHash1: 0xfefd829e246002a8fd061eede7501bccb6e244a9aacea0ebceaecef5d877a984 （2）txHash2: 0x3c09c6306b67737227edc24c663462d870e7c2bf39e9ab66877a980c900dd5d5 （3）txHash3: 0x4227bca8ed4b8915c7eec0e14ad3748a88c4371d4176e716e8007249b9980dc9 （4）txHash4: 0x82fc23992c7433fffad0e28a1b8d11211dc4377de83e88088d79f24f4a3f28b3

在txHash1中，主要交易流程如下： （1）通过Audius的代理合约对Governance合约进行初始化 （2）评估/执行84号提案，即第一次攻击提交的提案，评估为QuorumNotMet，原因是没有投票 （3）查询Governance代理合约的AUDIO代币余额 （4）提交85号提案，与84号提案相同。该提案的功能就是将Governance代理合约中的AUDIO转移到攻击合约，数量不能超过Governance代理合约的AUDIO余额 （5）通过代理合约对Staking合约进行初始化，将治理代币地址以及代理合约地址都设置为攻击合约

（6）通过代理合约对DelegateManagerV2合约进行初始化，将治理代币地址以及代理治理地址都设置为攻击合约

（7）通过代理合约将DelegateManagerV2合约中的服务提供者工厂合约为攻击合约

（8）通过代理合约将质押的代理权授权给攻击合约，授权的代币数量为1e31

通过以上步骤，攻击者篡改并获取了治理系统的最高权限。 在txHash2中，攻击者在提交了提案85之后的3个区块内进行了投票。 在txHash3中，攻击者在3个区块的投票期以及1个区块的等待期之后对提案85进行了评估/执行。 在txHash4中，执行提案85，将18,56万枚AUDIO转移到攻击合约，攻击合约收到1800万枚AUDIO后，将其兑换为704 枚ETH。 最后，攻击者将兑换的ETH存入到了Tornash平台。 问题分析：攻击者之所以能够攻击成功，根本原因在于通过代理合约多次调用初始化函数，而初始化函数本应该只能调用一次的。以Governance合约中的初始化函数为例，其代码如下：

这里使用了Openzeppelin里面的初始化器initializer，initializer没有起到任何作用，原因在于代理调用。

Openzeppelin里面的初始化器initializer中定义的两个bool类型的状态变量initialized和intializing分别占用了存储插槽slot0中的前16个字节。第1个8字节为initialized，第2个8字节为initializing。

由于代理合约本身定义了一个地址类型的状态变量proxyAdmin，其值为0x80ab62886eacfebca74511823d4699eb88fd097e，同样占用了存储插槽slot0，第1个8字节为0，第2个8字节为0x80ab6288，第3个8字节为0x6eacfebca7451182，第4个8字节为0x3d4699eb88fd097e。于是，实现合约中的initialized和intializing与代理合约中的proxyAdmin同时占用了存储插槽slot0，从而引起了存储冲突。 插槽0中的数据分布如下：

初始化函数执行到initializer时，从存储插槽slot0的第1个8字节读取initialized，其值为0，即false；从存储插槽slot0的第2个8字节读取initializing，其值为0x80ab6288 > 0，即true。

三、预防措施

我们了解合约升级的几种模式以及回顾了相关攻击事件后，作为开发人员应该采取哪些适当的措施来防止相关攻击？ （1）可升级智能合约的真正问题是从合约中迁移存储值，构建可升级智能合约的更好方法是区分不同合约中的存储和逻辑，将合约数据保存在一个仅接受来自逻辑合约调用的合约中，不断改变逻辑合约的逻辑 （2）在调用 delegatecall 之前检查目标合约是否存在，Solidity 不会替我们执行此检查，忽略检查可能会导致意外行为和安全问题 （3）仔细考虑变量声明的顺序，因为会出现变量打包存储同一个插槽、影响gas成本、内存布局、delegate调用结果等问题 （4）仔细考虑合约初始化问题，状态变量可能在构造时候出现未初始化，应当在初始化期间缓解潜在的竞争条件 （5）考虑代理模式中的函数名称，避免函数名称冲突 （6）项目上线前，需联系专业的第三方专业审计团队进行审计

关于我们：SharkTeam的愿景是全面保护Web3世界的安全。团队成员分布在北京、南京、苏州、硅谷，由来自世界各地的经验丰富的安全专业人士和高级研究人员组成，精通区块链和智能合约的底层理论，提供包括智能合约审计、链上分析、应急响应等服务。已与区块链生态系统各个领域的关键参与者,如OKC、polygon、Huobi Global、Polkadot、imToken、ChainIDE等建立长期合作关系。

Telegram：https://t.me/sharkteamorg Twitter：https://twitter.com/sharkteamorg 更多区块链安全咨询与分析，点击下方链接查看 D查查|链上风险核查 https://m.chainaegis.com