导读
区块链生态中恶意攻击事件频发？冲击过后我们还应当如何搭建安全堡垒？安全是区块链行业发展背后的坚实力量，技术则是在攻防战争中矛与盾的力量转化。这里有一份以技术为导向的不完全安全指南，看一线网络安全攻防实战的团队如何做到负责任的披露，希望能够引领更多公链安全修习者共筑更为强大与健壮的数字未来。我们也许难以辩明黑暗丛林中的猎人，有人选择打开了潘多拉的魔盒，还应有人点燃寓意希望的圣火。
DoraSpeaker
DoraSpeaker是DoraHacks旗下的内容分享栏目，会围绕hackathon主题，引进属于时代的各种技术领域最资深的行业专家和学者为DoraHacker们带来分享。
分享主题：EOS和以太坊等公链安全研究
分享时间：2018.6.16 20:00 -21:00
分享人：慢雾科技安全研究员keywolf，“以太坊黑色情人节”事件披露者之一。
开场语录：
在分享开始之前，先来给大家介绍我们慢雾科技：“慢雾”，来源于三体，代表黑暗森林中的安全区域。慢雾科技专注于区块链生态安全，核心能力包括安全审计、安全顾问、防御部署、以及地下黑客风向标追踪。我们目前已经为全球多家交易所、钱包、智能合约做了安全审计和防御部署，同时相信大家也有从各个媒体上关注到，我们与区块链行业内众多团队达成了战略合作。
这次给大家带来的分享内容是我们慢雾科技目前所做的一些公链安全研究。主要内容有三个方面：首先是以太坊RPC安全；第二个是以太坊智能合约安全，目前在这方面已经频繁爆出了许多问题；最后则是我们慢雾最近做的EOS安全研究。
由于时间有限，没有办法展开详细说明，接下来会给大家介绍相关的推荐内容及文档链接，以供参阅、研究。下面我们开始进入正题吧。
我们从RPC的安全攻防开始说起。通常，在区块链上都会有RPC。关于以太坊的RPC，我们之前在披露“以太坊黑色情人节”的时候进行过深入的研究分析，发现其中有不少问题。
1.1 以太坊黑色情人节事件回顾与原理剖析
3月20号，我们发布了《以太坊生态缺陷导致的一起亿级代币盗窃大案》这篇文章。在披露过程中我们发现，攻击目前仍在持续，并且这样的一个盗币行为造成的损失已高达2000多万美金。
在这边给大家简单介绍一下攻击过程：攻击者会在全球扫描8545以太坊RPC端口，以及8546 WebSocket RPC 端口，频繁查询账户列表及账户余额，同时获取区块高度；第二步是在得到服务器的IP及端口列表之后，不断重复调用sendTransaction的方法将余额转出到攻击者自己的钱包，一个关键点在于，如果正好碰上节点的用户在机器上对自己的钱包执行unlockAccount时，在默认的300秒时间内，攻击者从RPC调用的时候就不再需要密码，就能够对这个交易转出进行签名，这样就可以把这个节点里面的ETH或者Token转到攻击者钱包。
我们在披露了 “以太坊黑色情人节”之后，还建立了专题网站，对这样的攻击行为进行持续跟踪和监控。在我们的专题网站中，能够看到被盗取的币和Token数量都在不断增加。
以太坊生态缺陷导致的一起亿级代币盗窃大案：
https://mp.weixin.qq.com/s/Kk2lsoQ1679Gda56Ec-zJg
Billions of Tokens Theft Case cause by ETH Ecological Defects：
https://mp.weixin.qq.com/s/ia9nBhmqVEXiiQdFrjzmyg
以太坊黑色情人节专题跟踪：
1.2 以太坊 RPC 攻击手法一览
在披露了“以太坊黑色情人节”之后，我们持续地对RPC进行研究，除了这个发送交易的攻击，还有其他的一些攻击方法，主要就是针对RPC相关的模块，例如：如果RPC里面启用了personal模块，那么就可以通过RPC调用personal_unlockAccount的方法去猜测钱包的账户密码，假如说账户密码是弱口令的话，就可以一次性实现解锁和转账；再一个是比较重要的miner 模块，这是与挖矿相关的。miner模块里有一个方法是通过miner_setEtherbase可以修改挖矿收益的钱包地址。假如说，RPC里面启用了这样的方法，并且节点里面正在进行打包（挖矿功能）的话，攻击者就可以通过修改挖矿地址来实现劫持矿机。
以太坊 RPC 功能列表：
https://github.com/ethereum/wiki/wiki/JSON-RPC
同时我们还发现以太坊生态里的Geth、Parity等的日志没有很好地记录到通过RPC请求的方法及来源IP。在进行溯源的时候，由于这样的日志机制不够完善，我们难以去获取到这些攻击者的信息。
1.3 以太坊 RPC 安全加固方法
讲完了上面的几个攻击方法，再重点说一下防御以及加固的方法：
针对攻击面来说，一个是修改端口。尽量不要用默认的RPC API端口，避免别人进行全网扫描的时候发现这样的端口。
更重要的就是尽可能地不要把这个端口暴露在公网上，可以通过修改监听地址为内网的方法，让RPC在内网进行调用。
第三，假如说你需要对外提供查询的话，也可以配置iptable来源IP白名单作为限制。
Geth 命令行参数列表：
https://github.com/ethereum/go-ethereum/wiki/Command-Line-Options
再有就是，不要将账户信息（keystore）存放在节点上 （因为如果账户不在节点上，就不会用到unlockAccount ）。如此一来，攻击者在通过RPC查询的时候也不会看到账户信息。
在全节点的使用方面，尽可能把签名的过程拿到钱包里，或者选择不在全节点上进行操作，可以使用web3的 sendTransaction 和 sendRawTransaction 发送私钥签名过的 transaction。
接下来我们会讲以太坊智能合约安全。最近这段时间频繁地有团队爆出智能合约安全问题，例如早期从BEC、SMT爆出的问题，还有最近EDU、BAI的问题。
2.1 智能合约准则(code is law)
两起著名的利用智能合约漏洞的事件
智能合约的准则就是代码即法律。相信The DAO事件和Parity事件大家都有所耳闻。在智能合约的准则下面，默认的是合约在发布之后代码无法进行修改，但可以通过一些分层的设计来进行局部更新。
2.2 智能合约漏洞一览
接着讲的是智能合约的漏洞。上面的DASP网站里有去中心化应用安全问题的TOP10，其实大家在近期了解到的智能合约问题上，比较多的是溢出和逻辑设计方面的缺陷。
DASP的可重入漏洞（ Reentrancy Vulnerabilities ）也是The DAO攻击的根源，还有的就是权限控制缺失以及拒绝服务、短地址攻击。
DASP在我们慢雾区也有中文版文档，大家可以去搜索一下。由于时间关系，在这次分享中不能与大家展开说明。
2.3 如何写安全的智能合约
https://github.com/OpenZeppelin/openzeppelin-solidity
以太坊智能合约 —— 最佳安全开发指南
https://github.com/ConsenSys/smart-contract-best-practices/blob/master/README-zh.md
如何写出安全的智能合约呢？一个推荐是参考OpenZeppelin的框架，同时ConsenSys也总结了以往的智能合约漏洞，并给出开发方面的安全建议。
下面我们简单聊聊EOS方面的安全，最近EOS主网上线也是一个大家关注的热门话题。
我们在主网上线过程中有对几十个超级节点进行安全检测，同时也输出了多份文档。
3.1 EOS P2P 拒绝服务漏洞
在研究过程中我们发现了P2P拒绝服务的漏洞，发现并验证这个问题之后，我们也进行了负责任的披露，将问题提交给EOS官方，同时也申请了CVE。
CVE-2018-11548 EOSIO P2P 拒绝服务漏洞：
https://github.com/slowmist/papers/blob/master/EOSIO-P2P-Sybil-Attack/zh.md
在EOS官方修复这个漏洞后，我们才在社区披露漏洞的细节和安全问题。这是我们所做的负责任的披露工作。
拒绝服务漏洞的根源是由于默认的P2P链接数上限是25，同时没有对来源IP进行唯一校验。这样攻击者就可以使用同一个IP来发起成千上万的连接去占满超级节点的连接数。
3.2 EOS超级节点安全
我们针对EOS共识算法以及节点的配置出具了一份《EOS 超级节点安全执行指南》，在RPC安全、配置安全、网络安全、DDoS 防御和主机安全以及威胁情报方面进行了深入的研究思考，并且整理了这样一份安全执行指南输出到社区里：
EOS 超级节点安全执行指南：
https://github.com/slowmist/eos-bp-nodes-security-checklist
同时我们也提供了一份安全审计方案以供节点来进行自我审计，校验自己节点的安全性：
EOS 超级节点安全审计方案：
https://github.com/slowmist/eos-bp-nodes-security-checklist/blob/master/audit.md
3.3 EOS 智能合约安全
在EOS主网启动之后，会有越来越多的DApp开始在上面运行，那么EOS智能合约安全也会是我们关注的重点。
EOS合约在溢出及权限设计方面和以太坊是类似的。在规避溢出方面，C++也提供了一些基础的函数库来规避溢出。
EOS智能合约我们也在不断地进行研究和实践，以后还有更多分享带给大家，敬请期待。
