自六月份EOS主网之后，Joe老师亲身经历和见证过EOS DApp一路走来的艰辛。被黑客以各种各样方式攻击过的DAPP，总的损失规模至少上千万了。一直以来，都想对所有被攻击过的DAPP，以及攻击方式做一个汇总。因为前人花大的代价踩的坑，得到的教训，应该总结好，避免后人再犯。
因此上周日，一块链习·区块链技术100讲—第3讲由资深全栈工程师，区块链DApp开发老司机Joe老师向大家倾心分享——如何避免累计造成千万损失的EOS智能合约漏洞。
以下是老师分享的详细内容 。 ↓↓↓
这些造成损失的漏洞，可以归为合约代码漏洞，和随机数算法使用不当的两种问题。
1. 智能合约代码问题
代码溢出之类的漏洞 （狼人杀案例）
这个就不多说了，漏洞细节，就是当时eos版本中的 asset 类的乘法存在 检查溢出无效的问题。 而 代码中，依赖 asset 的代码做溢出检查，或者压根就没考虑做溢出检查。 导致了整型溢出，出现 了致命而无法修复的bug。这点，只要主要在合约代码中的数值计算部分，做详细的 eosio_assert 断言检查就可避免。关键还 是细心写代码哈。
未检查 code == eosio.token。 这个问题受害面还是比较广的，从 EOS bet、newdex、 以及后来的 cast 项目，都是因为没有检查 转账的来源，而蒙受大额损失，从以上的列表看出，这条经验是好百万巨款买来的。
项目方，利用转账通知回调transfer，来执行业务，但是这个 transfer通知，有可能来自 非 eosio.token的 （俗称假币 假EOS）， 所以对 code == eosio.token 的判断，就非常的重要。
转账通知 未判断 to == _self。这个问题，暴漏在 EOS bet 第二次被攻击的时候。损失也是500万以上。转账通知，有个特点，就是不仅仅你收到转账的会收到通知，任何人收到转账的时候，都可以通 知你，他收到了转账。 比如，张三收到了李四 100 EOS 的转账，于是张三 告诉王五，“收到 100 EOS 转账”。王五，没有判断 “收款人 等于王五”，于是以为是自己收到了 100 EOS的转账。
原因就是这样。 项目方，实际上没有收到 真正的 EOS， 只是收到了 一条EOS 到账通知，但收款 人还不是项目方。如何对任意人发起转账通知呢？只需要在转账中加入一条代码即可：require_recipient(N(eosbetdice11));这样，你想通知谁，就通知谁。 此时要是对面没判断收款人，那么很可能就被你黑了噢。
2. 伪随机代码中存在的一些问题。
伪随机数算法中的可计算参数。之前不少概率随机游戏的项目方，采用了链上伪随机方案，也即纯粹使用区块链上的数据来做游 戏开奖的随机数种子。但是，由于使用不当，有了种种被黑的结局。类似的链上伪随机算法，我贴几张图作为参考：
以及广泛被引用的github代码：
以上案例，都有一个共同的特点，就是采用了 tapos_block_prefix, tapos_block_num 做为随机数种子。但是啊，这两个值，其实是依赖于过去的区块。也就是说，它们是能算出来的，当这个关键的参 数，能够被计算出来的时候，所谓的随机数算法，就不是随机了。黑客可以提前计算好结果，保证百分百胜率。
除了，tapos_block_prefix, tapos_block_num, 还有当前 transacation_id 下面就分享下，这几个值如何算。tapos_block_prefix, tapos_block_num 以及 transacation id 怎么计算 ？
tapos 有个定义是 Transactions as Proof-of-Stake (TaPOS)。它是指定一个过去的区块（ ref_block_num ），用来做 Proof-of-Stake的。而代码中使用的 tapos_block_prefix 和tapos_block_num， 正是由这个 ref_block_num 算出来的。
查看push action 说明，可以看到发起一个普通的action时，其中 ref_block_num, 是由客户端指定的！有人会说，我平时发起action的时候，并没有指定过 ref_block_num啊？其实，当你没指定 ref_block_num 的时候，我们使用的 cleos 或eosjs 客户端，会帮我们默认指定 一个：
翻客户端的代码，它告诉你，如果用户没指定ref_block_num，会帮你取一个， 取的是 last_irreversible_block_id，也就是get info 中返回的，上一个不可逆区块的id。也就是，有了ref_block_num ，我们就可以拿到 tapos_block_prefix 和tapos_block_num 了:
tapos_block_num = ref_block_num & 0xffff tapos_block_prefix = get block(ref_block_num).ref_block_prefix
最后 说下 transacation_id。
transacation_id ，是一笔交易的唯一id，是一个hash值，看起来好像是随机不可预测的啊。于是有人拿它做随机数，然后就没然后了。这个值，跟你发起的 transacation 有唯一关联， 所以是个可计算的值。计算方法如下：
直接 read_transaction 拿到 当前 transacation的数据，然后 sha256 就得到了 transacation_id了。
3 为什么利用延时交易，tapos_block_prefix, tapos_block_num 依然被破解 了。有的项目，采用延时交易来异步开奖，伪随机算法里，用到tapos_block_prefix，tapos_block_num， 时间，用户名，奖池金额等信息。这样的伪随机算法，看起来好像没毛病，用到了未来的数据，似乎无法预测，但是真的是这样 么？时间的话，知道了你延迟多少秒后，直接往上加就行了，用户名是确定的，奖池金额这个虽然是 动态的，但是如果变动的频率不是非常快，快到每分每妙都在变，那么在短时间内，可以视为是 定值。所以关键还在于 tapos_block_prefix, tapos_block_num 。延迟交易中的tapos_block_prefix, tapos_block_num， 和普通交易中的 tapos_block_prefix, tapos_block_num 计算方式有所不同。
普通交易，通过客户端制定 ref_block_num ,然后计算出来。而延迟交易中，看EOS相关代码得知，直接使用head_block_id 做为 ref_block_num 。也就是说，当前区块头，就是ref_block_num。
知道这点后，就好办了，有多种办法可以拿到head_block ，比如说 直接 get_info
拿到了 head_block_num 之后，在get_block 信息，可以直接得到
拿到了这两个参数，又知道了随机数算法，理论上，就能够预测能不能中奖了。
直接在合约里写代码判断，能中奖就发送交易，不能就跳过。总结 tapos_block_prefix, tapos_block_num，慎用为随机数算法参数，如果非要用，可以采用发起 连续的两次延时交易。因为延迟交易中的 head_block_id 跟你延迟多少秒没关系，是构造这个延迟 交易的时候，就设定好了的。
4. 同步开奖时被利用智能合约钩子，回滚交易。早期被黑的项目中，还存在一些 “错误的实践” ， 也值得提一下。
第一种，是同步开奖，同步开奖有个问题，就是黑客可以轻松的破解你，一个简单的思路是，直 接拉取你的项目code，然后部署一个合约A， 然后用合约B跟这个A合约玩，假如和A合约玩赢了， A合约会给B转账，在B的转账通知那边写一个转账通知回调，一旦赢了，就和你的项目玩。 这样 是必胜的。
第二种，是发回执，被对方拒绝，导致回滚整个交易。
一个错误案例是： 开奖 -> 给对方发一个 receipt action， 告诉对方你中奖没中奖， 于是对方，直 接针对这个receipt 写一个回调，当你告诉他输了之后，他可以拒绝，回滚这次开奖， 这个好像被 叫做 “重放攻击” ， 避免的方法，就是 receipt 之类的通知，可以采用异步的。
5. 为何不开源也被撸？
目前大多数菠菜类项目方，是不敢开源的，一是怕竞争，而是怕暴漏问题。这个不好评判，我个人还是喜欢开源的。被撸的项目方，其实大部分也都没有开源，那么为什么还是被撸了呢？ 这里简单分享下。
首先，你合约代码都部署都上链了，对于有能力撸你的那些技术大神，这里其实没多少秘密可言。无非是读源代码和编译后代码的区别而已。项目的代码，在编译过后，部署到了链上。取回的步骤如下。
1. 第一步，通过 get code 取回。可以得到 abi 文件和 wast 文件。abi文件，可以看到接口信息， 和猜测整个合约代码的大致结构。
2. 翻译 wast 文件了，找出你的随机数算法。 下面几张图，是简单的示例。
简而言之，你开源或不开源，对那些黑客来说，其实都一样的。关键还是写代码时，不要留下问题。不要去踩那些坑。不要轻易使用可以被拿到的参数做关键部分的随机数算法参数。
6. onchain调用。
EOS Bet 在第一次被攻击的时候，表面上，是没有检查code == eosio.token , 实际上，还有一个值得一提的细节。那就是，对方这个 transfer action，并没有暴漏在 abi中，也就是客户端是没办法直接调用的。
但是黑客是直接调用的。那么是如果做到的呢。原来，abi并不是必须的。一旦你的code中有这个action，那么就算在abi文件中，把这个 action接口删除了，企图留下外面 的人不知道的 “后门”。实际上这个 action 还是可以被调用。
有两种方法：
第一种，就是直接在另一个智能合约里发起调用。
第二种，就是改造下你的客户端。不要在push aciton的时候，去调用abi。
改造的细节过于技术，有兴趣的去参考这个https://zhuanlan.zhihu.com/p/42903901?utm_source= wechat_session&utm_medium=social
总结， abi 只是接口和数据描述文件，就算你代码不部署 abi，也不影响合约代码正常工作。所以，如果你的智能合约，仅仅是用来和其他智能合约交互，而不是面向客户的用户(cleos、 eosjs)，那 abi 都可以不用部署。
本期直播预告
本期我们邀请的直播分享嘉宾呢，是前谷歌高级软件工程师，Solidity资深开发者，DOS Network联合创始人 Jonny。
他这次将带来的分享主题是——智能合约中的随机数
Fomo3d及其山寨合约们存在空投随机数漏洞被黑客攫取超过6000个以太；“可证明公平”的Dice2win实际存在庄家可操控的随机数漏洞；EosRoyale, EOSDice等博彩类游戏因随机数可被预测而损失高达数万eos。我们将从链上随机数的常见使用误区，结合真实案例和攻击手法来讲解在智能合约中生成及使用随机数的正确姿势。无论是智能合约开发者还是链上游戏的项目方，都能从中了解和避免随机数漏洞防止被黑客任意割；而玩家们也可以学习如何火眼金睛得鉴别出存在漏洞、无法自证公平的项目方。
关于DOS Network: DOS是Decentralized Oracle Service (去中心化预言机服务) 的首字母缩写，专注于为智能合约赋能链外数据和计算能力，服务于多条异构公链，目前已发布基于以太坊测试网的alpha版本。总部位于硅谷，团队成员来自于谷歌、亚马逊、卡耐基梅隆，浙大、北邮，具有丰富的区块链和智能合约开发经验。
首先介绍下分享大纲：
1. 真随机和伪随机
2. 区块链场景下对安全伪随机数的要求
3. 误区1 - 使用block number, block time等纯链上随机数生成方式
3.1 解释，攻击手段和实际案例 - Fomo3d airdrop
4. 误区2 - 多方参与贡献种子生成随机数一定就安全吗
4.1 解释，攻击手段和实际案例 - dice2win
5. 安全可验证的随机数生成方法介绍和具体例子
5.1 强化版的Commit-Reveal
5.2 可验证随机函数和门限签名
5.3 DOS Network随机数生成方式和链上API使用
6. 小结
看了这满满当当的分享大纲，如果是区块链游戏玩家或关心合约安全和公平的小伙伴，经历双十一剁手后的洗礼一定很开心收到这份福袋~
因为在这次分享课中，你将获得区块链中产生随机数的正确姿势，以及快速甄别项目方的随机数漏洞。
最后，还有必要提醒同学的是——这份礼物的抢手程度也许远超过你的想象，一旦错过就无法再能拥有。
因此，不想错过这次特殊礼物的同学，直接小姐姐添加一块链习班长Jessie微信号：yikuailainxi，抢占最后的名额吧！
「一块链习」技术社区链接全世界最极客的区块链开发者，共同学习区块链技术知识与开发实战，为每一位开发者提供有深度的、持续的价值与帮助。
关注「一块链习」
与全球区块链开发者一块学习
网友评论