文章前言

本篇文章将通过对LightXXX合约内transfeFrom授权转账函数中的allowance不一致性检查问题和CountryXXX合约内transfeFrom授权转账函数中的balance不一致性问题对智能合约中的"不一致性检查"问题进行深入分析介绍,并以此来探究智能合约中值得关注的业务逻辑设计安全问题

漏洞原理

allowed不一致

漏洞介绍:如下面代码所示,用于检查授权额度的条件语句require(_value <= allowed[from][msg.sender]);与后期业务逻辑中授权额度更新时的语句"allowed[_from][_to] -= _value;"存在不一致问题(即检查时检查的条件与后期更新时操作的对象并非同一个),存在设计缺陷,该漏洞导致的危害是如果用户A给用户B授权转账后,用户B可以无限制的转走用户A的资产,直到转完账户的所有余额

balances不一致性

漏洞介绍:如下面的代码所示,用于检查用户资产数量是否足够转账的条件检测语句"require(balances[msg.sender] >= _value);"与后期转账操作时更新用户资产数量的操作语句"balances[_from] -= _value;"存在不一致性,该漏洞操作的危害是攻击者能够通过溢出,让_from账户余额获得极大的token数量

漏洞复现

allowed 不一致性

首先,下载LightXXX合约代码之后在本地Remix中进行部署调试(这里需要改一下合约中owner地址便于调试),相关账户地址信息如下所示:

  • 管理者:0x5B38Da6a701c568545dCfcB03FcB875f56beddC4
  • 攻击者1:0xAb8483F64d9C6d1EcF9b849Ae677dD3315835cb2
  • 攻击者2:0x4B20993Bc481177ec7E8f571ceCaE8A9e22C02db

Step 1:以管理者身份调用approve函数给予攻击者1一定的转账额度

approve:
"0xAb8483F64d9C6d1EcF9b849Ae677dD3315835cb2",10000


交易记录信息:

Step :2:使用allowance 查看转账额度:

"0x5B38Da6a701c568545dCfcB03FcB875f56beddC4","0xAb8483F64d9C6d1EcF9b849Ae677dD3315835cb2"


此时此时攻击者2的余额为0:

Step 3:之后切换为攻击者1身份,并通过攻击者1使用transferFrom向攻击者2进行转账操作

transferFrom 
"0x5B38Da6a701c568545dCfcB03FcB875f56beddC4","0x4B20993Bc481177ec7E8f571ceCaE8A9e22C02db",10000


交易记录信息如下:

Step 3:攻击者1继续使用:transferFrom向攻击者2进行转账操作,仍然能转账成功,因为 allowed[_from][msg.sender]没有发生变化

transferFrom 
"0x5B38Da6a701c568545dCfcB03FcB875f56beddC4","0x4B20993Bc481177ec7E8f571ceCaE8A9e22C02db",10000


交易日志记录:

之后发现攻击者2的余额依然增加了:

通过此攻击,攻击者能够将 _from 账户里的所有余额转移到其它用户余额中,并且allowed[_from][_to]是溢出了的~

allowance : 
"0x5B38Da6a701c568545dCfcB03FcB875f56beddC4","0x4B20993Bc481177ec7E8f571ceCaE8A9e22C02db"

balances不一致性

首先,下载CountryXXX合约然后在Remix中进行部署分析调试(在构造函数中给msg.sender赋一些token),相关地址如下:

  • 管理者: 0x5B38Da6a701c568545dCfcB03FcB875f56beddC4
  • 攻击者1:0xAb8483F64d9C6d1EcF9b849Ae677dD3315835cb2
  • 攻击者2:0x4B20993Bc481177ec7E8f571ceCaE8A9e22C02db

Step 1:在这里我们首先通过管理者地址给攻击者1地址打一定数量的代币进去,来模拟攻击者1充值token:

0xAb8483F64d9C6d1EcF9b849Ae677dD3315835cb2,100000000000000


交易日志信息:

之后攻击者1的地址所拥有的token数量为:

另一个攻击者2地址账户余额为0

Step 2:接下来我们的攻击就是让第二个账户溢出,之后使用攻击者2给予攻击者1一定的转账额度权限

approve: 
"0xAb8483F64d9C6d1EcF9b849Ae677dD3315835cb2",10000


Step 3:切换回攻击者1,然后使用transferFrom向自己进行转账操作

transferFrom 
"0x4B20993Bc481177ec7E8f571ceCaE8A9e22C02db","0xAb8483F64d9C6d1EcF9b849Ae677dD3315835cb2",10000


交易日志如下:

此时攻击者2地址上余额本来为0,但经过 “ 的减法计算下溢变为了一个极大值

修复方案

修复方法如下:
1、使用safeMath方法进行计算
2、使用balances[_from] >= _value作为条件判断而非 balances[msg.sender]
3、检查allowed[_from][msg.sender]并对allowed[_from][msg.sender]进行操作不要与allowed[_from][_to]混用
修复示例:

点击收藏 | 0 关注 | 1
登录 后跟帖