Beraborrow 被遗漏的漏洞

介绍

在这篇文章中，我们将讨论一个我们通过模糊测试发现的严重 Bug，这个 Bug 在一次安全竞赛中被忽略了。

这个 Bug 是在 Beraborrow 代码库（Liquity 的一个分支）中发现的，此前该代码库已经过多轮审计。

之所以能发现这个 Bug，是因为 Beraborrow 团队坚定地致力于应用多层安全方法，其中包括：

• 内部同行评审

• 一项仅限受邀的安全竞赛，参与者包括一些最有经验的独立审计员

• 与 Recon 合作的模糊测试，由 0xsi 领导 + 由 Alex The Entreprenerd 进行的独立审查

这突显了多层方法的重要性，因为每种方法都有其自身的优势，应用更多的层可以降低 Bug 突破某一层并进入生产环境的可能性。

风险管理的瑞士奶酪模型，每一层都降低了漏洞进入生产环境的可能性。src: https://upload.wikimedia.org/wikipedia/commons/a/a7/Swiss\_cheese\_model\_textless.svg

正如你将在下面看到的那样，这个 Bug 演示了模糊测试如何特别适合发现与舍入相关的问题。舍入是一个简单属性被破坏的根本原因：任何操作都不应降低 vault 的每股价格，从而揭示了一个可用于更大漏洞利用链中的前提条件，从而导致严重级别的漏洞。

Liquity V1 如何工作

由于 Beraborrow 是 Liquity V1 的一个分支，我们首先需要了解 Liquity 的工作原理，才能理解所发现的 Bug。

Liquity 是一种借贷协议，允许用户使用 ETH 借出免息贷款以换取 LUSD（一种 ETH 支持的稳定币），并可以按任何时间表偿还。

Liquity 允许用户通过将 ETH 存入合约来开设借贷头寸（一个 trove）。Troves 必须始终过度抵押，这意味着抵押品的价值大于借入的稳定币的价值。

一旦用户开设了一个 trove，他们就可以用他们的抵押品借入 LUSD 稳定币。Liquity 不要求用户支付周期性的利息费用，而只收取一次性费用，用户在借款时支付。

为了确保偿付能力，如果用户的抵押率低于最低值，他们的 trove 可能会被清算。清算将清算后的 ETH 抵押品分配给将 LUSD 存入 StabilityPool 合约的用户，以提供流动性来吸收来自清算 troves 的债务。

Liquity 中的系统性风险使用 TCR（总抵押率）指标来衡量。这被定义为总抵押品价值与系统中总债务的比率。这允许量化系统的整体健康状况，其中高 TCR 意味着系统有良好的抵押，低 TCR 意味着系统存在偿付风险。

恢复模式

现在我们了解了 Liquity 的工作方式，我们需要了解一旦模糊测试器通过破坏的属性给了我们一个前提条件后，可能会被利用的机制：恢复模式。

Liquity V1 引入了恢复模式，作为一种减轻系统中高风险的机制。当系统中的风险（以 TCR 衡量）过高时，将启用恢复模式，并允许系统要求所有借款人承担更少的风险，并强制原本不可清算的账户变为可清算。TCR 必须低于 CCR（临界抵押率）阈值 150% 才能触发恢复模式。

例如，如果某个头寸的 CR（抵押率 - 头寸抵押品的价值 / 头寸债务的价值）低于 110%，通常会被清算。然而，在恢复模式下，由于系统正试图降低风险，因此 CR 高达 150% 的头寸也可以立即被清算。

这样做是为了降低系统的风险，并确保所有清算人都能有利可图地执行清算。此外，激活进入恢复模式不是通过延迟或利率完成的，而是立即生效。

由于恢复模式会立即被触发，Liquity V1 已经制定了机制来阻止用户恶意尝试触发它，以便从强制清算其他用户中获利。这些安全机制包括：防止用户有利可图地自我清算，防止任何用户操作触发恢复模式（在所有操作之后进行显式检查），以及防止用户在系统已经处于恢复模式时引入更多风险。

有了这些保护措施，这种类型的攻击就被阻止在主网上尝试。

发现 Bug 的属性

在审查了许多实施类似 ERC4626 的 vault 之后，我们已经开始实施定义属性的常见做法，以检查其中的价格套利机会。基本上，这些类型的属性检查在操作后是否以意外的方式更改了每股完全份额的价格 (PPFS)。

虽然有很多方法可以对此进行测试，但这些测试可以使用全局（独立属性）或内联检查（在目标函数 handler 中）分为两大类：

• 使用奇美拉框架中的 BeforeAfter 合约，检查存款或取款操作之前和之后的 PPFS 是否有任何变化。

• 存款/取款末日式检查，检查调用 handler 后不应达到的状态。

在本例中，该属性是在 Properties 合约中作为全局检查实现的：

该属性检查存入 vault 不会导致 PPFS 降低。有关我们如何使用 OpType 对“添加”和“取款”操作进行分类，并将此定义为全局属性而不是与其中一个函数 handler 内联的更多信息，请参见 Recon 书中关于对函数类型进行分组的部分。

定义此属性并在模糊测试器运行多次后，我们不断看到它被破坏，这表明有些事情导致了 PPFS 降低。

了解模糊测试器的输出

在 Liquity 中出现 PPFS 套利的情况下，我们知道，如果此属性被破坏，模糊测试器生成的调用序列不会直接成为漏洞利用，但可以作为导致漏洞利用的前提条件。因此，我们首先必须了解为什么 PPFS 会意外降低：

从 Echidna 中中断的调用序列生成的 reproducer 单元测试，我们用它来调试中断的属性。

从上面测试的日志中我们可以看到，totalAssets 减少了 2，但在赎回后，份额的 totalSupply 仅减少了 1：

来自 test_property_removing_should_never_decrease_ppfs_1 单元测试的日志。

这表明，由于系统通过份额代币而不是资产代币支付费用，并且在这样做时进行了向上舍入，因此当用户赎回份额时，份额和资产之间的比率发生了意外变化。

更具体地说，当用户应该销毁 X - fee 份额时，向上舍入意味着没有销毁或收取 1 wei 的份额作为费用，导致资产/份额比率变得不平衡，因为现在剩余的份额比移除的资产数量应该剩余的份额更多。实际上，这降低了份额的价格，并将价值损失分摊给所有现有存款人。

将所有内容联系起来

一旦理解了错误地降低赎回时份额代币的 totalSupply 并因此降低 PPFS 的根本原因，这就是一个入口点，可用于通过触发恢复模式和清算其他借款人来攻击 Den Manager（负责管理用户特定的 vault，用户在其中存入抵押品）。

凭借对故意触发恢复模式的内在危险的了解，Alex 能够将这个低严重性的价格问题升级为可以用来对付其他借款人的高严重性攻击向量。

攻击者可以使用以下操作来降低份额价格的能力来直接触发恢复模式：

1. 开设一个 trove 并borrow足够的抵押品和债务，使 TCR 非常接近 CCR（它不能减少到 CCR 以下，因为有一个显式检查可以防止这种情况）。

2. 导致 1 wei 的损失降低所有未平仓头寸的价值。

3. 价格的变化导致超过 CCR 阈值，系统进入恢复模式。

4. 反向清算所有其他 troves，从最健康的（最接近 150% MCR；最低价值）开始，到最不健康的（最接近 150% MCR；最高价值）结束，这导致比达到 CCR 阈值所需的清算多得多。

5. 平仓攻击者的头寸。

这些步骤将通过来自攻击合约的 multicall 函数执行，以确保攻击无法被抢先交易。

看看攻击者获得的收益与他们为执行攻击而必须支付的代价，我们可以看到攻击的成本相当于：

• Gas 成本

• 开仓费用

而他们从攻击中获得的收益相当于：

• 清算调用者激励（所有清算抵押品的 50 个基点）

• Gas 津贴

• 基于攻击者可以向 StabilityPool 提供的债务金额的、清算抵押品的百分比收益。如果他们使用闪电贷，这个债务金额可以显着增加，从而在攻击执行中获得更大的利润。

此测试显示了如何使用 PPFS 前提条件将代币供应量最多膨胀 4 个基点，以便在触发恢复模式时清算更多 troves。该漏洞可以通过仅将股价降低 1 wei 触发，以降低影响。

结论

我们希望以上内容能够证明，寻找可以使用模糊测试找到的、特定的前提条件，可以为已知的攻击路径打开可能性，否则这些攻击路径将无法使用。

令我们惊讶的是，这个 Bug 从为 Beraborrow 代码库举行的审计竞赛以及多次手动审查中溜走了，这证明了模糊测试具有独特的能力，可以找到这些类型的、与舍入相关的边缘情况，手动审查者通常难以在脑海中推理出来。

当与熟练的安全研究人员的能力相结合时，模糊测试可以作为一种工具，让你对代码库有其他人没有的洞察力，从而找到独特的高严重性漏洞。

如果你需要帮助定义自己的不变量测试套件，并需要一名熟练的安全研究人员充分利用它来发现其他人可能在你的代码库中错过的漏洞，请 联系我们！

• 原文链接： getrecon.substack.com/p/...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～