区块链安全月报——盘点解析 1 月典型安全事件

Cobo Labs

    此篇文章由 Cobo 区块链安全研究团队供稿，是?Cobo?Labs?的第??4??篇文章。
    跨链桥 Multichain 漏洞
    1月18日 知名跨链桥 Multichain（前身 Anyswap）发现并修复了一个针对 WETH, PERI, OMT, WBNB, MATIC, AVAX 共 6 种代币有重要影响的漏洞。凡对 Multichain Router 授权过上述代币的用户均受影响，攻击者可直接利用漏洞转走用户授权的代币。根据 19 日的官方公告，由于部分用户未及时取消授权，有约 445 WETH 被攻击者盗走。
    漏洞发生在 AnyswapV4Router 合约上的 anySwapOutUnderlyingWithPermit 函数中，由于函数对 Token 参数的合法性没有校验，攻击者可传入伪造的 Token 合约来代替原本官方的 AnyswapV1ERC20?Token。另一方面 WETH 等代币合约没有实现 permit 方法但是实现了 fallback 函数，因此在后续调用 permit 时不会发生 revert，可以继续成功执行下去。最终导致攻击者可以将受害者 approve 给 AnyswapV4Router 合约的 Token 盗走。
    关键代码如下：
    
    Cobo Comment
    对于普通用户来说，需要特别留意 Token 无限授权（ERC20 Infinite Approval ）所带来的风险。授权尽可能保证只授权用到的 Token 数量，而不要使用默认的无限授权，避免节约了 gas 却丢失了本金。对已有的无限授权要及时撤销，查询账户的授权情况可以使用 Etherscan 的工具 https://etherscan.io/tokenapprovalchecker 。
    Reference
    https://github.com/W2Ning/Anyswap_Vul_Poc
    https://theblockbeats.info/news/28774
    https://hackernoon.com/erc20-infinite-approval-a-battle-between-convenience-and-security-lk60350r
    BSC 上的 DEX Crosswise 遭攻击
    1月18日 BSC 上的 DEX 项目 Crosswise 遭受攻击，损失约 30 万美金，并造成 CRSS Token 币价闪崩。
    问题是因 MasterChef 合约 的 setTrustedForwarder 函数没有正确进行权限校验。当攻击者修改了 TrustedForwarder 后，可以实现伪造 msg.sender 的效果，从而直接获取到 MasterChef 的 owner 权限。然后再利用 owner 权限调用 set 函数设置?strategy 为攻击者的恶意参数 0xccddce9f0e241a5ea0e76465c59e9f0c41727003 。修改 strategy 后通过少量 deposit 即可 withdraw 大量的 CRSS Token 获利。
    官方公告也承认这个漏洞过于明显，似乎是开发者有意为之，其内部调查后开除了 4 个开发者。目前已经对链上数据进行了快照，后续将进行重新部署。官方 git 上已经开始进行整体的代码审计，据称后续会再联合 Certik 进行审计。
    相关代码如下：
    
    官方公告也承认这个漏洞过于明显，似乎是开发者有意为之，其内部调查后开除了 4 个开发者。目前已经对链上数据进行了快照，后续将进行重新部署。官方 git 上已经开始进行整体的代码审计，据称后续会再联合 Certik 进行审计。
    Cobo Comment
    此次攻击针对的是 MasterChef 合约，其实不会直接盗取用户的 LP 或者 CRSS token，但币价大跌还是会让持有 CRSS 的用户造成实际的损失。查看官方 doc 上无法找到项目审计报告，此漏洞比较明显，如果经过安全公司审计的话，很大概率可以暴露出来。对于个人投资者来说，未经过审计的项目还需谨慎。
    Reference
    https://twitter.com/peckshield/status/1483340900398895105
    https://crosswise.medium.com/post-exploit-update-2a24c3370466
    https://bscscan.com/address/0x70873211cb64c1d4ec027ea63a399a7d07c4085b#code
    https://github.com/crosswise-finance/crosswise-code-review-1.1
    Rari #90 即 Float Protocol Pool 遭受预言机操纵攻击
    1月15日，RariCapital 上的 90 号池即 Float Protocol 池遭受预言机操纵攻击。
    该池使用 Uniswap V3 FLOAT/USDC 交易对报价，而在攻击发生之前几天，FLOAT/USDC 池中流动性下降（只剩下约 ~$550k），低流动性给了攻击者进行进行预言机操纵攻击的机会。攻击者使用 47 ETH（价值约 $120k）在池中使用 USDC 兑换 FLOAT，导致 FLOAT 报价升高。之后再使用 FLOAT 抵押到 Rari #90 池中借出其他资产实现获利。攻击手法与 2021 年 11 月发生的 Rari #23 池 Vesper Lend Beta 攻击一致。
    Cobo Comment
    对于一些无法使用 ChainLink 预言机报价的小币种，DeFi 合约中通常会使用 DEX 作报价。目前 UniswapV2/V3 延时报价虽然可以抵抗闪电贷攻击，但无法抵抗真实的大资产操纵；而 TWAP 时间加权机制虽然可以在一定程度上提高操纵难度，但只能缓解不能根除。从开发者角度，可以考虑在合约中添加一定风控类代码针对恶意报价进行检查。对普通用户而言，则要留意相关的流动性池，提防价格操纵风险。
    Reference
    https://twitter.com/FloatProtocol/status/1482184042850263042
    https://medium.com/vesperfinance/on-the-vesper-lend-beta-rari-fuse-pool-23-exploit-9043ccd40ac9
    DefiDollar 发现潜在攻击
    1月8日 DefiDollar Finance (@defidollar) 发推表示在 DUSD 合约中发现一个潜在漏洞，合约已经暂停，所有资金安全。据称该漏洞可能是使用了区块链监测系统自动发现的。其思路是监测链上 Tornado.Cash 转账到新地址并部署合约的行为（这是许多真实攻击中的典型初期准备行为）。进一步通过对合约和相关交易的分析来发现潜在的攻击行为，发现问题时将立刻通知相关项目方进行预防。有人已经在 Forta 上实现了类似的 Agent.
    Cobo Comment
    项目方可以考虑类似的方式，通过监测链上的新合约和内存池中的交易，对于可疑的合约或交易可以进行静态分析或模拟执行，检查是否会对自身项目关联合约中的资产有不良影响。随着区块链攻防的升级，可以预见类似的监测告警系统将会越发成熟，当然攻击者也会挖掘到更多 bypass 监测的攻击方式。在传统安全中攻防持续对抗的局面在区块链安全中也将不断重现。
    Reference
    https://twitter.com/AndreCronjeTech/status/1479778350084333574
    https://connect.forta.network/agent/0x2fbec7dcd4eebf34c5b94d899109057eea3642a2400b7143e64873d453b7ba61
    Rari pool #19 攻击失败
    知名区块链安全白帽 @samczsun 发布了针对 Rari #19（Index Coop Pool）的预警推文，但后面攻击没有实际发生。
    攻击手法与前面提到的 Float Protocol Rari #90 预言机攻击是类似的。攻击者在 Uniswap V3 将约 300 个 ETH 兑换成了 BED，实现对币价的操纵。由于 Uniswap V2/V3 Oracle 都是在第二个区块才会更新币价，使攻击者无法在一个交易内完成对币价的操纵，从而可以对抗闪电贷攻击。而当使用真实的大资金进行操纵时，攻击者则需要至少等待到第二个区块才能看到币价的反应。由于 TWAP 的存在，通常攻击者还需要多等待几分钟，以使币价变得更加明显。对于此次攻击来说，攻击者也确实是这样做的。然而尴尬的是，在第二个区块出现了疑似套利机器人的存在，此地址在第二个区块立刻将将手中的大量 BED 兑换成了 ETH，维持住了原本币价的稳定。使得攻击者无法继续攻击，并且还要承担 swap 的 gas、手续费与大单交易滑点的损失。
    Cobo Comment
    Uniswap V2/V3 Oracle 虽然可以抗闪电贷攻击，但是无法直接对抗大资金操纵。因此对于流动性较小的交易对，仍然存在预言机价格被操纵的风险。从攻击者的角度看，要进行对 Uniswap V2/V3 Oracle 操纵攻击，需要较高的攻击成本，而且需要保证自己持有市场中大部分所操纵的池子的目标代币，否则就会出现上面的情况，被其他持有目标代币的大户套利，最终偷鸡不成蚀把米。
    Reference
    https://twitter.com/samczsun/status/1486243806739587076
    OpenSea 前端漏洞
    @PeckShield 发文称 OpenSea 可能有前端问题，有用户利用该问题获利 347 ETH。这个漏洞可能与 @yakirrotem 披露的问题有关。
    OpenSea 的交易架构是：
    
  • 卖家发起 listing（相当于报价），这时用户会对报价数据进行签名，表示同意以设置的价格出售其 NFT。
  • 这个签名数据会保存在 OpenSea 的链下数据库中，当买家在 OpenSea 上购买该 NFT 时，OpenSea 会把这个签名数据上链验证，通过后即可完成 NFT?transfer，OpenSea 也会收取一部分手续费。
  • 售出前，卖家也可以取消之前的 listing，被 cancel 的 listing 会在链上验签时失败，从而不会被出售。

    这里存在的问题是，OpenSea 允许在原有 listing 不取消的情况下，再次发起 listing（目前该问题已经修复）。这时虽然 OpenSea UI 上已经看不到卖家旧的报价，但其实旧的 listing 依然存在并有效。攻击者可以在 https://orders.rarible.com 中查询到旧的 listing。由于 OpenSea 的 listing 并没有 交易 Nonce 机制，旧的 listing 依然是有效的。攻击者可以通过旧的 listing 直接购买 NFT，并以新的价格售出。由于 NFT 有剧烈的价格波动，通过这种方式可以实现巨额套利。
    https://etherscan.io/token/0xbc4ca0eda7647a8ab7c2061c2e118a18a936f13d?a=9991#inventory 就是一例子：1 月 24日 BAYC 的 NFT 在 OpenSea 上先以 0.77 ETH 买入，又以 84.2 ETH 卖出。
    Cobo Comment
    普通用户建议登录 https://orders.rarible.com 查询自己是否有旧的 listing，并立刻进行取消处理。更稳妥安全的方式是直接将 NFT 转移到新地址上。
    Reference
    https://twitter.com/PeckShieldAlert/status/1485547426467364864
    https://twitter.com/yakirrotem/status/1485559864948629512
    Metamask 泄露个人 IP 漏洞
    @alxlpsc 在 medium 上披露称 Metamask 存在严重的隐私泄露问题。漏洞主要是利用了 MetaMask 自动加载 NFT 图片 URL。基本的攻击思路：攻击者在可以将 NFT 的 URI 设置成自己可控的服务器网址，并将 NFT transfer 给目标账户；当用户登录 Metamask 时，Metamask 会自动扫描账户上所拥有的 NFT，并发起指向攻击者服务器的 HTTP 请求；攻击者则可以从访问日志中得到受害者的 IP 信息。
    Cobo Comment
    区块链的匿名性主要来自链上地址与链下身份的剥离。如果能够通过链上的地址确认链下身份，在区块链场景下确实是比较严重的危害。在传统安全中泄露主机 IP 通常不被认为是特别严重的问题（毕竟一条钓鱼短信或者邮件就可能做到），但在主张匿名性的区块链世界，隐私的重要程度会再上一个台阶。相信类似的，因安全场景不同而导致漏洞级别不同的情况，在区块链这个相对较新的领域还会不断出现。
    Reference
    https://medium.com/@alxlpsc/critical-privacy-vulnerability-getting-exposed-by-metamask-693c63c2ce94
    wxBTRFLY 漏洞披露与修复
    @immunefi 的白帽黑客发现了 wxBTRFLY Token 合约中存在严重漏洞。合约中的 transferFrom 函数没有正确更新 recipient 的授权，并且会错误更新 msg.sender 的授权。
    相关代码如下：
    function transferFrom(address sender, address recipient, uint256 amount) public virtual override onlyAuthorisedOperators returns (bool) {
    _transfer(sender, recipient, amount);
    _approve(sender, msg.sender, allowance(sender, recipient ).sub(amount, "ERC20: transfer amount exceeds allowance"));
    // 应该使用 allowance(sender, **msg.sender**)
    return true;
    }
    漏洞本身虽然严重但成因并不复杂（更像是开发者笔误产出的），比较有意思的是官方的修复方式。由于合约本身不支持升级，因此无法直接更新合约代码；合约不支持暂停，因此也没法用快照 + 迁移的方式转移用户资产。最终官方的措施是自己发动了攻击交易，将所有受漏洞影响用户的资产转移到了一个多签钱包中。待后面部署新 Token 合约后会再行分配。
    Cobo Comment
    ERC20 Token 已经有比较成熟的代码模板，wxBTRFLY 是在重写 transferFrom 时出现的问题。这个问题如果有完善的单元测试应该会很容易发现，项目方可能在开发过程中是缺少完善的测试流程。
    Reference
    https://discord.com/invite/rpkPDR7pVV
    https://twitter.com/redactedcartel/status/1482497468713611266?s=20
    https://etherscan.io/tx/0xf0e4ccb4f88716fa5182da280abdb9ea10ec1c61cfc5bbe87e10bdde07c229d6
    Qubit 跨链桥被攻击
    
    1 月 28 日，BSC 上的 DeFi 平台 Qubit Finance 的跨链桥 QBridge 遭受攻击，损失约 8000 万美金。
    跨链桥一种常见的实现形式是在源链的合约中抵押资产，并 emit event。由监听节点捕捉 event，向目标链的跨链桥合约发起调用，mint 等量的资产。来源链上只要有 event 事件产生，跨链桥系统就会认为有跨链资产需要转移。但如果源链上跨链桥合约代码存在问题，就可能出现没有资产抵押进跨链桥合约但仍 emit event 的情况，产生漏洞，造成目标链 Token 的错误增发。
    QBridge 就存在这样的问题。QBridge 支持抵押 ETH 和 ERC20 Token 两类资产。由于以太坊的 ETH 作为 native 代币，与 ERC20 Token 由两套单独的代码处理。在源链抵押 Token 时，会调用 deposit 方法，在抵押时 ETH 应该调用 depositETH 方法。QBridge 将零地址作为 ETH 的标识。但是实现时没有完善的校验，导致合约处理 ETH 时仍使用 deposit 方法，相当于将 ETH 当成了合约地址为零地址的 Token 处理。在转账时使用 transferFrom 则相当于是对零地址进行合约调用。而以太坊底层设计上，对 EOA 地址发起合约调用会默认成功，不会 revert。以上条件结合起来，最终的情况就是虽然攻击者在源链没有抵押任何资产，但仍可以在目标链上 mint 出大量 qXETH，实现获利。
    Cobo Comment
    目前区块链行业中多链并存，跨链桥已经是重要的基础设施。跨链桥本身由于要进行链上链下配合，整体复杂度要比普通 dapp 高上许多，因此更容易出现问题。同时跨链桥上通常会抵押大量的资产，如果可以非法转移那么获利颇丰。各个跨链桥系统似乎成为了攻击者们最近一两月中的重点目标。
    Reference
    https://mp.weixin.qq.com/s/PLbuI9JFxyFRlDlj9rPvmQ
    https://mp.weixin.qq.com/s/-kTsAs2WH5_4N4_3-XIxag
    
相关文章！