BEC合约整数溢出漏洞还原与分析
一、币圈一秒，人间一年
有道是币圈一日，人间一年。这个说法又得升级了，叫币圈一秒，人间一年。
前不久，币圈又出大事啦。BEC智能合约被爆出整数溢出漏洞，导致黑客能无限印币，在一次交易中，也就那么几秒钟的事情，黑客就“无中生有”地给两个账户转了天文数字般的BEC币，而原账户一分BEC币都没损失。大家来围观下这笔交易：
https://etherscan.io/tx/0xad89ff16fd1ebe3a0a7cf4ed282302c06626c1af33221ebe0d3a470aba4a660f
围观归围观，所谓外行看热闹、内行看门道。
看到这么大笔BEC币，想必大家已经流着口水。。。
别馋，虽然大熊不能教大家在现实中黑一把，但搭个测试网络，还原下漏洞，过过瘾也是可以的，顺便还能学习下智能合约部署、整数溢出漏洞原理。知识是无价的，说不定以后能靠这些知识大赚一笔。好吧，言归正传：
那么，什么是整数溢出呢？
二、整数溢出浅析
首先，什么是溢出？
往空杯里面加水，加到满之后，继续加水，水就会流出来，这就是溢出。然而需要注意的是：尽管溢出，但杯里面依然是满水的状态。
然后，什么是整数溢出？
跟满杯加水溢出的情况不同，整数溢出像水轮车。往里面加水，加满之后，继续加水，水轮车将会失衡并转动，此时水将会被全部倒出来，并重新盛水。这就跟整数溢出类似：当变量累加到超过自身容量范围时，将会溢出，归零。而黑客也是利用了这一点，把运算前的数值作为转账金额，把运算后溢出的0作为检测条件，从而实现绕过。
这次的BEC整数溢出漏洞就出在batchTransfer函数（功能是批量转账）里面，具体来说就是以下这行：
uint256 amount = uint256(cnt) * _value;
简单分析一下：比如张三给李四、王五转账，数额为2^255（2的255次方），那么cnt=2，_value=2^255，而将cnt和_value两者相乘，结果为2^256，刚好超过uint256的范围，溢出之后amount的结果为0，接下来所有条件都能通过，最终结果是张三账户减去0个BEC币，而李四、王五的账户增加2^255个BEC币。
三、环境搭建、漏洞还原与分析（无意中又发现了一个漏洞）
这个漏洞虽然不起眼，逻辑也很简单，但是直接带来的后果相当于无限印BEC币啊，这还了得，下面就开始搭建测试网络，也给自己印几批天文数字BEC币过过瘾。
由于区块链环境搭建、以太坊和BEC智能合约部署过程较长，且并不是本文重点，所以简单阐述，若有兴趣可到本人微信公众号《进击的大熊》，回复“BEC”可见。
（一）环境搭建
geth客户端安装，用来运行以太坊节点、创建和管理账户、发送交易、挖矿、部署智能合约。
具体环境是：Win10 64位、geth-windows-amd64-1.8.6
（二）漏洞还原
1、准备创世块文件、初始化创世块，并启动区块链节点
2、创建3个用户，并分别命名为zhangsan、lisi、wangwu
3、主节点zhangsan挖矿，得到一些ETH，后面部署智能合约等操作都需要ETH。
4、复制BEC智能合约源码，用在线Remix工具编译，并部署到虚拟网络，下图可以看到已经部署成功。
5、溢出转账
这里无意中又发现了一个漏洞，不过不是BEC合约，而是console，先前我一直这样来转账：（绿色数值就是2^255）
>bectoken.batchTransfer([lisi,wangwu],57896044618658097711785492504343953926634992332820282019728792003956564819968,{from:zhangsan})
然而失败了若干次，由于数值较大，每次都怀疑是不是复制错了，为了解决这个问题，还试过：
>bectoken.batchTransfer([lisi,wangwu],Math.pow(2,255),{from:zhangsan})
但还是失败，李四和王五的账号依旧为0.
后来用Remix调试才发现，原来一直不能成功绕过检测（require(_value > 0 && balances[msg.sender] >= amount); ），因为amount根本不为0，张三的账户上也没有那么多BEC币。进一步发现，传进去的_value也不是2^255，而是诡异的0x80000000000000016c889……
怪不得不能通过 balances[msg.sender] >= amount
那么，换个思路吧，直接把_value的值在源代码设为2^255则可实现绕过，并成功实现转账，最少证明了理论是可行，大方向没错。
这种情况下，我想只能是console传递数值的时候出现问题了，但找了很多资料没能解决，最后在Github上发帖咨询Geth团队，才知道原来也是个溢出漏洞，真是“洞中洞”啊。
发帖没过多久就收到了回复，感谢这位小哥！
大概意思是：所用的控制台基于JavaScript，而JavaScipt使用float-s来表示数字，直接传递2^255这样大的数值，将会产生溢出，从而使数值发生变化。解决方法是，需要使用一个大数字库，这样才能使用任意精度的整数。
因此我改变打法，用web3.toBigNumber来表示2^255，最终也实现了还原，成功给李四、王五账户上转了天文数字般的BEC币。
var value = web3.toBigNumber(’57896044618658097711785492504343953926634992332820282019728792003956564819968′);
另外，可能眼尖的朋友会留意到，为什么zhangsan账户上也有一笔BEC，那是因为智能合约上规定，创造者会拥有一些初始的Token，请见怪不怪。
（三）安全代码的作用
已经证明了整数溢出的危害性，那么该如何解决这个问题呢？其实BEC智能合约里面已经回答了这个问题，可以发现除了漏洞那行代码之外，其它运算都用了安全运算库里面的函数，那么试试吧。
更改BEC智能合约代码，把*改成库里面的mul函数，再重复上面的过程。
可以看到，这时已不能绕过检测，转账失败。
分析下这个Mul函数，代入具体数值说明一下：
假如：a = 2，b = 2^255
那么：c = a * b = 0
但： c / a = 0 != b
因此也就绕不过安全运算函数了。
四、整数溢出的原因
水轮车溢出之后归零，并重新开始盛水，是因为自身失衡所致。
那整数溢出的原理又是什么呢，当uint256的参数为2^256时，为什么会等于0，而不是继续等于2^256-1。
下面尝试用C++程序实验来解释：
从下图实验结果可以发现，当int参数赋给unsigned short参数之后，unsigned short只取后16的数值，而前面的数值一概不理，所以就会出现当输入为65536，赋给输出值后，产生溢出，只保留最后的0000，最终输出值为零。
另外，当输入为65537，-1时，按照溢出的规则，则输出也就自然为1、65535。
用OD调试这个C++程序，以进一步说明：
单步调试来到这里输入数值前，可以从堆栈发现输入值将会保存到 地址为0x004FF918的内存空间中。
于是输入65535，可以发现0x FFFF（65535）已经被存储到 0x004FF918的内存空间中。
接下来，程序会将该值用movzx指令赋给ecx寄存器，以实现C++中的output=input。
继续单步调试，可以看到ecx寄存器的寄存器值为0x FFFF，也就是说，当输入为65535，输出也为65535。
再来一次，这次输入65536，可以发现0x 0001 0000已经被存储到 地址为0x00CFF8CC的内存空间中。
接下来，程序会将该值用movzx指令赋给ecx寄存器。
单步调试，继续运行程序，可以看到ecx寄存器的寄存器值为0x 0000。也就是说当输入为65536时，输出为0。
所以关键在于：MOVZX指令。
这是汇编语言数据传送指令MOV的变体，无符号扩展并传送。
简单来说，movzx将源操作数取出，置于目的操作数，而目的操作数其余位用0填充。于是就出现了溢出时，只留下低位的16位数值。
五、写在最后
BEC智能合约也不是小众产品，但都能出现如此明显且致命的漏洞，可见币圈安全问题真的不会少。
想必大家都想着产品早日上线，早日盈利，所以基本的代码审计、系统测试这类基本的安全检查都能省则省，或者简单带过，带来的后果可想而知。这次的安全事件给区块链开发者和黑客们都提了醒，开发者得加大精力考虑代码安全，而黑客们则是将注意力从持币者身上转移到源码审计。
信息安全问题，归根结底是人与人之间的利益博弈，只要利益存在，攻与防、矛与盾就会一直持续。
希望这次的事件，能引起大家对信息安全的重视。
时刻牢记安全无小事，防微杜渐是关键！
