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 函数的具体实现方法,在对输入参数 exp1e18 的时候发生了精度丢失。

攻击细节分析

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

为什么要先 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 。具体的计算过程以及涉及的参数如下图所示:

后记

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

相关推荐
Mitch3112 天前
【漏洞复现】CVE-2023-37461 Arbitrary File Writing
web安全·网络安全·prometheus·metersphere·漏洞复现
阿菜ACai5 天前
【项目学习】Morpho 借贷协议简单调研
defi
阿菜ACai22 天前
【项目学习】Pendle 项目的简单调研
智能合约·defi
摘星怪sec1 个月前
【漏洞复现】|百易云资产管理运营系统/mobilefront/c/2.php前台文件上传
网络安全·文件上传·漏洞复现
阿呆不呆@qq4 个月前
springblade-JWT认证缺陷漏洞CVE-2021-44910
cve·漏洞复现
阿菜ACai4 个月前
【漏洞分析】Penpie 攻击事件:重入攻击构造奖励金额
漏洞分析·defi
网友小黑4 个月前
Tomcat常见漏洞复现
web安全·tomcat·漏洞复现
运维Z叔5 个月前
记一次因敏感信息泄露而导致的越权+存储型XSS
运维·前端·数据库·安全·渗透·xss·漏洞复现
阿菜ACai5 个月前
【漏洞分析】DoughFina 攻击事件分析:不做任何参数检查的去杠杆合约
区块链·智能合约·漏洞分析·solidity·defi