一、币圈一秒,人间一年
有道是币圈一日,人间一年。这个说法又得升级了,叫币圈一秒,人间一年。
前不久,币圈又出大事啦。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智能合约也不是小众产品,但都能出现如此明显且致命的漏洞,可见币圈安全问题真的不会少。
想必大家都想着产品早日上线,早日盈利,所以基本的代码审计、系统测试这类基本的安全检查都能省则省,或者简单带过,带来的后果可想而知。这次的安全事件给区块链开发者和黑客们都提了醒,开发者得加大精力考虑代码安全,而黑客们则是将注意力从持币者身上转移到源码审计。
信息安全问题,归根结底是人与人之间的利益博弈,只要利益存在,攻与防、矛与盾就会一直持续。
希望这次的事件,能引起大家对信息安全的重视。
时刻牢记安全无小事,防微杜渐是关键!
原文地址:https://www.cnblogs.com/0daybug/p/12311126.html