# DSM POST MORTEM

### **Authors**

<Who’s doing this?>

### **Status**

Fix deployed by all Guardians, vulnerability fixed

### **Impact**

The vulnerability hasn't been exploited

### Summary

In the process of discussing the new specification, a scenario was discovered that allows for the theft of deposit funds.

The Council Demon only checked the intersection of unused keys with deposit events in the Deposit contract.

The code before the fix: https://github.com/lidofinance/lido-council-daemon/blob/87c79c7fd42a4ef22cfe5995bd9fae3f7435e14a/src/guardian/staking-module-guard/staking-module-guard.service.ts#L210-L213

Vulnerability details:

Colluding Gardians in a quorum-sized number (4) can prepare a batch of a front-run transaction (direct tx to the deposit contract) and a deposit transaction through DSM in order to steal user ETHs. In doing so, they must find the moment when the deposit queue reaches the keys under their control. In case such a batches is sent within a single block, the check that is performed by Council Daemon will pass and the module will not be paused.

If the attack is executed in one block, the keys will go to the used state in the same block as the deposit events and the check will pass.

### **Resolution**

An additional handler for such a scenario has been added.

### **Detection**

The vulnerability was found by George while discussing the specification with Anna

## **Action Items**

- [ ] Prepare Incident Response Plan for DSM
- [ ] Optimize event cache loading to speed up deployment

## **Lessons Learned**

### **What went well**

- Quick response of the team: Dev, DevOps, Analytics (first responders)
- Coordinated teamwork in the process of preparing the fix and deploy
- It was enough to update at least one Council Daemon to fix it (свойство дизайна сервиса)
- 4 of the 6 Guardians had to collude to exploit the vulnerability
### **What went wrong**

- No tool to verify stolen ether (to find front run) (отдельный тул)
- No Incident Response Plan for DSM

### **Where we got unlucky**

- Long service update, due to reloading of deposit events (because we added the field to the event cache)

### **Where we got lucky**

- The vulnerability hasn't been exploited
- The fact that we discovered this vulnerability during the discussion of the new DSM specification
- Vulnerability is hard to exploit

## **Timeline**

- 15.30 In the call, George and Anna, while discussing the DSM 1.5 design, brought up the topic of mitigating the guardian collusion vulnerability that is changing in the proposed design. In discussing the changes that need to be made to the code for the offchain part of the DSM, it was discovered that there is probably a vulnerability in the current version of the Council Daemon code.
- 15:42 The call was ended
- 15:42 George created war room call and invited Valset Tech team for further investigations and discussions
- ~15:55 The vulnerability was confirmed and it was decided to prepare a fix asap
- ~16:00 Alex K volunteered to prepare the fix, Anna volunteered for the review
- 16:06 Problem announced in #security channel in discord, tagged @first-responders
- 16:56 Dune Dashboard by Vasiliy
- 16:59 Flipside query by Mikhail G
- 18:00 First draft of fix is ready
- 19:31 Reviewed by Eugene M
- 19:44 Reviewed by Anna M
- 20:20 Fix tested locally on fork
- 20:42 Fix deployed on testnet
- 20:54 Started on tesnet with updated cache
- 21:01 Fix deployed on staging
- 23:26 Started on staging with updated cache
- 23:35 Fix deployed on mainnet
- 23:37 Staging cache copied to mainnet
- 23:38 Started on mainnet. Works as expected

## **Supporting information**

- https://dune.com/queries/3479075/5847340/ — Dune Dashboard by Vasiliy
- https://flipsidecrypto.xyz/gregshestakov-QncCKh/q/OjAv82QdC-65/lido-deposits — Flipside query by Mikhail G
- https://github.com/lidofinance/lido-council-daemon/pull/183/ — PR with fix