Hundred Finance 攻击事件分析

2023-11-12 02:15

本文主要是介绍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。

攻击合约调用 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)

  1. exchangeRateStoredInternal = x / y

  1. 由 1 和 2 可得,要 burn 的 hWBTC 数量 = kx / (x / y) = ky

  1. 攻击者为了获取尽可能大的超额收益,需要通过精度丢失漏洞构造 burn z + 0.999… hWBTC → burn z hWBTC

  1. 由 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 。具体的计算过程以及涉及的参数如下图所示:

文章转载自: 阿菜种菜的菜园子

原文链接:https://www.cnblogs.com/ACaiGarden/p/17810494.html

这篇关于Hundred Finance 攻击事件分析的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!


原文地址:
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.chinasem.cn/article/394393

相关文章

github打不开的问题分析及解决

《github打不开的问题分析及解决》:本文主要介绍github打不开的问题分析及解决,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录一、找到github.com域名解析的ip地址二、找到github.global.ssl.fastly.net网址解析的ip地址三

Mysql的主从同步/复制的原理分析

《Mysql的主从同步/复制的原理分析》:本文主要介绍Mysql的主从同步/复制的原理分析,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录为什么要主从同步?mysql主从同步架构有哪些?Mysql主从复制的原理/整体流程级联复制架构为什么好?Mysql主从复制注意

java -jar命令运行 jar包时运行外部依赖jar包的场景分析

《java-jar命令运行jar包时运行外部依赖jar包的场景分析》:本文主要介绍java-jar命令运行jar包时运行外部依赖jar包的场景分析,本文给大家介绍的非常详细,对大家的学习或工作... 目录Java -jar命令运行 jar包时如何运行外部依赖jar包场景:解决:方法一、启动参数添加: -Xb

Apache 高级配置实战之从连接保持到日志分析的完整指南

《Apache高级配置实战之从连接保持到日志分析的完整指南》本文带你从连接保持优化开始,一路走到访问控制和日志管理,最后用AWStats来分析网站数据,对Apache配置日志分析相关知识感兴趣的朋友... 目录Apache 高级配置实战:从连接保持到日志分析的完整指南前言 一、Apache 连接保持 - 性

Linux中的more 和 less区别对比分析

《Linux中的more和less区别对比分析》在Linux/Unix系统中,more和less都是用于分页查看文本文件的命令,但less是more的增强版,功能更强大,:本文主要介绍Linu... 目录1. 基础功能对比2. 常用操作对比less 的操作3. 实际使用示例4. 为什么推荐 less?5.

spring-gateway filters添加自定义过滤器实现流程分析(可插拔)

《spring-gatewayfilters添加自定义过滤器实现流程分析(可插拔)》:本文主要介绍spring-gatewayfilters添加自定义过滤器实现流程分析(可插拔),本文通过实例图... 目录需求背景需求拆解设计流程及作用域逻辑处理代码逻辑需求背景公司要求,通过公司网络代理访问的请求需要做请

Java集成Onlyoffice的示例代码及场景分析

《Java集成Onlyoffice的示例代码及场景分析》:本文主要介绍Java集成Onlyoffice的示例代码及场景分析,本文给大家介绍的非常详细,对大家的学习或工作具有一定的参考借鉴价值,需要... 需求场景:实现文档的在线编辑,团队协作总结:两个接口 + 前端页面 + 配置项接口1:一个接口,将o

IDEA下"File is read-only"可能原因分析及"找不到或无法加载主类"的问题

《IDEA下Fileisread-only可能原因分析及找不到或无法加载主类的问题》:本文主要介绍IDEA下Fileisread-only可能原因分析及找不到或无法加载主类的问题,具有很好的参... 目录1.File is read-only”可能原因2.“找不到或无法加载主类”问题的解决总结1.File

Dubbo之SPI机制的实现原理和优势分析

《Dubbo之SPI机制的实现原理和优势分析》:本文主要介绍Dubbo之SPI机制的实现原理和优势,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录Dubbo中SPI机制的实现原理和优势JDK 中的 SPI 机制解析Dubbo 中的 SPI 机制解析总结Dubbo中

C#继承之里氏替换原则分析

《C#继承之里氏替换原则分析》:本文主要介绍C#继承之里氏替换原则,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录C#里氏替换原则一.概念二.语法表现三.类型检查与转换总结C#里氏替换原则一.概念里氏替换原则是面向对象设计的基本原则之一:核心思想:所有引py