【漏洞分析】Penpie 攻击事件:重入攻击构造奖励金额

背景信息

2024 年 9月 3日,Penpie 合约遭受重入攻击,攻击者在重入阶段向合约添加流动性来冒充奖励金额,从而获取合约内原有的奖励代币。资产损失高达 2734 万美元。

2024 年 5月,Penpie 平台新增了推出了无需许可的资产池功能,即允许 Pendle 上的用户可以在该平台上自建任何 PT 或 YT 代币的 LP 资金池,用户在 Penpie 平台上存入 LP 后,可以额外多获得一份代币奖励。

Trace 分析

攻击者首先在前置交易中新建了一个 market,并将 SY 地址设置为攻击合约 0x4af4

随后在攻击交易中,攻击者闪电贷了四种资产(由于四种资产的操作类似,我们选择其中一种资产 wstETH 进行分析)

闪电贷内进行了这几类操作

batchHarvestMarketRewards 函数中进行了重入攻击

代币流向分析

  1. 0x6e79.batchHarvestMarketRewards:
    1. redeemRewards:
      1. [Reentrancy] addLiquiditySingleTokenKeepYt:deposit 16010 wstETH to [Pendle: RouterV4], get 8860 [MarketToken]
      2. [Reentrancy] depositMarket:deposite 1751 [MarketToken] to [0x6e79], received 1751 [StakingToken]
    2. queueNewRewards:Claim 1751 [MarketToken] to 0xd128
  2. multiclaim:Claim 1751 [MarketToken] from 0xd128
  3. withdrawMarket:burn 1715 [StakingToken], get 1715 [MarketToken]
  4. removeLiquiditySingleToken:burn 10611 [MarketToken], get 18733 wstETH
  5. transfer:Repay flashloan

漏洞分析

CreatePool

任何用户都可以在 Pendle 上注册 Pool(market)

https://etherscan.io/address/0x588f5e5d85c85cac5de4a1616352778ecd9110d3#code

其中的 onlyVerifiedMarket 检查,会检查 pool 地址是否在 allMarkets 中。而任何人都可以创建池子,绕过这个限制。

https://vscode.blockscan.com/ethereum/0x45cF29F501d218Ad045EB8d622B69968E2d4Ef5C

batchHarvestMarketRewards

batchHarvestMarketRewards 函数中,通过计算调用 market.redeemRewards 函数前后的 MarketToken 数量差值,来得到作为奖励代币的 wstETH 数量。

攻击者利用这个设计缺陷,调用 0x6e79.batchHarvestMarketRewards 函数触发重入攻击,使得 bounsTokens 的值增大。

https://vscode.blockscan.com/ethereum/0xff51c6b493c1e4df4e491865352353eadff0f9f8

batchHarvestMarketRewards(Part1)

redeemRewards

由于 market 合约为攻击者创建的合约,其 SY 在创建时被设为了攻击合约的地址。

https://vscode.blockscan.com/ethereum/0x40789E8536C668c6A249aF61c81b9dfaC3EB8F32

函数调用流程

redeemRewards -> _redeemRewards -> _updateAndDistributeRewards -> _updateAndDistributeRewardsForTwo -> _updateRewardIndex -> _redeemExternalReward -> StandardizedYield.claimRewards

SY 为攻击合约地址,在 claimRewards 函数中进行重入。

[Reentrancy] addLiquiditySingleTokenKeepYt & depositMarket

[Reentrancy] addLiquiditySingleTokenKeepYt:deposit 16010 wstETH to [Pendle: RouterV4], get 8860 [MarketToken]

[Reentrancy] depositMarket:deposite 1751 [MarketToken] to [0x6e79], received 1751 [StakingToken]

重入攻击 trace,通过 addLiquiditySingleTokenKeepYtdepositMarket 操作将 wstETH 转换为 MarketToken ,并质押到 0x6e79合约中。

batchHarvestMarketRewards(Part2)

通过重入攻击,使得合约在计算 originalBonusBalance 奖励数量时误以为获得了 1751 的奖励(实际上并没有获得任何奖励,余额多出来的部分是重入的时候添加流动性那部分)。

originalBonusBalanceleftBonusBalance 的值会按照 _harvestBatchMarketRewards -> _sendRewards -> _queueRewarder 的调用路径传递到 _queueRewarder 函数中。

此时合约会向 0xd128 地址发送 1751 _rewardToken

攻击者在通过重入添加流动性时,所添加的代币数量 1751 等于 0x6e79 合约中代币余额的数量 1751,其目的是构造"新增奖励"的数量等于"账户余额",使得接下来的 queueRewarder 函数将 0x6e79 合约中的所有代币转移到 0xd128。

queueNewRewards

queueNewRewards:Claim 1751 [MarketToken] to 0xd128

0xd128 从 0x6e79 处转移奖励代币。其中0xd128是rewardPool合约。

multiclaim

multiclaim:get 1751 [MarketToken] from 0xd128

攻击者从 0xd128 合约中领取奖励(完成获利,这笔资金的来源是 0x6e79 合约的余额)

withdrawMarket

withdrawMarket:burn 1751 [StakingToken], get 1751 [MarketToken]

取回在重入中通过 depositMarket 存入的 1751 [MarketToken]

removeLiquiditySingleToken

removeLiquiditySingleToken:burn 10611 [MarketToken], get 18733 wstETH

此时攻击者手里持有原来的 8860 ,加上攻击所得 1751,一共持有 10611 [MarketToken]

最终攻击者移除 10611 流动性,获得 18733 的 wstETH。

Repay flashloan

向闪电贷归还 16010 wstETH,获利 2723 wstETH。

后记

这次的攻击事件影响挺大的,涉及的金额也是巨大。在事件发生以后,许多安全从业人员都对这件事情进行了分析,我也第一时间尝试着从 trace 去分析这个攻击事件。由于当时事发不久,还没有厂商公布详细的漏洞分析结果,再加上个人叛逆的心态想着难道不参考别人的分析报告我就分析不出来了吗,这次的攻击事件分析是在一天的时间内硬啃 trace 分析得来的。这样的分析对我来说进行得并不容易,且最终输出的分析文档,也会缺乏了一些对项目架构与设计的理解,有骨没肉,读起来很干巴。我反思了一下我为何会落入如此窘境,归根究底还是对项目的不熟悉。在不熟悉项目的前提下做的攻击分析,有形无意,味如嚼蜡。这是一个不可忽视的问题,我需要想想办法。

相关推荐
阿菜ACai4 天前
【项目学习】Morpho 借贷协议简单调研
defi
阿菜ACai19 天前
【漏洞分析】Vestra DAO 攻击事件:这个质押项目它取款不核销呀
漏洞分析
阿菜ACai21 天前
【项目学习】Pendle 项目的简单调研
智能合约·defi
xzajyjs2 个月前
CodeQL学习笔记(3)-QL语法(模块、变量、表达式、公式和注解)
web安全·渗透测试·漏洞分析·代码审计·codeql
阿菜ACai3 个月前
【漏洞分析】20240507-SATURN:当闪电贷遇上有缺陷的通缩机制
智能合约·漏洞分析
阿菜ACai4 个月前
【漏洞分析】OSN 代币攻击事件:一笔资金伪造多个分红大户
智能合约·漏洞分析·solidity
Soujer4 个月前
记一次CSDN认证模块后端未校验漏洞
安全威胁分析·漏洞分析·csdn
阿菜ACai5 个月前
【漏洞分析】Li.Fi攻击事件分析:缺乏关键参数检查的钻石协议
漏洞分析
阿菜ACai5 个月前
【漏洞分析】DoughFina 攻击事件分析:不做任何参数检查的去杠杆合约
区块链·智能合约·漏洞分析·solidity·defi