EOS DDOS攻击，你想不到的这12小时

    首先你看到此文时，说明我已将该攻击告知主网，他们已经应用了新patch来应对此类攻击，所以大家不要想多了O(∩_∩)O~。

    由于该攻击和开奖交易阻塞攻击有渊源，因而也提下前天的开奖交易阻塞攻击。

 

开奖交易阻塞攻击

 

    该攻击方法的核心是在下注时发起大量delaytime=0的恶意延迟交易，由于EOS执行交易采用FIFO策略，这些延迟交易肯定在开奖交易之前执行。这些延迟交易会在接下来的每个区块执行，在执行时会预测是否中奖，如果中奖就取消其他延迟交易，让开奖交易被执行。否则不作处理，BP会继续执行其他延迟交易，从而导致开奖交易没法被执行，被推迟到下一个区块。只要这些恶意延迟交易足够多，开奖交易会被一直阻塞，直到攻击者中奖。所以核心是延迟交易和cancel动作。

    但是还有一个问题就是如何检测是否中奖？这里有两种方法

    1）破解随机数算法，如果随机数中有时间因子，阻塞延迟开奖，尝试生成不同的时间因子并预测，自然可以攻击成功。目前各家安全团队都在强调不引入时间因子来防御就是这个。

    2）攻击者部署一模一样的菠菜合约，攻击者在恶意延迟交易里调用模拟的菠菜合约检测中奖结果进而能够预测结果，且不需要知道具体随机数算法。这个完全没法防。唯一可以减少被攻击概率的方法是在菠菜合约里hardcode自己合约account,并require_auth检测。这样攻击者必须修改合约才能成功。当然EOS系统是有办法的，比如限制这些恶意defer transaction, 具体怎么做的，需要看看最新的patch。

    这里攻击是比较容易发现的，因为这些defer transaction保存在链上了。

 

DDOS攻击

 

    首先该攻击还未曾被爆出过攻击案例，我们仅仅进行了测试并确认了该漏洞然后上报给了block.one，是主动发现。当然，我们分享给其他安全团队后，然后漏洞被曝光，然后该漏洞就可能被利用了，甚至有可能很早就被攻击者偷偷的使用(比如前面几次模拟两可无法完全重现的攻击)。

    DDOS攻击的核心是发起死循环交易，由于EOS限制一个transaction最长执行时间为10ms,  超时后就会报错，由于该交易报错失败，从而不消耗任何CPU资源，从而该攻击无成本。无成本才是恐怖的，因为无成本，攻击者可以一直占用主网的CPU，进而会导致全网长时间瘫痪，这才叫DDOS攻击。如果是有成本攻击，攻击者只能短时间阻塞其他正常交易。所以DDOS攻击的核心是无成本

    同时，EOS对于大量死循环超时交易处理不够，且超时处理自身需要消耗CPU，从而导致BP的最后一个块没法及时广播到下一个BP，进而会出现大量微分叉。

    到这里，你可能会说，这个攻击方式很简单啊，应该很早就有类似攻击并被发现啊。这说对了一半，在EOS刚运行时，用户通过cleos发起死循环交易确实是凑效的，但是后来所有BP节点的API Node防御到位增强后，几乎没有什么效果了。

   API Node防御是怎么回事呢？这得从交易执行流程说起。用户发起交易到被BP执行，其实大致经历了如下几个过程。

    

    那攻击者是否可以直接推送恶意交易给bp node呢？理论上可行，但是由于bp node属于EOSIO网络核心层，做了一些防范措施，相对还是不容易的，所以没法持续攻击，效果也不好（一个BP会有至少一个API Node+ BP Node)。

    既然有API Node防护了，今天的这个DOS攻击又是如何发起的呢？

    很简单，通过deferred transaction, 攻击者先发起一个合法交易，然后合法交易就会成功执行并被广播进入BP Node, 由于这个合法交易会发起死循环的defer交易，从而BP Node在执行这个合法交易的时候也会生成这些死循环的恶意交易，因而死循环恶意交易进入网络核心层，大量吞噬了出块节点的CPU。

        

    这类攻击中的defer transaction会因超时失败，因而不会保存在链上，因而这类攻击具备很强的隐蔽性，很难被发现和完整还原。因此我猜测上个月的所谓利用”黑名单账号”回滚攻击DApp也只是猜想而已，不一定是事实。因为当时的攻击账号中用到的黑名单账号并没有被验证，只是各种安全团队的探索性尝试而已，但是“黑名单账号攻击”确实可行合理，因而被当做最终解读。利用该DDOS攻击可以实现上次的攻击，同时，上面的“开奖交易阻塞攻击”使用该DDOS攻击方法后，无攻击成本且隐蔽性增强。

   

具体攻击代码如下，非常简单：

 

完整源码请看

https://github.com/itleaks/eos-contract/tree/master/ddos-exp

 

测试结果

 

    用少量死循环延迟交易的测试结果如下，立马有部分节点不执行正常交易，TPS下降厉害。

     过了一小段时间恢复正常

微分叉和丢块也非常多，且大部分都是0交易的块。

 

解决建议

 

    1）增加交易执行顺序的随机性

            比如以太坊就是交易费高的先执行，由于这个交易费是交易发起者用户设置的，自然是随机的，不可预测的。

    2）增加执行超时交易成本

            目前交易执行超时不会消耗任何CPU，可以考虑超时执行的交易也消耗CPU，这就要求这些超时交易记录在链上，同时可以增加透明性

    3)  限制延迟交易执行时间

个人能力有限，本文的分析可能有不足或者错误的地方，欢迎大家告知

|**************************************************
* 本文来自CSDN博主"爱踢门"，喜欢请点关注
* 转载请标明出处:http://blog.csdn.net/itleaks
***************************************************|