‘冰封’合约背后的老牌劲敌，拒绝服务漏洞

文章来源：链安科技

火讯财经注：链圈币圈行进的步伐越来越急促，安全漏洞成为重大隐患。当务之急是加固安全程序合约，防患于未然。

我们将当时的拒绝服务攻击事件挖掘出来，并将原理分析和漏洞修复技巧与大家分享，时刻牢记过去的教训。

无论是蓄意破坏交易正常流程还是阻塞交易通道，都用到了一个互联网时代已经盛行已久的攻击方式——DoS，也就是我们所说的拒绝服务攻击。这种攻击方式可以让合约执行的正常的交易操作被扰乱，中止，冻结，更严重的是让合约本身的逻辑无法运行。

 何为DoS

DoS 是DenialOfService，拒绝服务的缩写，从字面上来理解，就是用户所需要的服务请求无法被系统处理。

打个比方来形容DoS，火车站是为大家提供乘车服务的，如果想要DoS火车站的话，方法有很多，可以占用过道不上车，堵住售票点不付钱，阻挠列车员或者司机不让开车，甚至用破坏铁轨等更加极端的手段来影响车站服务的正常运营。

过去针对互联网的DoS有很多种方法，但基本分为三大类：利用软件实现的缺陷，利用协议的漏洞，利用资源压制。

此外还有DDoS，称为分布式DoS，其区别就是攻击者利用远程操控的计算机同时向目标发起进攻，在上面的比喻中可以理解为雇佣了几百个地痞流氓来做同样的事影响车站的运作。

智能合约DoS攻击原理分析及相应漏洞修复

无处不在的DoS当然也会对基于Solidity语言的以太坊合约产生威胁。

针对智能合约的DoS攻击属于利用协议漏洞进行的手段，具体的攻击方法有三种[4]，其目的是使合约在一段时间或者永久无法正常运行。通过DoS攻击，可以使合约中的Ether永远无法提取出来，区块成为“冰冻废土”。

在对于原始代码进行分析后，我们发现KotET事件中对君王称号进行锁定的DoS攻击属于：

1. 通过(Unexpected) Revert发动DoS

如果智能合约的状态改变依赖于外部函数执行的结果，又未对执行一直失败的情况做出防护，那么该智能合约就可能遭受DOS攻击[5]。

我们使用案例合约还原KotET的竞拍机制，进行模拟分析：

以上案列合约是一个简化版的KotET的竞拍争夺王位的合约，如果当前交易的携带的ether大于目前highestBid，那么highestBid所对应的ether就退回给currentLeader，然后设置当前竞拍者为currentLeader，currentLeader改为msg.value。但是当恶意攻击者部署如下图所示合约，并通过合约来竞拍将会出现问题，：

攻击者先通过攻击合约向案例合约转账成为currentLeader，然后新的bider竞标的时候，执行到require(currentLeader.send(highestBid))会因为攻击合约的fallback()函数（这里指function（）external payable函数）无法接收ether而一直为false，最后攻击合约以较低的ether赢得竞标。

漏洞修复

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

对GovernMental事件中交易的gas值远远超出天际的原理分析，其属于通过区块Gas Limit发动DoS。

2.  通过区块Gas Limit发动DoS

一次性向所有人转账，很可能会导致达到以太坊区块gas limit的上限。以太坊规定了每一个区块所能花费的gas limit，如果超过交易便会失败。

即使没有故意的攻击，这也可能导致问题。然而，最为糟糕的是如果gas的花费被攻击者操控。在先前的例子中，如果攻击者增加一部分收款名单，并设置每一个收款地址都接收少量的退款。这样一来，更多的gas将会被花费从而导致达到区块gas limit的上限，整个转账的操作也会以失败告终。如以下简化版案例合约所示：

这个案例合约遍历可被人为操纵的investors[]数组。攻击者可以创建许多账户，使得investors[]数组变的很大，使得执行for循环所消耗的gas超过块gas极限，使得distribute函数一直处于out-of-gas（OOG）状态，而一直无法执行成功，合约正常功能实现受到影响。

漏洞修复

合约不应该循环对可以被外部用户人为操纵的数据结构进行批量操作，建议使用取回模式而不是发送模式，每个投资者可以使用withdrawFunds取回自己应得的代币；

如果实在必须通过遍历一个变长数组来进行转账，最好估计完成它们大概需要多少个区块以及多少笔交易。然后你还必须能够追踪得到当前进行到哪以便当操作失败时从那里开始恢复，举个例子：

3. 所有者操作发动DoS

另外， 我们联系之前提到的Owner权限过大，“超中心化”的问题，发现目前很多代币合约都有一个Owner账户，其拥有开启/暂停交易的权限，如果对owner保管不善，代币合约可能被一直冻结交易，导致非主观的拒绝服务攻击，例如如下owner权限中的功能：

此owner权限的局限性在于，在ICO结束后，如果特权用户丢失其私钥或变为非活动状态，Owner无法调用finalize()，用户则一直不可以发送代币，即令牌生态系统的整个操作取决于一个地址。

漏洞修复

可以设置多个拥有owner权限的地址，或者设置暂停交易的期限，超过期限就可以恢复交易，如：require(msg.sender == owner || now > unlockTime)

以铜为镜，可以正衣冠；以古为镜，可以知兴替；以人为镜，可以明得失

1. 对于调用外部函数的代码一定要考虑周全，对于例外情况的判定要加入代码中。

2. 遍历变长数组来逐个支付的方法需要全方位考虑和估计。合约中不应存在外部人员操纵的成分。

3. 强调再三的去中心化特征也应该应用到Owner权限这个概念上来。

从被DoS到交易系统异常，到项目被冰封直至被遗忘，以上的例子也经历了互联网发展初期所遭受的苦难，但是只要我们铭记教训，就能稳固地保持区块链技术的发展。