Hundred Finance 攻击事件分析

Hundred Finance

背景知识

Hundred Finance 是 fork Compound 的一个借贷项目，在2023/04/15遭受了黑客攻击。攻击者在发起攻击交易之前执行了两笔准备交易占据了池子，因为发起攻击的前提是池子处于 empty 的状态（发行的 hToken 数量为 0）。

准备交易：

1. https://optimistic.etherscan.io/tx/0xf479b1f397080ac01d042311ac5b060ceccef491867c1796d12ad16a8f12a47e
2. https://optimistic.etherscan.io/tx/0x771a16e02a8273fddf9d9d63ae64ff49330d44d31575af3dff0018b04da39fcc

攻击交易：Phalcon || Tendery

交易分析

两次准备交易一共存入 63816 + 30000000 = 30063816 wei WBTC，获得 3190800 + 1499976495 = 1503167295 wei hWBTC

WBTC decimal = 8，hWBTC decimal = 8

---

执行攻击交易，首先从 AAVE V3 闪电贷出来 500 WBTC

通过 tendery 的模拟交易可以查询到，在攻击交易执行前，池子中存在 30064194 wei WBTC

首先 redeem 之前存入的所有 WBTC，将池子还原到 empty 的状态。

redeem 之后池子中存在 378 wei WBTC（其中1wei为留存资金，377wei为reserve资金），发行 0 hWBTC。empty状态仅代表 hWBTC 的 totalsupply 为 0。（如果先入为主地认为 WBTC的数量也为0，那么当你看到后面的时候会发现凭空多redeem出来了1 wei WBTC）

创建合约 0xd340 并往其中发送 50030063816 wei WBTC

---

合约 0xd340：

首先存入 4 WBTC，mint 200 hWBTC

redeem 19999999998 wei hWBTC，收到 4 WBTC。此时合约持有 2 wei hWBTC

向池子转入 50030063816 wei WBTC，然后借出 1021.915074492787011273 ETH

调用 redeemUnderlying 函数取出 50030063815 wei WBTC，消耗 1 wei hWBTC。此时合约持有 1 wei hWBTC，池子持有 1 wei WBTC

---

攻击合约调用 liquidateBorrow 函数对创建的 0xd340 合约的债务进行清算。支付 0.000000267919888739 ETH，获得 1 wei hWBTC。

redeem 1 wei hWBTC，获得 2 wei WBTC，此时池子重新回到 empty 状态。这样做的目的是为了可以再次掏空其他池子。

把 50030063817 wei WBTC 转移走

随后攻击者又再进行了6次相同的操作来掏空其他的池子完成获利，文章篇幅有限就不再展开说明。

漏洞代码分析

合约 0xd340 在进行 redeem 操作时利用了精度丢失的漏洞，获取超额的 WBTC 。漏洞的发生在于 redeemFresh 函数中。

进入到 trace 分析，发现在 truncate 函数中进行了精度丢失。

跟进代码查看 truncate 函数的具体实现方法，在对输入参数 exp 除 1e18 的时候发生了精度丢失。

攻击细节分析

在分析攻击的过程中，对一些细节的部分存在着困惑，尝试着用生疏的技巧浅浅的分析一下。

为什么要先 mint 再 redeem，剩余 2 wei hWBTC

因为 mint 函数只能根据抵押物的数量来 mint hToken。也就是说在 initialExchange = 0.02 WBTC/hWBTC 的情况下，即使是传入 1 wei 的 WBTC，也会 mint 出 50 wei hWBTC。想要得到 2 wei hWBTC的剩余，没办法通过直接 mint 2 hWBTC 的方式（因为你无法提供 0.04 wei WBTC），所以只能先 mint 出大量的 hWBTC，然后再 redeem 使其剩余 2 wei。

所以按道理来说是不是先 mint 出 50 wei hWBTC，再 redeem 48 wei hWBTC 也可以？

为什么要剩余 2 wei hWBTC，而不是其他数量

剩余一定数量的 hWBTC 是为了后续构造精度丢失的攻击，使得合约从 hWBTC 的数量来计算抵押率是满足的，从而批准这笔 redeem，而实际上借出的 WBTC 数量是不满足抵押率要求的。而攻击者构造 2 wei 的这个数量就是为了通过精度丢失，是的超额借出的 WBTC 数量最大化。

假设在 2 wei 的情况下，borrow 了一半价值（1 wei）的资产：

赎回价值 1.99… wei hWbtc 的 WBTC，实际销毁 1 wei hWbtc。此时超额部分为 0.99… wei hWBTC，获得的 WBTC 占总资金的 1.99 / 2 。

在 20 wei 的情况下，borrow 了一半价值（10 wei）的资产：

赎回价值 10.99… wei hWbtc 的 WBTC，实际销毁 10 wei hWbtc。此时超额部分为 0.99… wei hWBTC，获得的 WBTC 占总资金的 10.99 / 20 。

通过上面两个例子我们可以得出，剩余的 hWBTC 数量越少，攻击者通过精度丢失所获得的超额 WBTC 比例就越大。

剩余的 hWBTC 数量可不可以为 1 wei 呢？

假设剩余 1 wei hWBTC，攻击者可以借出 100% 价值的资产，此时赎回价值 0.99… wei hWBTC 的 WBTC，利用精度丢失实际 burn 0 hWBTC。这样构造最大的好处是借出的资产可以达到 100%，而 2 wei 的方案借出资产只能借出 50%。

攻击者是如何构造获利场景的

攻击者只消耗 1 wei hWBTC ，然后 redeemUnderlying 出了 50030063815 wei WBTC

攻击者先 deposit 50030063816 wei WBTC，然后 redeem 50030063815 wei WBTC，希望通过 redeem (deposit amount - 1) 的方式构造精度丢失的场景：redeem 出价值 1.999… wei hWBTC 的 WBTC，最终会 burn 1 wei hWBTC，超额收益 0.999... hWBTC。

但是由于在攻击执行前池子里剩余有 1 wei WBTC，所以攻击者直接 redeem 50030063816 wei WBTC 也是可以达到 burn 1 wei hWBTC 的目的的。也就是说只有当 redeem 50030063817 wei WBTC 的时候才会 burn 2 wei hWBTC。

这个精度缺失攻击的前提是池子中 WBTC 的数量大于 hWBTC 的数量

假设 3 WBTC，2 hWBTC，可得 exchangeRateStoredInternal = 3 / 2 = 1.5

赎回 2 WBTC，计算需要 burn 的 hWBTC 数量：2 / 1.5 = 1.333… → 1 hWBTC

可以通过一个公式来计算出攻击者持有部分 hWBTC 的情况下通过精度丢失得到最大获利的情况吗？

1. 假设池子持有 x WBTC，总共发行了 y hWBTC。攻击者持有 z hWBTC (z < y)，赎回 kx WBTC (0 < k < 1)
2. exchangeRateStoredInternal = x / y
3. 由 1 和 2 可得，要 burn 的 hWBTC 数量 = kx / (x / y) = ky
4. 攻击者为了获取尽可能大的超额收益，需要通过精度丢失漏洞构造 burn z + 0.999… hWBTC → burn z hWBTC
5. 由 3 和 4 可得，ky = z + 0.999 → k = (z + 0.999) / y

举例说明：

1. 假设池子持有 20000 WBTC，总共发行了 100 hWBTC，exchangeRateStoredInternal = 200。攻击者持有 50 hWBTC
2. k = (z + 0.999) / y = (50 + 0.999) / 100 = 0.5099
3. 赎回 kx = 0.5099 * 20000 = 10198 WBTC
4. burn 的 hWBTC 数量为 kx / (x / y) = 10198 / 200 = 50.99 → 50

如何计算出清算所需要的 token 数量

通过 liquidateCalculateSeizeTokens 函数，计算得出提供 267919888739 wei ETH，能够清算获得 1 wei hWBTC

然后攻击者执行 liquidateBorrow 函数，提供 267919888739 wei ETH 进行清算，获得 1 wei hWBTC 。具体的计算过程以及涉及的参数如下图所示：

后记

都周末了还搁这写分析文章博主是没有自己的生活的吗？