Jan 10 2024
- Severity: Low/Low Critical
- Status: In mitigation
- Risks:
- Intentional active Node Operator exploit
- Accidental active Node Operator operations
On Friday, January 5th, 2024, a known vulnerability was reported by anonymous security researcher 0xfuje in accordance with Liquid Collective’s Vulnerability Disclosure Policy, involving the potential for a malicious Node Operator to front-run user deposits by changing the withdrawal credentials to their own.
Only current Node Operators in Liquid Collective’s active set, who are all known entities with significant ecosystem reputation at stake, could potentially exploit this vulnerability. This same vulnerability was exposed to the Lido community in 2021 and was classified by Lido as a Critical risk with a Low likelihood of being exposed. The existing mitigations outlined below, including the reputations of the participants in Liquid Collective’s Node Operator set, were considered and evaluated during Liquid Collective’s design period. Liquid Collective is currently re-assessing additional measures to further reduce risk on the protocol and improve its operations.
Liquid Collective is in the process of designing a bug bounty program, as identified in the Vulnerability Disclosure Program, to reward responsible bug and vulnerability disclosure. Liquid Collective plans to publish a list of known vulnerabilities and areas for security research together with more information about the bug bounty program in the future. This security update aims to provide transparency into the potential vulnerability as the issue was proactively raised via the Vulnerability Disclosure Policy and is a known Low/Low Critical vulnerability.
Vulnerability
The known vulnerability identified is a front-running deposit exploit in which a malicious Node Operator could theoretically take control of Liquid Collective stakers’ ETH in 32 ETH increments. This exploit would be possible during the 32 ETH deposit transactions for registering new Ethereum validators on the network. To be clear, no validator has ever exploited this vulnerability and the Liquid Collective protocol is designed to allow users to stake ETH solely in a non-custodial manner. Each Node Operator is required to engage in all validator activities in good faith, refrain from exploiting any protocol code vulnerabilities, and operate each node in accordance with Liquid Collective guidelines.
While Liquid Collective’s Node Operators are required to set their validator withdrawal credentials to Liquid Collective’s withdrawal address, according to the Ethereum protocol’s consensus layer specifications a validator’s withdrawal credentials pair with its public key only after its first deposit is made to the Ethereum deposit contract.
Because Liquid Collective has not mandated that Node Operators make an initial 1 ETH deposit to anchor a new validator’s withdrawal credentials before that validator is chosen to activate on Ethereum with a 32 ETH deposit, a malicious Node Operator could potentially front-run an incoming staking deposit with their public key, signature, and a 1 ETH deposit. This action would change the validator’s withdrawal address to the Node Operator’s own before Liquid Collective’s depositToConsensusLayer() contract call finalizes the deposit, permanently altering the validator’s ETH withdrawal destination. Given the stage of Liquid Collective’s development and extensive due diligence applied when selecting the protocol’s current active Node Operator set, the Liquid Collective’s Node Operators’ controls are deemed sufficient to not justify any excessive capital requirements.
Previous awareness of the vulnerability
This same vulnerability was first flagged to the Ethereum research community in 2019, and was exposed to the Lido community in 2021. Liquid Collective has been aware of this potential vulnerability since the protocol’s inception, and classified it as Critical risk with a low likelihood of being exploited because Liquid Collective operates with a set of known Node Operators with leading business reputations at stake. Additionally, each Node Operator is required to operate each node in good faith, refrain from exploiting any code vulnerabilities and operate each node in compliance with Liquid Collective guidelines.
A decision was made during the design phase of Liquid Collective’s development to not implement the pre-deposit solution as doing so would require that Node Operators provide 1 upfront ETH for every pending validator key, limiting the ability to have a sustainable, capital-efficient, buffer of pending keys available.
Severity classification
When this vulnerability was exposed to the Lido community in 2021, Lido classified it as a Critical risk with a Low likelihood of being exploited. We have been aware of this since the inception of our protocol and also believe the vulnerability should be classified as Low for similar reasons, that is, because Liquid Collective operates with a set of known Node Operators with reputation risk who must abide by strict Liquid Collective Node Operator guidelines.
Mitigation approach
The vulnerability is considered low risk because Liquid Collective’s Node Operators are all known persons with reputational risk that agree to abide by strict Liquid Collective Node Operator guidelines. However, the potential for exploitation remains.
- Liquid Collective leverages the support of security-focused Node Operators that institute industry-best practices.
- Liquid Collective’s known Node Operator set (including Coinbase Cloud, Figment, and Staked) includes companies that would be reputationally impacted by any adverse actions or intentional exploit.
- Liquid Collective’s Node Operators also have additional “skin in the game.” For example, a pillar of the protocol’s Slashing Coverage Program is the Node Operator Commitment requiring that the Node Operators “collectively provide up to 0.30% of the protocol's AoP in coverage, up to a maximum of $5.0 million per Node Operator.”
- Each Node Operator is required to engage in all validator activities in good faith, refrain from exploiting any protocol code vulnerabilities, and operate each node in accordance with Liquid Collective guidelines.
- Liquid Collective has tooling in place that helps to ensure Node Operators are interacting with the protocol as intended. For example, Node Operators use Liquid Collective’s CLI to add their keys to the protocol. These client side tools perform sanity checks to ensure that the validators keys are configured correctly, are not duplicates, and are not compromised. Additionally, a second asynchronous check is performed after keys are added and before the keys are marked as fundable.
Next steps
- Liquid Collective is currently evaluating additional remediation paths to further minimize this risk on the protocol and will provide an update as next steps are identified.
- Improving documentation: Ensuring that Liquid Collective’s documentation accurately and adequately describes the protocol’s Node Operator onboarding operations, as well as the architecture of the remediations outlined above.
Conclusion
Liquid Collective is dedicated to maintaining high security standards. We recognize the importance of protecting participants' security when using the protocol, and understand that security is primordial to maintaining participants' trust.
Liquid Collective will continue to research other ways of minimizing risk, and will revisit how Lido has approached this issue since their public analysis of potential mitigations. We appreciate the research completed by the Lido community that was leveraged in our analysis of this vulnerability. Further mitigation via protocol updates to implement DVT, currently in the discovery phase, could further decrease the risk of this potential exploit.
You can view Liquid Collective’s security resources on the protocol's Diligence page.
