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

Posted 2023-04-02 「已注销」

前言

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() 和 授权转移代币 transferFrom() 的具体实现，但该函数的修饰器是 public，因此任何人都可以不通过 transfer() 或 transferFrom() 函数直接调用它。

而当变量 useWhiteListSwith 设置为 False 时，该函数不会检查调用地址和传输地址是否合规，直接将代币转移到指定地址。

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

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

总结

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

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

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

创宇区块链｜Inverse Finance 安全事件分析

前言

北京时间 2022 年 4 月 2 日晚，Inverse Finance 借贷协议遭到攻击，损失约 1560 万美元。知道创宇区块链安全实验室第一时间跟踪本次事件并分析。

分析

基础信息

攻击tx1：0x20a6dcff06a791a7f8be9f423053ce8caee3f9eecc31df32445fc98d4ccd8365

攻击tx2：0x600373f67521324c8068cfd025f121a0843d57ec813411661b07edc5ff781842

攻击者1：0x8B4C1083cd6Aef062298E1Fa900df9832c8351b3

攻击者2：0x117C0391B3483E32AA665b5ecb2Cc539669EA7E9

攻击合约：0xeA0c959BBb7476DDD6cD4204bDee82b790AA1562

Oracle：0xE8929AFd47064EfD36A7fB51dA3F8C5eb40c4cb4

Keep3rV2Oracle：0x39b1dF026010b5aEA781f90542EE19E900F2Db15

攻击流程

tx1：

1、Sushiswap 兑换，300 WETH => 374.38 INV

2、Sushiswap 兑换，200 WETH => 690307.06 USDC

3、DOLA3POOL3CRV-f 兑换，690307.06 USDC => 690203.01 DOLA

4、Sushiswap 兑换，690203.01 DOLA => 1372.05 INV

tx2：

1、质押 INV 作为抵押物

2、借走 1588 ETH、94 WBTC、4M DOLA、39.3 YFI

漏洞原理及细节

在第一笔攻击交易中，攻击者通过巨额的 WETH => INV 兑换，抬高 Sushiswap 中 INV 对 WETH 的价格。

紧接着在15秒后的下一个块中实施了第二笔攻击交易，质押 INV 作为抵押物，由于上一个块的价格操纵导致预言机对 INV 的高估值，使得攻击者得以借走大量ETH、WBTC、DOLA、YFI完成攻击套利。

实际上该两笔攻击交易即是常见的闪电贷操控价格攻击的拆分，由于预言机采用了 TWAP 类型，于是将攻击拆分成两段，首先通过巨额资金的兑换操纵交易对价格，然后抢先交易保证在下一个块中第一时间完成套利离场。

总结

本次攻击事件中虽然 Inverse Finance 采用了相对安全的 TWAP 类预言机，但在巨额资金和现有的抢先交易技术的基础上，依然存在攻击的可能。因此，TWAP 类预言机的窗口期时间也需要进行合理的设置。

近期，各类合约漏洞安全事件频发，合约审计、风控措施、应急计划等都有必要切实落实。