“角色反转？是欺骗者还是受骗者”—深入区块链重入蜜罐

网友原创投稿，作者：Pinging      

前几天收到区块链安全爱好者的消息，给我分享了一个带有重入漏洞的代码。该代码在EtherScan上被公布出来，我将代码download下来后按照传统思维做该题目发现该合约并没有展现应有的结果，通过后期模拟与推理我找到了原因。

我将这次探索过程记录下来，并带领读者重温重入的调用方法以及该蜜罐是如何让“欺骗者”成为“受骗者”的。
 

代码背景

偶然的机会我拿到了一段看似有漏洞的代码：

在合约栏我得到：

   

 

如往常一样，我拿到该合约后从起始部分分析该合约，发现这不就是简单而又刺激的“重入”合约吗？？ 

`Log`合约是一个用于记录record的合约，该合约用来记录其余合约的操作，类似于event事件一样，只不过该Log不容易被用户发现（相当于合约中调用了Log合约）。

在`Private_Bank`中有常见的存钱函数`Deposit()`，至少存钱1 ether；取钱函数`CashOut()`，取_am数量的代币。两者都会调用Log记录操作。除此之外，该合约有个很明显的传统漏洞——“msg.sender.call.value()()”重入漏洞。

这么简单的合约不是很容易攻击吗？说做就做，我们立刻攻击一下， 下面的步骤同样为那些不是非常清楚重入攻击的小伙伴提供参考。

话不多说直接上攻击代码：

  

我们创建了`Exploit`合约，构造函数中传入5 ether与`Private_Bank`合约，`Put`函数用于向target传入2 ether的以太币；`tryIt()`为攻击函数，取钱1 ether，而合约的`function ()` fallback函数用于进行重入。

 
由于原始合约中存在call函数，而调用call函数会默认调用攻击合约的fallback函数。

   

按照我们的逻辑，我们将向原始函数发出取钱请求，根据上述代码，我我们需要先绕过`_am<=balances[msg.sender]`而当第一次绕过后便在函数内部进行重入，于是到后面虽然取钱数量达到限制也可以绕过判断不断调用取钱操作，从而作恶。

那我们就试一试：

   

现在里面有我们2 ether的记录了，现在我们攻击，准备享受胜利果实？

   

Boom？发现执行失败了？点了好多次都失败？怎么回事？

发现重入失败。

回看代码与合约并没有发现问题，攻击合约也是没问题的。此事必有蹊跷。
蜜罐合约分析与实战操作，上面便是该合约正常重入后发现的问题，关键是它吞了我2 ether？？？？我还取不出来？？欺骗者还是受骗者？？

现在读者应该跟我一样，并不知道这是怎么回事。后来经过尝试我发现，该合约的问题出在Log合约处。

由于Log合约是额外调用的合约，在以太坊网站上contract代码公布的时候是对这一环没有进行严格的过滤，从而导致真实合约并不是显示的这样。

我们也不绕弯子了，放上一个原始蜜罐代码以及显示的代码便于用户比较：

  

 

下面为真实的部署合约，该合约会判断传入的_data字符串是否是7个字符，如果是则revert，从而导致重入失效。

所以我们可以将我们的合约部署如下：

  

下面演示一下，我们先部署Log合约：

  

之后传入Log地址部署Private_Bank：

 

之后利用Private_Bank地址部署攻击合约。之后的结果就如同我们上面演示的那样出现bug。然而如果我们将revert函数去掉呢？

部署完成后充钱 2 ether，庄家合约中有9 ether，我们剩余3 ether。 

现在开始攻击：

  

重入成功，金额都溢出了。

  

所以这也就证明了Log函数被人动了手脚，然而这个手脚却无法显示出来，这也就是为什么重入蜜罐会起作用。

本文为作者投稿，享华盟原创激励计划，文章发布后会依照阅读量等内容作为参照依据对作者发放奖励。

推荐文章++++

*kippo进阶版蜜罐：Cowrie

*Docker 搭建HFish蜜罐