黑客来袭，让你深挖区块链安全漏洞

目前，区块链漏洞安全问题频发。

区块链行业面临私钥生成与保护、共识过程中心化、智能合约代码漏洞、签名过程算法漏洞、系统实现代码漏洞等安全问题。 针对以上问题，开发者应该如何应对，避免漏洞频发？ 羊毛布？

以下为CSDN主办，区块链大本营、百联道杰、极客帮创投协办的技术沙龙吴嘉智演讲内容。 区块链大本营不改初衷，精心组织。

先自我介绍一下，我叫吴嘉智，现任派盾研发副总裁。 今年年初我们转投区块链领域。 事实上，我们在创业初期也做了一些其他的尝试。 在此之前，我的工作比较偏向于操作系统安全，主要是Android方向，比如360 C0RE Team和360 Super ROOT。 我在360期间开发的产品。

目前区块链发展趋势如何？ 查看数据，蓝线代表创建的智能合约数量的趋势。

可以看到，去年9月，智能合约数量急剧下降。 年底各种ICO的出现，导致智能合约的数量大幅增加。 今年2月，出现明显下滑。 过去二、三月也在下降，但到了七月又开始回升。 其中的缘由在场的人都知道，就不多说了。

而且，至少从2017年下半年到今年年初，由于DApp在区块链各个行业的不断落地，行业形势看起来非常好。

区块链如此火爆，投资者会投入大量资金购买和炒币……

但是在我们安全研究人员的眼里，它其实是一个黑客非常感兴趣的目标。

从2014年的Mt.Gox事件到今年这个时候，已经发生了多起区块链安全事件。 比如今年4月份的BEC智能合约漏洞事件，5月份的EDU事件比特币签名漏洞，还有最近的交易所被黑，安全事件还有很多很多。

这种安全问题，造成的后果很严重，你的钱真的没了。 不像是手机里的照片，窃取隐私之类的，这根本就不是一个级别的。

今天主要讲两个话题，智能合约安全和公链安全。

简单解释：Fomo 3D漏洞

先说说智能合约相关的安全问题。 F3D最近很火，有很多有趣的东西。 就在 6 天前，我们进行了一项相对较新的研究......

微博：

故事是这样的。 7月23日晚上8点左右，在微博上发现了一条关于F3D的信息。 GETH客户端开发组组长，以太坊核心成员Peter，发现一个空投的F3D( )题，引起了我的兴趣，于是我们就去分析。

这件事很有意思。 首先看右边的蓝色方框。 它是 F3D 的智能合约之一。 它实际上有很多合同。 今天我只讲其中的一个。

其中之一是空投（）。 你可以理解为它使用了彩票抽奖机制。 假设你赌F3D，不管你买了多少钥匙，买了之后都会有一个小概率事件让你中奖，然后你就会有额外的奖励。 我觉得这样的设计也挺合理的，可以积极参与用户的参与。

0.1 ETH 是 F3D 的最低奖金。 有人故意用最低的投资来换取现金，他只需要操作一点钱就有机会获胜。 最后，智能合约中的 withdraw() 函数提取资金。

我们先来看看函数airdrop()。 有一个名为种子的变量。 种子是随机数中一个非常重要的概念。 计算机世界没有绝对的随机数。 您只能通过种子生成一个相对的。 随机数。

一旦你可以通过某种方式预测种子值，这个随机事件实际上就会从小概率事件变成大概率事件。

比如我刚开始学编程的时候比特币签名漏洞，刚开始学C的时候，我是用random()函数来获取随机数的。 那个时候不知道种子，所以会传null或者zero进去，然后发现每次跑都会是一样的结果。

这个黑客找到了一个方法。 他每次下注，都预示着这里会开奖，100%的彩票都会被抽中。 确认之后，他再将这笔钱投入，这样每次都能从中套现。

告诉我这东西是怎么预测的？ 其实它的实现是这样的。 可以看到seed操作有几个关键点，timestamp，difficulty，coinbase，gaslimit，number。

另一个特别的东西是 airDropTracker_。 其实这些都是合约里面的值。 你可以随时把它们读出来，这样你就可以认为以上所说的都是已知的，唯一不能预知的。 这是消息。 发件人。

当时，Peter 认为 F3D 团队假设 msg.sender 的随机性就足够了。 其实msg.sender就是你进入合约时的钱包地址。 F3D团队认为不可能让你生成大量的钱包来尝试，然后让种子可用。 预测，但不仅是从钱包，还有另一个合约，这其实是关键。

这就涉及到另一种算法。 有一个函数叫isHuman()来判断是真人钱包还是其他合约，但是问题是这个判断有错误，就是Extcodesize()。

你可以使用智能合约不断刷airdrop()，这和挖矿的过程很相似，因为智能合约产生的新合约地址是可以预测的，所以你可以一直计数，直到得到一个种子结果时 return(true ）满意，保证中奖。

一旦智能合约调整了constructor()中isHuman()的判断，就会出现误判，进而造成人为的开奖结果。

因此，就会有这样一种攻击模式&mDASH;——首先可以生成多个合约，然后会一直计算，直到可以保证某个合约X能够与当前airDropTracker_匹配，然后根据合约X来打赌，你可以一直拿走资金池中的所有资金。

但其实对于F3D来说，这并不是什么大问题。 因为被攻击的资金池只是整个F3D红利环节的一小部分。

所以，就好像你玩某个游戏，有个金手指，每次攻击力增加9，保证你能把人砍死。 大概是这样吧，有点像破坏了游戏的平衡，但实际上却影响了整个游戏。 影响不会太大，比如带走大家的个人资产。

其他智能合约相关漏洞

接下来，我将谈谈与智能合约安全相关的其他一些问题。

有一种与津贴有关的问题。 比如ERC20里面有一个标准的API叫transferFrom()，它可以让别人把你的钱转走，但是前提是已经提前声明了。 在哪里申报？ 它在 allowed[] 数组中。

这里有一个问题。 虽然它可以让你转钱出去，但是它不能判断你要转多少钱。 实际上，它只是切断了津贴。 这是代码中的错误，EDU问题属于此类。

这是我做的实验，我隐瞒了一些信息。

最上面0xd开头的值是我的一个钱包地址，然后To指向被我攻击的合约地址。 攻击完成后，我将0xa地址中的一个EDU，也就是多个0后带1的那个EDU，转移到0x6地址，其实0x6也是我的钱包地址。

输入数据部分是一些攻击的细节。 其实这个结构很简单。 你只需要调用 transferFrom() 函数，然后你传入 from、to 和 value。 所以，我偷了一个 EDU 到我的钱包里，这次攻击是这样的。

下面以batchTransfer()为例说一下溢出相关的漏洞，它的攻击就是这样完成的。

在调用batchTransfer()函数时，有两个参数可以传入，一个是receivers，一个是value。

receivers 是一个数组，传入数字40，代表偏移量，需要传递给智能合约。 然后是下面以2或8开头的那些。

这个逻辑是这样的。 在batchTransfer()的实现中，将8开头后面全0的值同时转给两个人。

如果按照一般的逻辑理解的话，账户里肯定有足够的钱才能转账。 但是问题是它在实现校验的时候，它的实现方式是直接计算两个数的乘积。

和0相乘，结果很明显，即使你和最大的字节相乘，相乘后也会变成0。

所以，你可以在没有钱的情况下给那两个人转那么多钱，也就是上面红框里的部分，你会看到这个地方的两次转账都是这么大笔的Token。 这样一来，就可以无中生有地制造出大量的假币，然后将假币充值到okex中，再进行砸币等各种操作。

另一种情况与转移非常相似，但稍微复杂一些。 地址和值都是数组。

它们溢出的方式是一样的，就是把这些值相加或者相乘，结果是一样的，就是大量的假币充入你的钱包地址。

至此，我简单的讲了智能合约的安全问题，其中一个是F3D的羊毛的最新研究，以及我们过去发现的一些其他问题。

公链安全

今天的第二个话题，讲一下Infrastructure的安全问题，也就是所谓的公链安全。

PeckShield对以太坊公链做了很多研究，也有一些与EOS有关。

说到公链问题，其实可以这么理解。 比如你用360手机卫士，可以理解为手机上运行着一个客户端，然后就是各种服务器端。 你要发送各种请求，然后它会推送一些信息给你。

在区块链中，你可以理解为只有客户端，没有服务器，至少在以太坊上是这样，每个节点看起来基本一模一样。

所以，当我们开始进入区块链行业，研究主链的安全性时，其实是把所有的客户端代码都看一遍，看看它实现的逻辑有没有错误。

这是一个统计数据。 以太坊节点网站可以统计哪些客户端在以太坊上运行，例如 Geth、C++、Parity 和 Python。 所以Geth和Parity用的多。 今天主要研究Geth，因为它是官方的，而且有大量的用户。 也有一些关于奇偶校验的研究。

先说Geth吧。 其实，涉及到任何安全问题，我们首先需要了解这样一个东西。 例如，Geth 是一个盒子。 我们怎样才能打破它？ 也就是所谓的Attack Surface（攻击面）问题。

例如，如果它可以通过智能合约进行攻击，那么它可能是 EVM 问题。

也可以通过一个RPC接口来使用，可以类比之前Web安全相关的问题。

还有一种通过协议栈的攻击。 这两个实际上有点不同。 因为区块链中的每个客户端都会相互同步或者相互共享信息，所以协议栈的问题是最底层也是最关键的问题。 一旦出现问题，整个系统可能就跑不起来了。 因此，接下来，我将主要讨论协议栈的一些方面。

这是以太坊的协议栈，大致是这样的。 您以前可能没有听说过很多零件。 比如大家熟悉的ETH、LES、Whisper，都是以太坊的协议。 然后还有一些其他的和它并列，它的底层其实包括RLPx和ÐΞVp2p。

假设你已经运行了 Parity 或者 Geth，你需要同步一个全节点。 实际上，这需要很多时间。 我刚开始的时候，可能需要一个月左右，这取决于你的带宽； 和硬盘。 我发现机械硬盘基本没什么用，只能和SSD同步。

与ETH并列的LES协议是一个相对轻量级的协议。 当你在同步的时候，你不需要同步所有的信息，你可以只同步一些元数据。

所以，在运行 Geth 时，可以指定以 LES 模式运行。

下面详细介绍一下我们之前发现的LES的安全问题。

简单来说就是读越界的问题。 问题出在上面这行代码，这里是query.Skip。

我们可以自己写一个类似Geth的客户端，只要我知道你Geth的IP就可以了。 比如有矿池，矿池中总要有一个节点同步到链上。 一旦我知道 IP 是什么，我就可以伪造这个东西让你崩溃。

那么，如何让它崩溃呢？ 我把Skip的值设置为-1（你可以在协议栈上随意设置），-1+1就是0，也就是说我可以尝试让你分配一个长度为0的数组，然后我就可以读了这个数组的Skip值为-1的位置一定不能再是你的位置。 已经超出了你所能控制的内存范围，所以必然会死机。

接下来演示这个EPoD Demo，问题出现在1810之前的版本，包括1810版本。

拍视频的时候，我用的是官网的1810版本。 与MD5相比，没有经过任何修改； 还需要处于离线环境，避免外部攻击，保证所有攻击都来自本机； 运行 Geth LES 模式。

然后监听本机发送的30303端口。 运行攻击代码后，EXP后面的地址（即本机地址）为127.0.0.1，端口为30303，此时Geth已经几近崩溃。

Index out of range，崩溃的原因是这个，读越界。 在处理这些 LESMessages 之一时，它导致越界读取。 TCPdump 是我攻击的钱包。 我们称此漏洞为 EPoD。 只要我知道你的IP，发送一个数据包，Geth就会崩溃，大概是这样的。

还有一些攻击我应该在 9 月的 ISC 上谈谈。

比如你新成立了一个交易所X，然后有一个成立时间比较长的交易所Y，你觉得它的交易量很大，如果想做小，可以攻击Y交易所.

一旦知道了Y交易所的IP和同步节点，就可以传播信息了，会很忙的。

就像刚刚提到的矿池，矿池最基本的就是算力。 每个矿池都在争夺算力。 一旦我能瘫痪一些矿池，这个矿池背后的算力就没有了。 ，这也很严重。

但是通常我知道矿池在使用Geth的同时也会使用Parity，两个客户端会实时同步。 一旦我们发现 Geth 和 Parity 同时出现问题，这将很有趣。

还有所谓的引导节点。 玩过这个游戏的人可能都知道，开始同步的时候，需要知道从哪里开始同步，从哪一侧开始，就是所谓的Boot Node。

所以，当你瘫痪以太坊中所有的Boot Nodes时，新的Geth是没有办法同步的，因为它根本就没有办法启动。

一旦你发现这类涉及公链安全和协议栈的问题，你可能会受到这些攻击的影响。

因此，如果 Geth 低于 1810 版本，请快速升级。