查看原文
其他

干货 | Solidity 安全:已知攻击方法和常见防御模式综合列表,Part-6:拒绝服务、时间戳攻击

Adrian Manning 以太坊爱好者 2019-01-22

Solidity 安全系列

Part-1:可重入漏洞、算法上下溢出
Part-2:不期而至的 Ether、Delegatecall
Part-3:默认可见性、随机数误区
Part-4:外部合约引用、短地址攻击
Part-5:未检查的 Call 返回值,条件竞争


1 拒绝服务


这个类别非常广泛,但其基本攻击形式都是让用户短暂地(在某些情形下,是永久)推出不可操作的合约。这种攻击可以把 Ether 永远锁在被攻击的合约中,正如 Parity 多签名钱包第二次被黑中的情形一样。


1.1 漏洞

有很多办法可以让合约变得不可操作。这里我只强调一些微妙的区块链 Solidity 编码模式,虽然看不太出来,但可能留下让攻击者执行 DOS 攻击的空间。

1.通过外部操纵映射或数组(Array)循环 ——在我的经历中,我看过此种模式的各种形式。通常情况下,它出现在 owner 希望在其投资者之间分配代币的情况下,以及,在合约中可以看到类似于 distribute() 函数的情况下:

contract DistributeTokens {    address public owner; // gets set somewhere    address[] investors; // array of investors    uint[] investorTokens; // the amount of tokens each investor gets    // ... extra functionality, including transfertoken()    function invest() public payable {        investors.push(msg.sender);        investorTokens.push(msg.value * 5); // 5 times the wei sent        }    function distribute() public {        require(msg.sender == owner); // only owner        for(uint i = 0; i < investors.length; i++) {            // here transferToken(to,amount) transfers "amount" of tokens to the address "to"            transferToken(investors[i],investorTokens[i]);        }    } }


请注意,此合约中的循环遍历的数组可以被人为扩充。攻击者可以创建许多用户帐户,让 investor 数据变得更大。原则上来说,可以让执行 for 循环所需的 Gas 超过区块 Gas 上限,这会使 distribute() 函数变得无法操作。

2.所有者操作——另一种常见模式是所有者在合约中具有特定权限,并且必须执行一些任务才能使合约进入下一个状态。例如,ICO 合约要求所有者 finalize() 签订合约,然后才可以转让代币,即:

address public owner; // gets set somewhere function finalize() public {    require(msg.sender == owner);    isFinalized == true; } // ... extra ICO functionality // overloaded transfer function function transfer(address _to, uint _value) returns (bool) {    require(isFinalized);    super.transfer(_to,_value) }


在这种情况下,如果权限用户丢失其私钥或变为非活动状态,则整个代币合约就变得无法操作。在这种情况下,如果 owner 无法调用 finalize() 则代币不可转让;即代币系统的全部运作都取决于一个地址。

3.基于外部调用的进展状态——有时候,合约被编写成为了进入新的状态需要将 Ether 发送到某个地址,或者等待来自外部来源的某些输入。这些模式也可能导致 DOS 攻击:当外部调用失败时,或由于外部原因而被阻止时。在发送 Ether 的例子中,用户可以创建一个不接受 Ether 的合约。如果合约需要将 Ether 发送到这个地址才能进入新的状态,那么合约将永远不会达到新的状态,因为 Ether 永远不会被发送到合约。


1.2 预防技术

在第一个例子中,合约不应该遍历可以被外部用户人为操纵的数据结构。建议使用 withdrawal 模式,每个投资者都会调用取出函数独立取出代币。

在第二个例子中,改变合约的状态需要权限用户参与。在这样的例子中(只要有可能),如果 owner 已经瘫痪,可以使用自动防故障模式。一种解决方案是将 owner 设为一个多签名合约。另一种解决方案是使用一个时间锁,其中 [13]行 上的需求可以包括在基于时间的机制中,例如 require(msg.sender == owner || now > unlockTime) ,那么在由 unlockTime 指定的一段时间后,任何用户都可以调用函数,完成合约。这种缓解技术也可以在第三个例子中使用。如果需要进行外部调用才能进入新状态,请考虑其可能的失败情况;并添加基于时间的状态进度,防止所需外部调用迟迟不到来。

注意:当然,这些建议都有中心化的替代方案,比如,可以添加 maintenanceUser ,它可以在有需要时出来解决基于 DOS 攻击向量的问题。通常,这类合约包含对这类权力实体的信任问题;不过这不是本节要探讨的内容。


1.3 真实的例子:GovernMental

GovernMental是一个很久以前的庞氏骗局,积累了相当多的 Ether。实际上,它曾经积累起 1100 个以太。不幸的是,它很容易受到本节提到的 DOS 漏洞的影响。这篇 Reddit 帖子描述了合约需要删除一个大的映射来取出以太。删除映射的 Gas 消耗量超过了当时的区块 Gas 上限,因此不可能撤回那 1100 个 Ether。合约地址为 0xF45717552f12Ef7cb65e95476F217Ea008167Ae3,您可以从交易0x0d80d67202bd9cb6773df8dd2020e7190a1b0793e8ec4fc105257e8128f0506b中看到,最后有人通过使用 250 万 Gas的交易取出了 1100 Ether 。


2 操纵区块时间戳


区块时间戳历来被用于各种应用,例如随机数的函数(请参阅随机数误区以获取更多详细信息)、锁定一段时间的资金、以及各种基于时间变更状态的条件语句。矿工有能力稍微调整时间戳,如果在智能合约中错误地使用区块时间戳,可以证明这是相当危险的。

一些有用的参考资料是:Solidity Docs,以及这个 Stack Exchange 上的问题。


2.1 漏洞

block.timestamp 或者别名 now 可以由矿工操纵,如果他们有这样做的激励的话。让我们构建一个简单的、容易受到矿工的剥削的游戏,

roulette.sol :

contract Roulette {    uint public pastBlockTime; // Forces one bet per block    constructor() public payable {} // initially fund contract    // fallback function used to make a bet    function () public payable {        require(msg.value == 10 ether); // must send 10 ether to play        require(now != pastBlockTime); // only 1 transaction per block        pastBlockTime = now;        if(now % 15 == 0) { // winner            msg.sender.transfer(this.balance);        }    } }


这份合约是一个简单的彩票。每个区块都有一笔交易可以下注 10 Ether,获得机会赢取合约中的全部余额。这里的假设是, block.timestamp 的最后两位数字是均匀分布的。如果是这样,那么将有 1/15 的机会赢得这个彩票。

但是,正如我们所知,矿工可以根据自己的意愿调整时间戳。在这种特殊情况下,如果合约中有足够的 Ether,挖出某个区块的矿工将被激励选择一个 block.timestamp 或 now 对 15 取余为 0 的时间戳。在这样做的时候,他们可能会赢得这个合约中的 Ether 以及区块奖励。由于每个区块只允许一个人下注,所以这也容易受到抢先提交攻击。

在实践中,区块时间戳是单调递增的,所以矿工不能选择任意块时间戳(它们必须大于其祖先块)。区块时间也不能是未来值,因为这些块可能会被网络拒绝(节点不会验证其时间戳指向未来的块)。


2.2 预防技术

区块时间戳不应该用于熵源或产生随机数——也就是说,它们不应该是游戏判定胜负或改变重要状态(如果假定为随机)的决定性因素(无论是直接还是通过某些推导)。

时效性强的逻辑有时是必需的;即解锁合约(时间锁定),几周后完成 ICO 或到期强制执行。有时建议使用 block.number(参见 Solidity 文档)和平均区块时间来估计时间;即,10 秒的区块时间运行 1 周,约等于,60480 个区块。因此,指定区块编号来更改合约状态可能更安全,因为矿工无法轻松操纵区块编号。BAT ICO合约就采用这种策略。

如果合约不是特别关心矿工对区块时间戳的操纵,这可能是不必要的,但是在开发合约时应该注意这一点。


2.3 真实的例子:GovernMental

GovernMental 是一个很久以前的庞氏骗局,积累了相当多的 Ether。它也容易受到基于时间戳的攻击。合约会在一轮内支付给最后一个加入合约的玩家(需要加入至少一分钟)。因此,作为玩家的矿工可以调整时间戳(未来的时间,使其看起来像是一分钟过去了),以显示玩家加入已经超过一分钟(尽管现实中并非如此)。关于这方面的更多细节可以在 Tanya Bahrynovska 的 以太坊安全漏洞史 中找到。


原文链接

https://blog.sigmaprime.io/solidity-security.html
作者: Dr Adrian Manning
翻译&校对: 爱上平顶山@慢雾安全团队 & keywolf@慢雾安全团队

本文由慢雾安全团队翻译。这里是最新译文的 GitHub 地址:https://github.com/slowmist/Knowledge-Base/blob/master/solidity-security-comprehensive-list-of-known-attack-vectors-and-common-anti-patterns-chinese.md

EthFans 经授权转载。


你可能还会喜欢:

干货 | 以太坊智能合约安全

干货 | Verge 攻击解析,Part-1

干货  | 以太坊设计原理




    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存