我们提供安全,免费的手游软件下载!
2024 年 9月 3日,Penpie 合约遭受重入攻击,攻击者在重入阶段向合约添加流动性来冒充奖励金额,从而获取合约内原有的奖励代币。资产损失高达 2734 万美元。
2024 年 5月,Penpie 平台新增了推出了无需许可的资产池功能,即允许 Pendle 上的用户可以在该平台上自建任何 PT 或 YT 代币的 LP 资金池,用户在 Penpie 平台上存入 LP 后,可以额外多获得一份代币奖励。
攻击者首先在前置交易中新建了一个 market,并将
SY
地址设置为攻击合约 0x4af4
随后在攻击交易中,攻击者闪电贷了四种资产(由于四种资产的操作类似,我们选择其中一种资产 wstETH 进行分析)
闪电贷内进行了这几类操作
在
batchHarvestMarketRewards
函数中进行了重入攻击
16010
wstETH to [Pendle: RouterV4], get
8860
[MarketToken]
1751
[MarketToken] to [0x6e79], received
1751
[StakingToken]
1751
[MarketToken] to 0xd128
1751
[MarketToken] from 0xd128
1715
[StakingToken], get
1715
[MarketToken]
10611
[MarketToken], get
18733
wstETH
任何用户都可以在 Pendle 上注册 Pool(market)
https://etherscan.io/address/0x588f5e5d85c85cac5de4a1616352778ecd9110d3#code
其中的
onlyVerifiedMarket
检查,会检查 pool 地址是否在
allMarkets
中。而任何人都可以创建池子,绕过这个限制。
https://vscode.blockscan.com/ethereum/0x45cF29F501d218Ad045EB8d622B69968E2d4Ef5C
在
batchHarvestMarketRewards
函数中,通过计算调用
market.redeemRewards
函数前后的 MarketToken 数量差值,来得到作为奖励代币的 wstETH 数量。
攻击者利用这个设计缺陷,调用
0x6e79.batchHarvestMarketRewards
函数触发重入攻击,使得
bounsTokens
的值增大。
https://vscode.blockscan.com/ethereum/0xff51c6b493c1e4df4e491865352353eadff0f9f8
batchHarvestMarketRewards(Part1)
由于 market 合约为攻击者创建的合约,其
SY
在创建时被设为了攻击合约的地址。
https://vscode.blockscan.com/ethereum/0x40789E8536C668c6A249aF61c81b9dfaC3EB8F32
函数调用流程
redeemRewards -> _redeemRewards -> _updateAndDistributeRewards -> _updateAndDistributeRewardsForTwo -> _updateRewardIndex -> _redeemExternalReward -> StandardizedYield.claimRewards
SY
为攻击合约地址,在
claimRewards
函数中进行重入。
[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:Claim 1751 [MarketToken] to 0xd128
0xd128 从 0x6e79 处转移奖励代币。其中0xd128是rewardPool合约。
multiclaim:get 1751 [MarketToken] from 0xd128
攻击者从 0xd128 合约中领取奖励(完成获利,这笔资金的来源是 0x6e79 合约的余额)
withdrawMarket:burn 1751 [StakingToken], get 1751 [MarketToken]
取回在重入中通过
depositMarket
存入的
1751
[MarketToken]
removeLiquiditySingleToken:burn 10611 [MarketToken], get 18733 wstETH
此时攻击者手里持有原来的
8860
,加上攻击所得
1751
,一共持有
10611
[MarketToken]
最终攻击者移除
10611
流动性,获得
18733
的 wstETH。
向闪电贷归还
16010
wstETH,获利
2723
wstETH。
这次的攻击事件影响挺大的,涉及的金额也是巨大。在事件发生以后,许多安全从业人员都对这件事情进行了分析,我也第一时间尝试着从 trace 去分析这个攻击事件。由于当时事发不久,还没有厂商公布详细的漏洞分析结果,再加上个人叛逆的心态想着难道不参考别人的分析报告我就分析不出来了吗,这次的攻击事件分析是在一天的时间内硬啃 trace 分析得来的。这样的分析对我来说进行得并不容易,且最终输出的分析文档,也会缺乏了一些对项目架构与设计的理解,有骨没肉,读起来很干巴。我反思了一下我为何会落入如此窘境,归根究底还是对项目的不熟悉。在不熟悉项目的前提下做的攻击分析,有形无意,味如嚼蜡。这是一个不可忽视的问题,我需要想想办法。
相关资讯
热门资讯