错误修复审查和事后分析

在与 FairySwap 团队合作中，Discreet Labs 编写了以下事后分析报告，以提供影响其用户的漏洞信息以及 Discreet Labs 团队如何实施修复。我们非常感谢 FairySwap 团队在以下问题上向 Discreet Labs 寻求帮助。

FairySwap 是 Findora 生态系统中重要的合作伙伴，并正在努力补偿受到该漏洞影响的用户。据我们了解，FairySwap 将在未来几周内发布一份补偿计划。

1. 总结

FairySwap 于 2022 年 12 月 17 日向 Findora 报告了一个漏洞，FRA 在 EVM 链上预编译的合约存在一个漏洞，该漏洞启用了 delegate_call 函数。delegate_call 函数不常用，在 FRA 预编译的契约中不应该被支持。在其他网络中，例如 Polygon，仅为 WMATIC 合约保留基本功能。该漏洞允许黑客从 FairySwap 的 LP 合约中窃取约 57,353,000 FRA( 截至 12 月 27 日，修复日期 )( 这将使黑客能够在任何 FRA<>流动性池中窃取所有 FRA)。

根据 FairySwap 的报告，Findora 立即采取行动修复了该错误。FairySwap 协助调查区块链活动、验证修复并建议硬分叉操作（0.3.37 强制升级：https://github.com/FindoraNetwork/platform/releases/tag/v0.3.37-release）。

在 Findora 开发和实施修复程序的过程中，第二名黑客于 12 月 22 日利用流动性池漏洞从受影响的流动性池中窃取了另一笔大量桥接通证。

这是第二次攻击中损失的情况。

2. 漏洞分析

2.1 Delegate_call 漏洞

在 EVM 中，除了基本的调用函数外，还有两个函数：delegate_call 和 static_cal。EVM 将在智能合约执行之前为基本调用函数设置上下文。上下文包括以下内容：

• Value
  

• Sender：智能合约的调用者

• Address：执行代码副作用的智能合约地址

例如，当智能合约 0xa 通过 1 Wei 调用智能合约 0xb 的函数时，上下文为：

如果 0xb 调用 0xc 没有任何费用，则 0xc 执行的上下文是：

对于 delegate_call，它不会在代码执行时更改上下文。以前面的例子为例，如果智能合约 0xc 中的 delegate_call 调用了智能合约 0xd 的一个函数，则 0xd 执行时的上下文为：

一般而言，delegate_call 用于在不改变智能合约存储的情况下升级智能合约的逻辑流程。

回到漏洞攻击，问题的核心是 FRA 预编译合约的实现。为了通过 ERC20 标准接口与 FRA 进行交互，Findora 为开发人员提供了预编译接口。但是在预编译合约的实现中，缺少对 delegate_call 的检查。结果是代码在目标合约和 delegate_call 函数调用的合约上执行的副作用。

利用这个漏洞，黑客（0x3d4d08292B58b715b5908753908cb9AA54B2Aa24）进行了如下攻击：

1. 利用 delegate_call 漏洞部署恶意智能合约（https://evm.findorascan.io/tx/0xe854e320d7a786764fcfb2ab239c8dab9fada992348e673deafb4d8e7a60cec7/internal-transactions ）。

2. 在这个恶意合约中实现了 FairyCall 函数：

   
   

1. 在 FairyCall 函数中，执行了 delegate.call (approve(hacker's wallet address))
   
   
2. 发现意外的批准事件(https://evm.findorascan.io/tx/0x9e04b4c68d67ff18b2767d8fc4bda17312e159ffbf4bcd31a7f9b90cb3521367/logs)。本次事件中 topics[0]为 0x8c5b…，topics[1]为目标地址，topics[2]为黑客地址，最大 unit256。
   
   
3. 智能合约执行后，目标地址对黑客地址的余量变成无穷大。
   

在上面的步骤 2a 中，approve 函数的副作用是：

其中发送者应该是目标地址，地址应该是黑客的智能合约。如果没有 FRA 预编译合约的漏洞，这应该被执行为：

并且它不应该影响 FRA 预编译合同。然而，事实是，通过这个漏洞，副作用变成了：

黑客在预编译合约中向受害者的地址授予无限权限。有了这个，黑客就可以轻松地从受害者那里提取资产。（原文代码如上，如有感兴趣的技术科学家，可以在后台与我们联系）

以下是 FairySwap 上的所有受害 LP 合约：

0x270E323ad4d38811D7ab8592Cd5209399dfC97b7

0x2D3a68C45ffF21A77b398aD756E43191b6685c12

0xbD0b8eF52f72Ecb51ef800c748558D8Cd7A7dC1E

0x759387452688b526B497B711D57eF312BEf80B3E

0x00177706924b66b4DE0878345f14Db592603a0B9

2.2 流动性利用

在 delegate_call 漏洞的第一次攻击之后，几乎所有 FRA 都从 FairySwap 上受影响的 LP 池的一侧被抽干。以 FRA/USDT.b 为例，这个池子里的 FRA 变成了 0。

Swap/AddLiquidity/RemoveLiquidity 没有作用，因为 Uniswap V2（用于创建 FairySwap）用自己的函数代替了 balanceOF 函数。换句话说，流动性对的储备与实际持有量不一致。它可以降低加载流动性对时的 gas 费。当 pair 失去平衡时，通过一般路由器的操作总是会失败。

但是，当通过手动方式直接同步流动性对时，reserves 将与 ERC20.balanceOF 同步。并且在执行 Pair.sync() 函数后，FRA 在这些受影响的 LP 池的另一端兑换通证（USDT、ETH 等）时获得折扣，这意味着 FRA 在这些池中具有无限价值。只需少量 FRA 即可将这些水池的另一侧排干。第二个黑客利用此漏洞通过对受影响的 LP 池调用 sync() 函数来窃取受影响池另一侧的所有通证。

3. 漏洞修复

Findora 移除了 FRA 预编译合约中的 delegate_call 支持。此修复可在此处（https://github.com/FindoraNetwork/platform/pull/768 ）的合并更改中获得，可在 GitHub 上查看。

为防止进一步损失，FairySwap 团队在第二次攻击后利用 delegate_call 漏洞和流动性漏洞，立即将所有剩余代币从所有受损 LP 池转移到安全钱包。

以下是所有受损 LP 合约地址：

0x658c7ae1910A8f2494b69f9A020E7711f3441c8b

0x0f7855D3fa7739eA8cc354F3dab280Fcb0Cc77e3

0xaF64b8DC86679CCb0BC60331d324bb6c60f38B6b

0xdb9Bb9f766834EF3eB19acB43ecEC5b4b8543852

0xef14dEB182142713BB38e6e6787345adCb07Aa22

0x432920df2386D594983D81EDAb4F6D5f01eAC75D

4. 下一步措施和补偿

我们正在与 FairySwap 团队进行沟通，获悉他们拥有受影响用户地址的完整列表，并将协调补偿策略以确保其社区完整。FairySwap 团队将在未来几周内公布更多相关策略。

如有问题，请访问 FairySwap Telegram 聊天室：https://t.me/FAIRYSWAP 

Findora 将以太坊的可编程性与先进的隐私保护 ZK 技术相结合。它允许开发人员使用 Solidity、SDK 和他们熟悉的功能来构建创新的隐私 Dapp。

作为一条创新的 L1, Findora 是零知识密码学领域的领导者。它的 ZK 技术将允许开发人员将隐私和可审计性结合起来，以实现合规性。通过 SDK, Findora 为 Web3 提供了一个即插即用的隐私工具。

通过隐私保护和零知识创新，Findora 使 Web3 能够被大规模采用。

Findora 相关链接：