创宇区块链｜Creat future 惨遭随意转移币 幕后黑手究竟是谁？

前 言

CF 代币合约被发现存在漏洞，它允许任何人转移他人的 CF 余额。到目前为止，损失约为 190 万美元，而 pancakeswap上CF/USDT 交易对已经受到影响。

知道创宇区块链安全实验室 第一时间对本次事件深入跟踪并进行分析。

事件详情

受影响的合约地址：https://bscscan.com/address/0x8B7218CF6Ac641382D7C723dE8aA173e98a80196#code

问题函数出在第 563 行：

function _transfer(address from, address to,uint256 amount) public {

require(from != address(0), "ERC20: transfer from the zero address");

require(amount > 0, "Transfer amount must be greater than zero");

if(useWhiteListSwith){

require(msgSenderWhiteList[msg.sender] && fromWhiteList[from]  && toWhiteList[to], "Transfer not allowed");

}

uint256 fee = 0;

...

uint acceptAmount = amount - fee;

_tOwned[from] = _tOwned[from].sub(amount);

_tOwned[to] = _tOwned[to].add(acceptAmount);

emit Transfer(from, to, acceptAmount);

}

_transfer() 函数是直接转移代币 transfer() 和 授权转移代币 transferFrom() 的具体实现，但该函数的修饰器是public，因此任何人都可以不通过 transfer() 或 transferFrom() 函数直接调用它。而当变量 useWhiteListSwith 设置为 False 时，该函数不会检查调用地址和传输地址是否合规，直接将代币转移到指定地址。

在区块高度为 16841993 时，管理员就把 useWhiteListSwith 设置为 False：

此时开始有攻击者利用 _transfer() 函数直接转移代币：

总结

经过完整分析， 知道创宇区块链安全实验室 明确了该次事件的源头由函数本身权限出现问题，而管理员同时操作不慎关闭了白名单检测，两方结合导致攻击者可以实现转移任意钱包代币的操作。

在核心函数上我们一直建议使用最小权限原则，像这次的 _transfer() 函数本不该用 public 修饰器，使得 transferFrom() 函数检查授权额度的功能形同虚设；而合约管理者也不该随意修改关键变量值，导致攻击者可以绕过白名单检查的最后一道防线。

合约不仅仅是代码层面的安全，不光需要白盒代码审计，更需要合约管理员共同合理维护。