创宇区块链安全实验室 水手 2021-06-03 11:09:47 发布在 区块链社区
25227 0
前言
智能合约（英文：Smart contract ）的概念于 1995 年由 Nick Szabo 首次提出，它是一种旨在以信息化方式传播、验证或执行合同的计算机协议，它允许在没有第三方的情况下进行可信交易，这些交易可追踪且不可逆转。然而智能合约也并非是安全的，其中 重入 (Re-Entrance) 攻击漏洞是以太坊中的攻击方式之一，早在 2016 年就因为 The DAO 事件而造成了以太坊的硬分叉。
漏洞概述
在以太坊中，智能合约能够调用其他外部合约的代码，由于智能合约可以调用外部合约或者发送以太币，这些操作需要合约提交外部的调用，所以这些合约外部的调用就可以被攻击者利用造成攻击劫持，使得被攻击合约在任意位置重新执行，绕过原代码中的限制条件，从而发生重入攻击。重入攻击本质上与编程里的递归调用类似，所以当合约将以太币发送到未知地址时就可能会发生。
简单的来说，发生重入攻击漏洞的条件有 2 个：
- 调用了外部的合约且该合约是不安全的
- 外部合约的函数调用早于状态变量的修改
下面给出一个简单的代码片段示例：
上述代码片段就是最简单的提款操作，接下来会给大家详细分析重入攻击造成的原因。
漏洞分析
在正式的分析重入攻击之前，我们先来介绍几个重点知识。
01 转账方法
由于重入攻击会发送在转账操作时，而 Solidity 中常用的转账方法为
<address>.transfer()，<address>.send() 和 <address>.gas().call.vale()()，下面对这 3 种转账方法进行说明：
- <address>.transfer()：只会发送 2300 gas 进行调用，当发送失败时会通过 throw 来进行回滚操作，从而防止了重入攻击。
- <address>.send()：只会发送 2300 gas 进行调用，当发送失败时会返回布尔值 false，从而防止了重入攻击。
- <address>.gas().call.vale()()：在调用时会发送所有的 gas，当发送失败时会返回布尔值 false，不能有效的防止重入攻击。
02 fallback 函数
接着我们来讲解下 fallback 回退函数。
回退函数 (fallback function)：回退函数是每个合约中有且仅有一个没有名字的函数，并且该函数无参数，无返回值，如下所示：
回退函数在以下几种情况中被执行： * 调用合约时没有匹配到任何一个函数； * 没有传数据； * 智能合约收到以太币（为了接受以太币，fallback 函数必被标记为 payable）。
03 漏洞代码
下面的代码就是存在重入攻击的，实现的是一个类似于公共钱包的合约，所有的用户都可以使用 deposit() 存款到 Reentrance 合约中，也可以从 Reentrance 合约中使用 withdraw() 进行提款，当然了所有人也可以使用 balanceof() 查询自己或者其他人在该合约中的余额。
首先使用一个账户 (0x5B38Da6a701c568545dCfcB03FcB875f56beddC4) 扮演受害者，将该合约在 Remix IDE 点击 Deploy 按钮进行部署。
在部署合约成功后在 VALUE 设置框中填写 5，将单位改成 ether，点击 deposit 存入 5 个以太币。
点击 wallet 查看该合约的余额，发现余额为 5 ether，说明我们的存款成功。
而下面的代码则是针对上面存在漏洞的合约进行的攻击：
使用另外一个账户 (0xAb8483F64d9C6d1EcF9b849Ae677dD3315835cb2) 扮演攻击者，复制存在漏洞的合约地址到 Deploy 的设置框内，点击 Deploy 部署上面的攻击合约。
部署成功后先调用 wallet() 函数查看攻击合约的余额为 0。
攻击者先存款 1 ether 到漏洞合约中，这里设置 VALUE 为 1 ether，之后点击攻击合约的 deposit 进行存款。
再次调用合约的 wallet 函数查看漏洞合约的余额，发现已经变成了 6 ether。
攻击者 (0xAb8483F64d9C6d1EcF9b849Ae677dD3315835cb2) 调用攻击合约的 attack 函数模拟攻击，之后调用被攻击合约的 wallet 函数去查看合约的余额，发现已经归零，此时回到攻击合约查看余额，发现被攻击合约中的 6 ether 已经全部提款到了攻击者合约中，这就造成了重入攻击。
04源码分析
上面讲解了如何进行重入攻击已经漏洞原因，这里梳理了漏洞源码和攻击的步骤，列出了关键代码。
相关案例
2016 年 6 月 17 日，TheDAO 项目遭到了重入攻击，导致了 300 多万个以太币被从 TheDAO 资产池中分离出来，而攻击者利用 TheDAO 智能合约中的 splitDAO() 函数重复利用自己的 DAO 资产进行重入攻击，不断的从 TheDAO 项目的资产池中将 DAO 资产分离出来并转移到自己的账户中。
下列代码为 splitDAO() 函数中的部分代码，源代码在 TokenCreation.sol 中，它会将代币从 the parent DAO 转移到 the child DAO 中。平衡数组 uint fundsToBeMoved = (balances[msg.sender] * p.splitData[0].splitBalance) / p.splitData[0].totalSupply 决定了要转移的代币数量。
下面的代码则是进行提款奖励操作，每次攻击者调用这项功能时 p.splitData[0] 都是一样的（它是 p 的一个属性，即一个固定的值），并且 p.splitData[0].totalSupply 与 balances[msg.sender] 的值由于函数顺序问题，发生在了转账操作之后，并没有被更新。
paidOut[_account] += reward 更新状态变量放在了问题代码 payOut 函数调用之后。
对_recipient 发出 .call.value 调用，转账_amount 个 Wei，.call.value 调用默认会使用当前剩余的所有 gas。
解决办法
通过上面对重入攻击的分析，我们可以发现重入攻击漏洞的重点在于使用了 fallback 等函数回调自己造成递归调用进行循环转账操作，所以针对重入攻击漏洞的解决办法有以下几种。
01使用其他转账函数
在进行以太币转账发送给外部地址时使用 Solidity 内置的 transfer() 函数，因为 transfer() 转账时只会发送 2300 gas 进行调用，这将不足以调用另一份合约，使用 transfer() 重写原合约的 withdraw() 如下：
02先修改状态变量
这种方式就是确保状态变量的修改要早于转账操作，即 Solidity 官方推荐的检查-生效-交互模式 (checks-effects-interactions)。
03使用互斥锁
互斥锁就是添加一个在代码执行过程中锁定合约的状态变量以防止重入攻击。
04使用 OpenZeppelin 官方库
OpenZeppelin 官方库中有一个专门针对重入攻击的安全合约：
https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/security/ReentrancyGuard.sol
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
/** * @dev Contract module that helps prevent reentrant calls to a function. *
* Inheriting from `ReentrancyGuard` will make the {nonReentrant} modifier * available, which can be applied to functions to make sure there are no nested * (reentrant) calls to them. * * Note that because there is a single `nonReentrant` guard, functions marked as * `nonReentrant` may not call one another. This can be worked around by making * those functions `private`, and then adding `external` `nonReentrant` entry * points to them. * * TIP: If you would like to learn more about reentrancy and alternative ways * to protect against it, check out our blog post * https://blog.openzeppelin.com/reentrancy-after-istanbul/[Reentrancy After Istanbul]. */abstract contract ReentrancyGuard { // Booleans are more expensive than uint256 or any type that takes up a full // word because each write operation emits an extra SLOAD to first read the // slot’s contents, replace the bits taken up by the boolean, and then write // back. This is the compiler’s defense against contract upgrades and // pointer aliasing, and it cannot be disabled.
// The values being non-zero value makes deployment a bit more expensive, // but in exchange the refund on every call to nonReentrant will be lower in // amount. Since refunds are capped to a percentage of the total // transaction’s gas, it is best to keep them low in cases like this one, to // increase the likelihood of the full refund coming into effect. uint256 private constant _NOT_ENTERED = 1; uint256 private constant _ENTERED = 2;
uint256 private _status;
constructor () { _status = _NOT_ENTERED; }
/** * @dev Prevents a contract from calling itself, directly or indirectly. * Calling a `nonReentrant` function from another `nonReentrant` * function is not supported. It is possible to prevent this from happening * by making the `nonReentrant` function external, and make it call a * `private` function that does the actual work. */ modifier nonReentrant() { // On the first call to nonReentrant, _notEntered will be true require(_status != _ENTERED, “ReentrancyGuard: reentrant call”);
// Any calls to nonReentrant after this point will fail _status = _ENTERED;
_;
// By storing the original value once again, a refund is triggered (see // https://eips.ethereum.org/EIPS/eip-2200) _status = _NOT_ENTERED; }}
