Bancor 危机：Token 背后潜伏的“上帝之手”

本文作者：安比(SECBIT)实验室 & 轻信科技(LedgerGo)

恐怖的智能合约管理员权限

作为比特币和区块链爱好者，我们崇尚去中心化。然而，很多持币者可能还不太清楚，目前各类 Token 项目智能合约管理员拥有超级权限竟已逐渐成为常态。据我们不完全统计，排名前 570 名的 Token 合约中，有 342 个合约存在只有管理员能调用的功能（onlyOwner），不少合约更存在管理员任意铸币、烧币、冻结账户、关停转账等过高权限 [1]。

安比（SECBIT）实验室研究了排名靠前的 Status (SNT) 和 FunFair (FUN) 项目。我们认为这两个热门项目都存在非常严重的管理员权限过高问题。

Status 合约中有名为 Controller 的管理员角色，可调用 generateTokens() 往任意地址增发代币，可调用 destroyTokens() 销毁任意地址上的代币 [2]。但 Status 项目的白皮书并没有相关特殊权限声明。而且，这两个超级权限函数在实现上，并没有触发 Mint 或 Burn 事件，只有普通的 Transfer 事件。

function generateTokens(address _owner, uint _amount) onlyController returns (bool) {
    uint curTotalSupply = getValueAt(totalSupplyHistory, getBlockNumber());
    if (curTotalSupply + _amount < curTotalSupply) throw; // Check for overflow
    updateValueAtNow(totalSupplyHistory, curTotalSupply + _amount);
    var previousBalanceTo = balanceOf(_owner);
    if (previousBalanceTo + _amount < previousBalanceTo) throw; // Check for overflow
    updateValueAtNow(balances[_owner], previousBalanceTo + _amount);
    Transfer(0, _owner, _amount);
    return true;
}

倘若有人利用管理员身份作恶，社区可能难以第一时间发现。通过扫描区块链数据我们发现，目前 Status 团队仅于 2017 年 6 月 19 日依次传入极小值成功调用了增发和销毁的函数进行测试，因此普通用户无需过分恐慌。但需要知道的是官方团队随时保留有这样的超级权限。此外，Status 合约还应用了可升级的代理合约机制，管理员可以通过任意设置代理合约 controller 地址的方式，在关键函数前面插入可升级的校验逻辑，来影响转账等关键操作。

function doTransfer(address _from, address _to, uint _amount) {
    ...
    if (isContract(controller)) {
        if (!TokenController(controller).onTransfer(_from, _to, _amount))
            throw;
    }
    ...
}

知名的 FunFair (FUN) 项目也存在与 Status 类似的问题 [3]。白皮书中并未提及其 Token 合约中的特殊权限；通常原本应当在众筹后一定时间内关闭的铸币等功能，项目方依然未关闭。倘若有人作恶，增发巨额数量的 Token 至市场上抛售，后果不堪设想。

此外还有不少项目有同样的问题。我们呼吁相关项目方应立即向社区做好风险告知与特殊权限披露，社区参与者也可以积极发挥监督力量。

Token 持有者有权了解，项目方也有义务披露以下这些内容：

• Token 及业务合约中项目方拥有的特殊权限明细

• 项目方为何需要这些特殊权限

• 特殊权限会在哪些情况下使用

• 特殊权限被滥用会发生哪些后果

• 哪些特殊权限可以被永久关闭以及何时关闭

• 特殊权限动用历史记录的详细说明

• 特殊权限动用的监控渠道

• 项目方采取何种措施来保障特殊权限不被滥用和盗用

• 如何通过更好的智能设计提升社区治理水平

此外，交易所作为区块链项目生态中的中坚力量，也应当积极督促项目方限制过高权限以及透明运营。

管理员权限过高造成损失的真实案例

目前为止还没有热门项目团队利用超级权限作恶的证据，或许我们可以舒一口气。但即使在信任官方团队不会主动作恶的前提下，恶性安全事件依然有可能发生。

加密货币交易平台 Bancor 于 7 月 10 日称遭到攻击，丢失 24,984 个 ETH，3,236,967 个 BNT，229,356,645 个 NPXS，折算法币金额为 1250 万美金的以太坊，1000 万美金的 Bancor 代币和 100 万美金的 Pundix 代币。

初期不少媒体报道称 Bancor 智能合约存在安全漏洞。安比（SECBIT）实验室遂对此安全事件进行追溯分析。

Bancor 主要合约包括 SmartToken 和 BancorConverter，分别为 ERC20 Token 合约以及与业务相关的 Token 转换交易合约。

本次 Bancor 平台被盗事件与 BancorConverter 合约有关，攻击者（黑客/内鬼）极有可能获取了 0x009bb5e9fcf28e5e601b7d0e9e821da6365d0a9c 账户的私钥。

而此账户正是转换代币合约 BancorConverter（0x3839416bd0095d97bE9b354cBfB0F6807d4d609E）的 owner，同样拥有极高权限。owner 作为该合约的所有者和管理员，有唯一的权限通过 withdrawTokens() 方法提走合约中的全部 ERC20 Token 至任意地址。

第一次攻击发生在以太坊主网区块高度 5930096，北京时间 7 月 9 日 8 时 6 分。攻击者利用 owner 身份，首先调用 withdrawTokens() 转走 0.1 ERC20 ETH 进行攻击测试 [4]。

三分钟后，攻击者再次转走 22000 巨额数量的 ERC20 ETH 至其控制的地址（0x33ed22f4b6b05f8a5faac4701550d52286bd735a）上 [5]。

随后，攻击者再调用 Ether Token 合约（0xc0829421C1d260BD3cB3E0F06cfE2D52db2cE315）的 withdrawTo() 方法，将 ERC20 版本的以太代币兑换为真实以太币 [6]。

至此，22000 个 ETH 便完全被攻击者借用管理员身份所盗走。

攻击者还控制了以下账户，如法炮制地偷走其账户余额，以及其所管理合约中的代币。

0x0024d891047e844186758f89eb2f4dcfbb02c952
0x00894a35bc9deea9f9e20040c21c5607740a37a0
0x5aa9e9de3e667ad79a097b4b75ccde10acb7f930

目前，区块链浏览器网站 EtherScan 已将攻击者的地址标注为 Fake_Phishing1701 和 Fake_Phishing1702。此外，Bancor SmartToken ERC20 合约也由 owner 完全控制，目前是一个名为 MultiSigWallet 的合约，暂未被盗用。

owner 对 SmartToken 合约具有以下权限：

• owner 可通过 disableTransfers() 任意禁用转账功能

• owner 可通过 issue() 任意增发代币

• owner 可通过 destroy() 任意销毁代币

以上这些功能均通过 ownerOnly 进行限定，换句话说，owner 对 Bancor 合约拥有最高权限。

Bancor 团队如何处理被盗事件

Bancor 项目方在攻击发生后，识别出攻击者地址，声称冻结了攻击者偷来的 BNT 代币。经我们调查，Bancor 管理员实际动用了 destroy() 方法来“销毁”用户手中的 Token。

function destroy(address _from, uint256 _amount) public ownerOnly {
    balanceOf[_from] = safeSub(balanceOf[_from], _amount);
    totalSupply = safeSub(totalSupply, _amount);
    ...
}

管理员可以从任意账户 _from 中扣除任意金额 _amount 的 Token，同时将总供应量 totalSupply 缩减。

这就是常说的 烧币 功能。由于攻击者在得手后，将偷来的币分散到若干个地址中。Bancor 的管理员不得不挨个依次调用 destroy() 来销毁对应地址的代币，再调用 issue() 方法将烧毁的币重新增发到自己手中。但此补救方法对于 NPXS Token 和已转走的 ETH 无效，这些被盗的币将被转至交易所抛售。

Bancor 团队也发表声明称普通用户的钱包没有受到影响，并进一步解释铸币、烧币以及存储大量以太币是他们协议中价格发现机制的一部分。

Bancor 安全事件的影响与反思

除开巨额被盗事件，Bancor 团队的这一声明和处理方式，同样引起了社区的恐慌。人们纷纷质疑 Bancor 项目智能合约中 owner 管理员的超级权限，甚至称之为“后门”。

Udi Wertheimer 早在一年前就曾发文抨击 Bancor 项目无论是众筹合约还是 ERC20 Token 合约都缺乏良好的设计，称所有的 Token 都由 Bancor 团队完全掌控，管理员拥有绝对控制权，极度中心化 [7]。而 Bancor 团队则一直声称自己十分重视安全，并采用业内最佳的钱包和私钥管理方案 [8]。不过，他们并没有披露此次被盗事件的细节，如攻击者如何能控制多个管理员账户。

我们把目光放至整个通证生态。社区参与者对管理员拥有的权限知之甚少，而项目方的相关披露与风险提示更少。安比(SECBIT)实验室也正在智能合约风险列表中收录各类权限过高问题 [9]，试图借此引导社区重视这些问题。

https://github.com/sec-bit/awesome-buggy-erc20-tokens

对于 Token 合约，当有账户存在超级权限时，整个 Token 生态极容易发生单点失效。致命问题可能会出现在两个方面，一是项目方作恶，二是超级管理员身份被盗用。当 Token 的价值全部依赖在某一个人或少数几个人身上时，可想而知这其中暗藏的风险会非常之高。以 Bancor 为例，在巨大的经济利益面前，即使我们信任了发行方不会滥用权限，却依然无法保证别有用心者不会借此攻击。对于发行与运营极度依赖项目方的 Token，可能我们永远无法形成类似对比特币的共识与信仰。

Bancor 危机也给我们带来很多反思：

• Bancor 是否是真正的去中心化交易协议

• 智能合约在哪些情况下需要管理员

• 合约管理员权限的边界在何处

• 如何保障钱包及私钥安全

管理员权限是把双刃剑。在 Bancor 事件中，黑客利用了管理员权限盗取代币，而项目方也正利用了管理员权限来降低损失。不过我们认为，开发者依然可以通过良好的代码设计来降低 Token 和 协议合约对管理员的依赖。同时，我们也号召大家，去更多地了解相关项目的智能合约（它可能跟你想象的不太一样），关注手中的 Token 到底由谁控制，利用社区力量监督项目管理员权限。

参考文献

[1] CoinAlpha 对 ERC20 乱象的总结 https://medium.com/finance-3/the-myth-of-the-erc-20-token-standard-ab0d76cf8532
[2] Status 合约代码 https://etherscan.io/address/0x744d70fdbe2ba4cf95131626614a1763df805b9e#code
[3] FunFair 合约代码 https://etherscan.io/address/0x419d0d8bdd9af5e606ae2232ed285aff190e711b#code
[4] 第一次攻击测试 https://etherscan.io/tx/0xf9fd6ac9bb4e632cf07d5b80b59bb6e417fe52305ea720e552ca6ca204951629
[5] 第二次攻击 https://etherscan.io/tx/0xf9fe97d642705fa016c4f8d11ea13ce581ba75c57ac455586254e15d915e9bde
[6] 兑换成 ETH https://etherscan.io/tx/0x43a964e635f31b0cc329db6f980f09096054e4e3a627c85654852fd026b92ba0
[7] 对 bancor 的质疑 https://medium.com/unchained-reports/bancor-unchained-all-your-token-are-belong-to-us-d6bb00871e86
[8] bancor 的回应 https://blog.bancor.network/response-to-bancor-unchained-cdb3bd2ba505
[9] SECBIT 智能合约风险列表 https://github.com/sec-bit/awesome-buggy-erc20-tokens/blob/master/ERC20_token_issue_list_CN.md#c-%E6%9D%83%E9%99%90%E7%AE%A1%E7%90%86%E9%97%AE%E9%A2%98%E5%88%97%E8%A1%A8