背景信息

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

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

X 告警：https://x.com/PeckShieldAlert/status/1831072230651941093
前置交易（Create Pool）：https://app.blocksec.com/explorer/tx/eth/0xfda0dde38fa4c5b0e13c506782527a039d3a87f93f9208c104ee569a642172d2
其中一笔攻击交易：https://app.blocksec.com/explorer/tx/eth/0x56e09abb35ff12271fdb38ff8a23e4d4a7396844426a94c4d3af2e8b7a0a2813
被攻击合约：https://etherscan.io/address/0x6e799758cee75dae3d84e09d40dc416ecf713652

Trace 分析

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

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

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

在 batchHarvestMarketRewards 函数中进行了重入攻击

代币流向分析

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
multiclaim：Claim 1751 [MarketToken] from 0xd128
withdrawMarket：burn 1715 [StakingToken], get 1715 [MarketToken]
removeLiquiditySingleToken：burn 10611 [MarketToken], get 18733 wstETH
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，通过 addLiquiditySingleTokenKeepYt 和 depositMarket 操作将 wstETH 转换为 MarketToken ，并质押到 0x6e79合约中。

batchHarvestMarketRewards(Part2)

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

originalBonusBalance 和 leftBonusBalance 的值会按照 _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 分析得来的。这样的分析对我来说进行得并不容易，且最终输出的分析文档，也会缺乏了一些对项目架构与设计的理解，有骨没肉，读起来很干巴。我反思了一下我为何会落入如此窘境，归根究底还是对项目的不熟悉。在不熟悉项目的前提下做的攻击分析，有形无意，味如嚼蜡。这是一个不可忽视的问题，我需要想想办法。