首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >Bancor 危机:Token 背后潜伏的“上帝之手”

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

作者头像
区块链领域
发布2018-07-23 17:25:39
5220
发布2018-07-23 17:25:39
举报
文章被收录于专栏:区块链领域区块链领域
本文作者:安比(SECBIT)实验室 & 轻信科技(LedgerGo)

导读:

包括 Status 和 FunFair 在内的部分国内外热门区块链项目,智能合约存在管理员权限过高的问题,或导致项目存在过度中心化的风险,相关 Token 生态极易发生单点失效。致命问题可能会出现在两个方面:一是项目方滥用权限,二是超级管理员身份被盗用。这两种情况一旦发生,相关 Token 生态可能会迅速崩塌。

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

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

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

Status 合约中有名为 Controller 的管理员角色,可调用 generateTokens() 往任意地址增发代币,可调用 destroyTokens() 销毁任意地址上的代币 [2]。但 Status 项目的白皮书并没有相关特殊权限声明。而且,这两个超级权限函数在实现上,并没有触发 MintBurn 事件,只有普通的 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 到底由谁控制,利用社区力量监督项目管理员权限。

刷屏神作《我不是药神》反思,也许区块链能改变这一切。

开发人

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2018-07-14,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 区块链领域 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 恐怖的智能合约管理员权限
  • 管理员权限过高造成损失的真实案例
  • Bancor 团队如何处理被盗事件
  • Bancor 安全事件的影响与反思
相关产品与服务
项目管理
CODING 项目管理(CODING Project Management,CODING-PM)工具包含迭代管理、需求管理、任务管理、缺陷管理、文件/wiki 等功能,适用于研发团队进行项目管理或敏捷开发实践。结合敏捷研发理念,帮助您对产品进行迭代规划,让每个迭代中的需求、任务、缺陷无障碍沟通流转, 让项目开发过程风险可控,达到可持续性快速迭代。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档