Biased trust leads to darkness - Analysis of Penpie hack

By: 九九@SlowMist Security Team

Background

According to the intelligence of the SlowMist Security Team, on September 4, 2024, the decentralized liquidity income project Penpie was attacked, and the attacker made a profit of nearly 30 million US dollars. The SlowMist security team analyzed the incident and shared the results as follows:

(https://x.com/Penpiexyz_io/status/1831058385330118831)

Prerequisite knowledge

Pendle Finance is a decentralized financial yield trading protocol with a total locked value of more than $4.5 billion. The protocol was successfully integrated with Magpie to optimize yield opportunities and enhance its veTokenomics model. On this basis, the Penpie project introduced a liquidity mining function to enable Pendle Finance's market to achieve passive income.

Pendle Finance includes the following important concepts:

• PT (Principal Token):Represents the principal at a certain point in the future. Holding PT means holding the ownership of the principal and can be redeemed after maturity. For example, if you have a PT-stETH option that expires in 1 year, you will be able to redeem stETH worth 1 ETH in 1 year.

• YT (Yield Token):Represents future income. Holding YT means that you own all the real-time income generated by the underlying assets, and you can manually collect the accumulated income on Pendle at any time. If you own 1 YT-stETH and stETH has an average yield of 5%, then at the end of one year, you will have accumulated 0.05 stETH.

• SY (Simple Yield):A contract used to wrap any interest-bearing token. It provides a standardized interface that can interact with the yield generation mechanism of any interest-bearing token.

• LPT (Liquidity Provider Token):Represents a liquidity market as a certificate for providing liquidity of the underlying asset.

• PRT (Pool Reward Token):Represents a deposit certificate for users depositing LPT tokens in the Penpie pool.

Root Cause

The core of this incident is that when Penpie registered a new Pendle market, it mistakenly assumed that all markets created by Pendle Finance were legitimate. However, Pendle Finance's market creation process is open, allowing anyone to create a market, and key parameters such as the SY contract address can be customized by the user. Taking advantage of this, the attacker created a market contract containing a malicious SY contract, and took advantage of the mechanism that the Penpie pool needs to call an external SY contract when obtaining rewards, and used flash loans to add a large amount of liquidity to the market and pool, artificially magnifying the reward amount, thereby making a profit.

Attack Step Analysis

Preparation for the Attack

Transaction hash: 0x7e7f9548f301d3dd863eac94e6190cb742ab6aa9d7730549ff743bf84cbd21d1

1. First, the attacker creates the PT and YT yield contracts through the createYieldContract function of the PendleYieldContractFactory contract, sets SY as the attack contract address, and calls the createNewMarket function of the PendleMarketFactoryV3 contract to create the corresponding market contract 0x5b6c_PENDLE-LPT.

2. Then, the attacker uses registerPenpiePool of the PendleMarketRegisterHelper contract to register the Penpie pool. During this process, the deposit certificate PRT token contract and the related rewarder contract are created, and the pool information is registered in Penpie.

3. Subsequently, the attacker calls the mintPY function of the YT contract to mint a large amount of YT and PT, the amount of which depends on the exchange rate returned by the attack contract (SY contract).

4. Immediately afterwards, the attacker deposited PT into the market 0x5b6c_PENDLE-LPT and minted LP tokens.

5. Finally, the attacker deposited the LP token into the Penpie pool in exchange for the deposit certificate PRT token.

Formal attack

Transaction hash: 0x42b2ec27c732100dd9037c76da415e10329ea41598de453bb0c0c9ea7ce0d8e5

1. The attacker first borrowed a large amount of agETH and rswETH tokens through flash loans.

2. Call the batchHarvestMarketRewards function of the Penpie pool to collect rewards from the specified market in batches. This operation triggers the redeemRewards function of the market contract 0x5b6c_PENDLE-LPT.

3. In the redeemRewards function, the claimRewards function of the SY contract (attack contract) was called externally. During this period, the attacker used flash loan funds to increase liquidity for the reward tokens (the attack contract specifically set the reward tokens to two market tokens 0x6010_PENDLE-LPT and 0x038c_PENDLE-LPT), and deposited the obtained market tokens into the Penpie pool to obtain the corresponding deposit certificate tokens.

4. Then, these newly deposited market tokens in the Penpie pool will be treated as calculated rewards, and then these tokens will be transferred to the Rewarder contract through the queueNewRewards function of the contract.

Since only the attacker has deposited in the 0x5b6c_PENDLE-LPT market, the multiclaim function of the MasterPenpie contract can be called immediately to extract this part of the LPT tokens in the Rewarder contract.

5. Finally, the attacker burns the deposit certificate PRT obtained in the third step through the withdrawMarket function of the PendleMarketDepositHelper contract, redeems the market tokens, and removes liquidity from these market tokens together with the rewards extracted in the previous step, and finally obtains the underlying asset tokens (agETH and rswETH) to realize profit.

Summary

This security incident exposed the problem of insufficient verification in the market registration process of Penpie, and over-reliance on the market creation logic of Pendle Finance, which enabled attackers to control the reward distribution mechanism through malicious contracts and obtain excess rewards. The SlowMist security team recommends that project parties add a strict whitelist verification mechanism when registering the market to ensure that only verified markets can be accepted. In addition, for key business logic involving external contract calls, audits and security tests should be strengthened to avoid similar incidents from happening again.