Tranchess Liquid Staking Deposit Firstrun Vulnerability Analysis
Introduction
Hello, I am Jade Han, a Security Researcher at Kalos Security.
Recently, while analyzing the Prysm Client Code, I investigated past vulnerability cases related to Ethereum 2.0 Staking.
As a result, I found a vulnerability that could occur during Ethereum 2.0 Staking with Tranchess, and reported it to the Tranchess team via Immunefi about two weeks ago.
In this article, I will briefly explain Tranchess and describe the vulnerability I reported.
What is Tranchess Liquid Staking?
Tranchess Liquid Staking is a staking service for Ethereum 2.0’s Beacon Chain.
It allows users to stake their Ether to contribute to the stability of the Ethereum blockchain network and receive rewards in return.
Unlike traditional staking methods, Tranchess Liquid Staking tokenizes the staked assets to provide liquidity.
This allows users to have a token with a value equivalent to their staked assets that they can use whenever needed while also continuously receiving rewards.
To use this service, users must first deposit Ether into Tranchess Liquid Staking.
Tranchess then stakes the Ether to receive rewards from the Ethereum 2.0 network and pays a portion of these rewards to the user who deposited the Ether.
Tranchess tokenizes the deposited Ether into an ERC-20 token called qETH and provides it to the user.
Users can store qETH like any other ERC-20 token on an exchange or wallet and can exchange it back to Ether whenever needed.
In doing so, users can continuously receive staking rewards from the Ethereum 2.0 network.
Description of the vulnerability
The vulnerability I am going to explain in detail now occurs due to a structural problem between LSD and the outsourced node operator, as well as an issue with the Ethereum 2.0 Beacon client.
First, we need to understand the structure of the Liquid Staking Dapp before we can find this vulnerability.
I didn’t know much about the structure of the Liquid Staking Dapp before looking for this vulnerability, and I thought the project team of the Liquid Staking Dapp operated nodes directly as Node Operators.
However, this was a misconception, and the Tranchess team did not operate the node directly.So, who receives the tokens through Tranchess, and who operates the node?The answer to that can be found in the link below.
Tranchess Partners RockX for ETH Liquid Staking
As described in the link above, Tranchess team does not operate the nodes directly but rather entrusts them to third parties to operate.
This is also the same structure for Tranchess’s competitor, Lido.
I will now talk about the structure of the Ethereum 2.0 Beacon client.
With the transition to Ethereum 2.0, the Consensus Model of Ethereum has changed from PoW to PoS, and an official Deposit Contract (0x00000000219ab540356cBB839Cbe05303d7705Fa) has been introduced for staking.
below code is official Deposit contract code.
After calling the deposit function with the parameters pubkey, withdrawal_credentials, signature, and deposit_data_root, and the deposit is complete, a DepositEvent occurs.
Based on this event, the Ethereum 2.0 Beacon client (such as Prysm, Lighthouse, etc.) updates the staking state.
The following is the implementation code for the Prysm client.
Looking at the part that handles the Deposit Event, we can see that the balance in the Beacon state that reflects the Withdrawal credential set at the first deposit for a specific pubkey increases even if the Withdrawal credential changes for the second or third deposit.
Looking at the code, there is no error even if the withdrawal credential is different each time a deposit is made.
Considering the relationship between LSD and the outsourced node operator, the following scenarios can occur:
- If the private key managed by the node operator is leaked and used to insert a hacker’s withdrawal credential, the hacker can deposit ETH on behalf of other users, and after the Shanghai Upgrade, withdraw all the ETH using the hacker’s withdrawal credential.
- If the node operator maliciously inserts a withdrawal credential other than the one agreed upon with Tranchess and uses a newly created credential after the Shanghai Upgrade to withdraw all the ETH.
Although such scenarios can occur, Tranchess’s EthStakingStrategy Contract had no mitigation for these malicious scenarios.
The following is the code for this:
Tranchess publicly uploaded these pubkeys to the NodeOperatorRegistry Contract, and the list is as follows:
- 0xb1b620b54b1909fdf1defc96e60350040cf7fef3dbdfa75099f977c835331201 644fe9caa6d028dcef5c6d953cdc0d59
- 0xa105b2b7c4212b10a62389fae02f58f49c1f1570ec3e5e0a41c46691ec2de464519d9c234b9bc1d834107a7644b570ec
- 0xa8f88f29387bb0ed8a3d7248dc6e59aa798852915e0e86673d901c0ebb3dbe09278d71526e9c48a041a3a3159e456e76
- 0x95996aa22e15e86284ce82014a09611b8157bf6cb85d8ce8d2c26df8818f654ec0b61d84bc28d950aee1504aa61f8b99
- 0xb79cf2db73b9f7a7b4b921b7957c0505c8289f0b9909cd91f8361c85d3736a4fa94388baf328bd458c08b88a5f358b82
- 0x93566ae24339434b6d78c05e89d00fc4c1bd465d9c968c5f7553c4ab276a407613438c31be285f0ee68f25417c3853c2
- 0x809ec014355946f5e1edce029fc02a70db36b2d64f165a69faa56eee9cae832fb93c2406ef10cf3631f3b85955558d2b
- 0xad764e91cdc35d0947902501db3a3d7e11317da0326020d5b1ba6479683d5c3d2980d9ee34c185908eb0184783cafc74
- 0x877b53e9863eec56e1c72820204b807da851d362234521355119063faa1e86ae6aec73c5c573c90b2017498bcb2b5baa
- 0xabc410a16ce29462ef454b7006a49614deb1df486be9f68c8d7c6cce99a02b911a71b37f49352b4f420558e1d90c98c0
- 0xa78cf179be6372b7e7db4f9790b189f5b4da488e3f8c4e7fd504821dce3ebcdef20197c34874e61e2f82ab4f2eb4b136
- 0x84cc0d2fa72d2eaeba75166996e5be70fb2363c5b12ec944890f1ee3a6bd5aac04d7cda3a41af911fa1733719bd7dca8
- 0xacb09993792576384bd2a1f7e62a9df8774946c317d57ac45aab4e715404a7738efd3cdd4604433e9fa277d8883a6b96
- 0xace03da219de936ff1b4c3abf88ec016d14a23232866c3c4ccdc726ebac6f7d63b1605a3a83e4688e5022ddf9a0a6ca6
There has been a similar type of vulnerability that occurred in the past.
It is described in the following link:
RocketPool and Lido Frontrunning Bugfix Review
Frax Ether Liquid Staking contest
Mitigation
The Tranchess team applied the mitigation created by Lido to their code.
The details are available in the link below.
lido-improvement-proposals/lip-5.md at develop · lidofinance/lido-improvement-proposals
Below is the history of the code they patched.
https://github.com/tranchess/contract-core/pull/301
This Pull Request addresses a front-run vulnerability by restricting public access to certain functions and introducing a new contract called SafeStaking.
A trusted off-chain group verifies the pubkey used by Tranchess and provides signatures accordingly.
When the trusted off-chain group provides the signatures and submits them, the safeDeposit function checks the get_deposit_root, making it a secure code even if a malicious front-runner attempts front-running.
There is a different explanation for Mitigation attached to Tranchess Team’s blog.
The link is provided below:
https://tranchess.medium.com/recap-deposit-front-run-vulnerability-mitigation-cfc66ef8c50d
Conclusion
When creating an Ethereum 2.0 Liquid Staking Dapp, it is important to consider the structural issues with the Beacon chain client’s implementation.
Previous examples such as Rocket Pool and Lido should be referenced, and it is important to have a good understanding of the implementation of Beacon chain clients such as Prysm, Lighthouse, etc.
This will help ensure that the Dapp is created with a secure and effective design.
Despite the bear market, I am grateful to Tranchess for paying me a large bug bounty.
We will continue to research other chains’ Liquid Staking Security and hope to write another article with more achievements soon.Thank you for reading.
