Creat future惨遭随意转移币，幕后黑手究竟是谁？

前言

CF代币合约被发现存在漏洞，它允许任何人转移他人的CF余额。到目前为止，损失约为190万美元，而 pancakeswap上CF/USDT 交易对已经受到影响。知道创宇区块链安全实验室第一时间对本次事件深入跟踪并进行分析。

事件详情

受影响的合约地址

https://bscscan.com/address/0 x8B7218CF6Ac641382D7C723dE8aA173e98a80196＃code

问题函数出在第563行：

codefunction _transfer(address from, address to,uint256 amount) public {
require(from !＝ address(0), "ERC20: transfer from the zero address")；
require(amount ＆gt； 0, "Transfer amount must be greater than zero")；
if(useWhiteListSwith){
require(msgSenderWhiteList[msg.sender] ＆amp；＆amp； fromWhiteList[from] ＆amp；＆amp； 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() 函数检查授权额度的功能形同虚设；而合约管理者也不该随意修改关键变量值，导致攻击者可以绕过白名单检查的最后一道防线。

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