深入理解拒绝服务漏洞

function invest public payable { // 投资

investors.push(msg.sender);

investorTokens.push(msg.value * 5); // 5 倍 value

}

function distribute public { // 分配

require(msg.sender == owner); // 只有合约所有者可以操作

for(uint i = 0; i < investors.length; i++) {

// 这里 transferToken(to,amount) 将 "amount" 的代币转移到地址 "to"

transferToken(investors[i], investorTokens[i]);

}

}

在上面的代码片段中我们可以看到，distribute函数中会去遍历投资者数组，但是合约的循环遍历数组是可以被外部的人进行人为扩充，如果有攻击者要攻击这个合约，那么他可以创建多个账户加入投资者的数组，让 investors 的数据变得很大，大到让循环遍历数组所需的 gas 数量超过区块 gas 数量的上限，此时 distribute函数将无法正常操作，这样就会造成该合约的拒绝服务攻击。

针对以上情况，合约不应该对可以被外部用户人为操纵的映射或循环数组进行批量操作，这里更建议使用取回模式而不是发送模式，即每个投资者可以通过使用 withdrawFunds取回自己应得的代币。

如果合约必须需要通过遍历一个变长数组来进行转账，那么最好是估计完成它们大概需要多少个区块以及多少笔交易，从而限制数组长度，此外还必须能够追踪得到当前进行到哪以便当操作失败时从那里开始进行恢复。如下面的代码所示，必须确保在下一次执行 payOut之前另一些正在执行的交易不会发生任何错误。

struct Payee {

address addr;

uint256 value;

}

Payee payees[];

uint256 nextPayeeIndex;

function payOut {

uint256 i = nextPayeeIndex;

while (i < payees.length && msg.gas > 200000) {

payees[i].addr.send(payees[i].value);

i++;

}

nextPayeeIndex = i;

}3.2 所有者操作

在代币合约中，通常都有一个 owner 账户，也就是合约所有者账户，其拥有开启/暂停交易的权限，如果 owner 地址丢失，从而使得整个代币合约无法被操作，导致非主观的拒绝服务攻击。

bool public isFinalized = false;

address public owner; // 合约所有者

function finalize public {

require(msg.sender == owner);

isFinalized == true;

}

// ... 额外的一些 ICO 功能

// 重写 transfer 函数，先检查 isFinalized

function transfer(address _to, uint _value) returns (bool) {

require(isFinalized);

super.transfer(_to,_value)

}

在上面的合约中代币系统的全部运作都只取决于一个地址，那就是 owner 地址，在 ICO 结束后，如果特权用户丢失，其私钥可能会变为非活动状态，此时，无法调用 finalize函数开启交易，那么用户就一直不能发送代币，合约也就不能进行正常操作了。

针对以上情况，合约不应该将整个代币系统都只取决于一个 owner 地址，可以设置多个权限用户地址，也可以设置暂停交易的时间，超过时间或满足某个条件时开启交易，这样整个代币系统就不会被拒绝服务攻击了。下面的代码可以作为参考，来防止所有者操作而造成的拒绝服务攻击。

require(msg.sender == owner || now > unlockTime)3.3 基于外部调用的进展状态

如果智能合约的状态改变依赖于外部函数执行的结果，但又未对执行一直失败的情况做出防护，此时如果外部调用失败或者由于外部原因而被拒绝时，就可能会造成拒绝服务攻击。

比如用户创建一个不接受以太币的合约（非 payable 属性），如果正常的合约需要发送以太币到不接受以太币的合约中才能进入到一个新的状态，那么合约就会被拒绝而达不到新的状态。

pragma solidity ^0.4.22;

contract Auction {

address public currentLeader; // 当前竞拍者

uint256 public highestBid; // 最高竞拍价

function bid public payable {

require(msg.value > highestBid); // 交易携带的以太币大于当前的 highestBid

require(currentLeader.send(highestBid)); // 将当前的 highestBid 退还给当前的竞拍者 currentLeader

currentLeader = msg.sender; // 设置新的竞拍者为消息调用者 msg.sender

highestBid = msg.value; // 设置新的最高竞拍价 为 msg.value

}

}

上面的合约就是一个简单的竞拍合约，说下大致的流程，用户执行 bid函数时如果携带的以太币大于当前的 highestBid，那么 highestBid 所对应的以太币就会退还给当前的竞拍者 currentLeader，然后设置新的当前竞拍者为调用的用户，highestBid也设置为用户发起交易时携带的以太币。看着合约代码好像没有什么问题，但是当恶意攻击者部署如下攻击合约时，通过合约来竞拍将会出现问题。

pragma solidity ^0.4.22;

interface Auction{ // 设置原合约接口，方便调用函数

function bid external payable;

}

contract POC {

address owner;

Auction auInstance;

constructor public {

owner = msg.sender;

}

modifier onlyOwner {

require(owner==msg.sender);

_;

}

function setInstance(address addr) public onlyOwner { // 指向原合约地址

auInstance = Auction(addr);

}

function attack public onlyOwner {

auInstance.bid.value(msg.value);

}

function external payable{

revert;

}

}

攻击者先通过攻击合约调用 bid 函数向竞拍合约转账成为新的竞拍者 currentLeader，然后新的 bid 函数被执行进行竞标的时候，当执行到 require(currentLeader.send(highestBid))退还以太币操作时，会因为攻击合约的 fallback回退函数执行 revert而无法接收以太币，导致一直为 false，其他竞拍者竞拍都会失败，最后攻击合约以较低的以太币赢得竞拍。

针对以上情况，如果需要对外部函数调用的结果进行处理后才能进入新的状态，那么一定要考虑外部调用可能一直失败的情况，也可以添加基于时间的操作，防止外部函数调用一直失败无法满足 require 判断。

相关案例 4.1 演示案例

接下来会对拒绝服务攻击做出详细的演示讲解，以及会附上一个实例进行说明。

下面的合约代码是根据漏洞分析中第三点基于外部调用的进展状态讲的合约改的，正常的操作逻辑是任何出价高于当前合约 price 的都能成为新的 president，合约中存款也会通过 transfer函数转账以太币退还给上一个 president，这么看的话是没有任何问题的，但是以太坊是有两种账户类型，外部账户和合约账户，如果发起 becomePresident调用的是外部账户那就是正常的操作，但如果发起 becomePresident调用的是合约账户，并且在合约账户的 fallback函数中恶意的使用 revert等报错的函数，那么其他用户在发起 becomePresident时退还以太币给合约账户时会触发 fallback函数而导致报错，无法再正常进行 becomePresident中的逻辑成为新的 president了。

那么我们先来看下存在问题的合约代码，这里我们将合约代码设置为 PresidentOfCountry.sol：

pragma solidity ^0.4.19;

contract PresidentOfCountry {

address public president; // 总统地址

uint256 price; // 出价

function PresidentOfCountry(uint256 _price) { // 构造函数，设置初始的价格

require(_price > 0);

price = _price; // 设置初始的价格

}

function becomePresident payable { // 竞争总统

require(msg.value > price); // 支付的以太币必须大于当前总统的竞争费

president.transfer(price); // 退还以太币给上一任总统

president = msg.sender; // 设置新的总统为竞争成功用户

price = price; // 设置最新的竞争价格

}

}

在编写攻击合约之前，我们先来介绍下智能合约的两种账户类型以及 fallback 函数。

以太坊中有两种账户类型：

• 外部账户（externally owned accounts），也就是用户账户，由私钥控制。
• 合约账户（contract accounts），可执行代码和私有状态，由合约代码控制。

回退函数 (fallback function)：回退函数是每个合约中有且仅有一个没有名字的函数，并且该函数无参数，无返回值，如下所示：

function public payable{

...

}

回退函数在以下几种情况中被执行：

• 调用合约时没有匹配到任何一个函数；
• 没有传数据；
• 智能合约收到以太币（为了接受以太币，fallback 函数必被标记为 payable）。

下面就来编写攻击合约，主要有两个重点，一个是外部调用 becomePresident，二个就是在回退函数中使用 revert。

pragma solidity ^0.4.19;

import "./PresidentOfCountry.sol";

contract Attack {

function Attack(address _target) payable { // 构造函数，设置目标合约地址，用 call 进行外部调用 becomePresident

_target.call.value(msg.value)(bytes4(keccak256("becomePresident")));

}

function payable { // 回退函数，使用 revert 报错

revert;

}

}

在 Remix中进行调试查看结果，首先使用账户 (0x5B38Da6a701c568545dCfcB03FcB875f56beddC4) 设置初始竞争价格并部署漏洞合约代码 PresidentOfCountry.sol。

部署好后合约的地址为 0xd9145CCE52D386f254917e481eB44e9943F39138，后面在部署攻击合约时需要用到。

点击 president可以查看当前竞争者的地址。

使用账户 (0x5B38Da6a701c568545dCfcB03FcB875f56beddC4) 调用 becomePresident并携带 1 eth，执行成功后再点击 president查看，发现新的总统地址已经变成了 0X5B 的账户。

此时有一个攻击者 (0xAb8483F64d9C6d1EcF9b849Ae677dD3315835cb2) 编写了一个攻击者合约 Attack.sol，携带 2 eth（因为成为新的总统必须要大于当前总统的竞争价格，当前为 1 eth）并设置 _target为 PresidentOfCountry合约地址 (0xd9145CCE52D386f254917e481eB44e9943F39138) 进行部署。

部署好后的攻击合约地址为 0xa131AD247055FD2e2aA8b156A11bdEc81b9eAD95，此时再点击 president进行查看新总统的地址，发现已经是攻击合约的地址了。

之后如果还有其他用户想来竞争总统位置，就需要大于 2 eth的价格去调用 becomePresident函数，这里有个用户 (0xCA35b7d915458EF540aDe6068dFe2F44E8fa733c) 想去竞争总统，携带 3 eth去调用 becomePresident，结果发现报错并回退，点击 president 发现总统地址还是攻击合约没，此时不管是谁使用多少的以太币去调用 becomePresident，结果都是失败，该合约已经不能进行正常的操作，这就说明合约受到了拒绝服务攻击。

4.2 真实案例

下列代码是实际合约中存在拒绝服务攻击的案例，只写了关键的代码并做了相关的改动。可以看到合约的关键代码是用作提款操作，但是在提款中有一个判断要提款的金额和用户在该合约中存款的数量是否相等，而并不是大于等于，那么就有可能发生当用户要提出 amount数量的代币时，由于各种原因（他人转账、奖励分配等使得用户在合约中的存款代币余额发生变化）导致 balances[msg.sender]变动，甚至是用户不想全部提款，从而使得判断条件 require(balances[msg.sender] == amount);不成立，这时就会造成短暂的拒绝服务攻击。

...

function withdraw(uint256 amount) public { // 提款 amount 数量

require(balances[msg.sender] == amount); // 检查要提款的金额是否等于该用户在合约中的存款

balances[msg.sender] -= amount; // 修改合约中存款的状态变量

msg.sender.transfer(amount); // 转账到用户账户

}

而修改的办法就是将判断条件 require(balances[msg.sender] == amount);修改为 require(balances[msg.sender] >= amount);就可以了。

4.3 历史案例

在历史上，2016 年 2 月 6 日至 8 日，在游戏 KotET(King og the Ether Throne) 的「Turbulent Age」期间，就遭受到了拒绝服务攻击，导致部分角色的补偿和未接收款项无法退回玩家的钱包中。

同年 6 月，GovernMental 合约也遭受到了拒绝服务攻击，当时 1100 个以太币通过使用 250 万个 gas 交易而获得，这笔交易超出了合约能负荷的 gas 上限，从而导致交易暂停。

相关的还有 Fomo 3D 等的拒绝服务攻击。

解决办法

通过上面的讲解，我们可以发现拒绝服务攻击在智能合约中的影响也是非常严重的，所以针对拒绝服务攻击，合约开发者应该针对上面漏洞分析时讲到的三种情况进行相应的代码修改。比如对于外部操作的映射或者数组循环，需要对长度进行限制等；

而对于所有者操作需要考虑合约的非唯一性，不要使得合约因为某个权限账户而导致整个业务瘫痪；基于外部调用的进展状态需要对函数的调用进行异常处理，一般来说内部函数的调用不会造成危害，如果调用失败也只是会进行回退，而外部调用具有不确定性，我们不知道外部调用者想干什么，如果被攻击者攻击，就可能会造成严重的后果，具体表现为恶意返回执行错误，造成正常代码无法执行，从而造成拒绝服务攻击，那么针对这种开发者就应该加入函数执行异常的处理机制。

总的来说，合约开发者需要考虑合约代码的代码逻辑全面性和缜密性等，这样才能更好的杜绝拒绝服务攻击。

参考文献

作者：创宇区块链安全实验室；来自链得得内容开放平台“得得号”，本文仅代表作者观点，不代表链得得官方立场凡“得得号”文章，原创性和内容的真实性由投稿人保证，如果稿件因抄袭、作假等行为导致的法律后果，由投稿人本人负责得得号平台发布文章，如有侵权、违规及其他不当言论内容，请广大读者监督，一经证实，平台会立即下线。如遇文章内容问题，请联系微信：chaindd123。