Decoding Pike Finance Exploit | QuillAudits

4 min readMay 1, 2024

Summary:

On the 30th of April 2024, the Pike Beta protocol was exploited for 99,970.48 ARB, 64,126 OP and 479.39 ETH, resulting in a significant loss of over $1.6 million worth of altcoins.

About Project:

Pike is a universal liquidity market optimized for native assets.

Pike enables lending and borrowing using native assets directly on their respective blockchains, eliminating the need for wrapping and cross-chain transfers.

For example, users can deposit Arbitrum’s ARB tokens as collateral on their native Arbitrum chain, while borrowing other assets on a different blockchain.

To learn more about Pike Finance head over to their documentation: https://docs.pike.finance/

Vulnerability Analysis & Impact:

On-Chain Details:

Attacker Address: 0x19066f7431df29A0910d287C8822936Bb7D89E23

Attacker Contract: 0x1da4Bc596BFb1087f2F7999b0340Fcba03C47fbD

Victim Contract: 0xFC7599cfFea9De127a9f9C748CCb451a34d2F063

Attack Transactions -

Optimism Transaction :- https://optimistic.etherscan.io/address/0x19066f7431df29a0910d287c8822936bb7d89e23

Arbitrum Transaction :- https://arbiscan.io/address/0x19066f7431df29A0910d287C8822936Bb7D89E23

Ethereum Transaction :- https://etherscan.io/tx/0xe2912b8bf34d561983f2ae95f34e33ecc7792a2905a3e317fcc98052bce66431

The Root Cause:

This exploit is related to the initial USDC vulnerability in Pike Finance’s Beta protocol that was reported last week on the 26th of April.

Reference — https://mirror.xyz/pikefinance.eth/M1ToE42vwEHuE6xlz0dVRQwPT0xpaRtpIIw2arOdBAM

In order to pause the protocol, the spoke contracts were upgraded and there was the inclusion of an additional dependency within the smart contract code.

This dependency introduced new variables which altered the storage layout — in particular, the position of the *initialized* variable.

As a result, the position occupied by the *initialized* variable was taken over by other variables, leading to a misalignment in storage mapping.

This misalignment caused the contract to behave as if it was uninitialized, since the *initialized* variable could no longer be accessed.

As a result, attackers were then able to upgrade the spoke contracts, bypassing admin access, and as a result, withdraw funds.

Attack Process:

The attacker executed the initialize function in the original contract, adding their address to the _isActive variable.
Since proxied contracts do not make use of a constructor, it’s common to move constructor logic to an external initializer function, usually called initialize.
It then becomes necessary to protect this initializer function so it can only be called once.
The initialization functions use a version number. Once a version number is used, it is consumed and cannot be reused.
This mechanism prevents re-execution of each “step” but allows the creation of new initialization steps in case an upgrade adds a module that needs to be initialized.

The attacker could then perform an upgradeToAndCall and upgrade to a malicious implementation.

How upgradeToAndCall Works -

Upgrade: The function first updates the address of the implementation contract to which the proxy forwards calls. This address points to the new version of the contract containing updated logic.
Initialization Call: After upgrading the implementation address, upgradeToAndCall executes a specified function in the context of the new implementation. This is typically used to set initial states, configurations, or perform necessary migrations that align with the new logic.
Data Encoding: The function to be called and its arguments are encoded and passed to upgradeToAndCall. This encoded data is then used to perform a delegate call to the new implementation.
Security Considerations: Because upgradeToAndCall can alter the contract’s behavior and state significantly, it’s crucial that such functions are strictly controlled.

Flow of Funds:

After the Exploit

The Project acknowledged the incident and announced it through their X handle.

How could they have prevented the exploit?

One of the main reason why this exploit happened was because after the initial attack on 26th April, in order to pause the protocol, the spoke contracts were upgraded and there was the inclusion of an additional dependency within the smart contract code and this dependency introduced new variables which altered the storage layout — in particular, the position of the *initialized* variable.

This could’ve been prevented by careful inspection, review and auditing of the upgraded implementation contracts.

Web3 security- Need of the hour

Why QuillAudits For Web3 Security? QuillAudits is well-equipped with tools and expertise to provide cybersecurity solutions saving the loss of millions in funds.

Want more Such Security Blogs & Reports?

Connect with QuillAudits on :