Post Mortem — Safenap DAO Module Bug
Gnosis SafeSnap DAO Module: Summary and Sequence of Events
Our now unsupported RNBW token was exploited by minting 100,000,000,000,000 tokens and swapping it in our v2 Uniswap RNBW:ETH pool (that did not have that much liquidity as we were in the process of giving our users a new token). V1 pools (XSGD, TCAD and TGBP) were also affected, where the ownership of the pools were transferred to the attacker’s address. Thankfully, the pools are built in such a way that the owner cannot withdraw funds on behalf of users, so the remaining v1 LPs (of which there were only ourselves and one other team that we have already contacted) were not affected.
- See wider attack on other DAOs due to compromised Gnosis DAOModule (Reality module) https://twitter.com/Ali_run/status/1575277566906310657?s=20&t=I8NSKf643OQSy2mLqxDlCA
- See walkthrough by https://twitter.com/AnciliaInc/status/1578911092923076608?s=20&t=V_duu_6ICd8TDYnA7MF1Eg
[10/09/2022 6:28PM] — PeckShield reported the issue in our shared TG group pasting this tx link https://etherscan.io/tx/0xc18ec2eb7d41638d9982281e766945d0428aaeda6211b4ccb6626ea7cff31f4a
[10/09/2022 6:35PM] — Our team did initial report confirmation and investigation
[10/09/2022 6:50PM] — War room opened in Zoom with Andrei Simion of Akira Tech
Team identified the attack vendor -> a Gnosis Safe DAOModule was compromised, which our Ops multisig was integrated with last year (to enable off chain gasless voting). It was given permission to vote and hence was able to exploit transfer of ownership of our contracts.
[10/09/2022 11:59PM] — Team finished securing ownership of all our Ownable contracts directly to a ledger wallet that we controlled and no longer a gnosis safe that had enabled modules + removed all SafeSnap modules on the affected Ops multisig
Investigation Recap
Trace:
https://ethtx.info/mainnet/0xc18ec2eb7d41638d9982281e766945d0428aaeda6211b4ccb6626ea7cff31f4a/
Community Warnings:
https://twitter.com/AnciliaInc/status/1578911092923076608?s=20&t=p2-KxjRZs78-uFPnkltpfQ
Conclusion:
- Funds in all stablecoin pools are safe and unaffected:
The only LPs left in our v1 pools were contacted to withdraw their liquidity, which is in progress as a precautionary measure. Even though the v1 pools are now owned by the attacker, there is no way the contract owner can withdraw funds on behalf of users which was a design decision we made early on. Further, all proposals on HaloDAO’s snapshot pages can no longer be executed due to the team disabling all SafeSnap modules (whether compromised or not) on the affected Ops multisig (which we have now deprecated).
2. Our losses:
Our Ops multisig had 7.5 ETH that was taken + the small amount of ETH drained in the RNBW:ETH liquidity pool
3. RNBW token holders:
RNBW is not a supported token in the new Xave protocol (which does not have a token yet). The RNBW snapshot for new token eligibility already took place on August 5, 2022 8am UTC (see prior announcement https://medium.com/halodao/token-migration-phase-1-47eda39f7576) and we already have the final list of staked holders who will receive our new token (no public announcements have been made).
4. Regardless of the relatively low impact, the team could have assigned full time roles focused on quicker response and early detection (we were all focused on our v2 deployments last few weeks)
Next Steps / Learnings / Future Mitigation
We’re treating this scenario as a simple bug bounty given that no users were harmed and our own losses were quite manageable (essentially our “pocket ETH” for gas deployments). From here on out, our ops will include measures, such as:
- Never integrating with an external dependency that we did not audit/develop ourselves
This situation happened because of the compromised Gnosis DAOModule that we did not build but should have checked for vulnerabilities
2. Ensuring that all contract deployer wallets and multisg signers should be hardware wallets
Not that this would not have prevented this scenario, but we’ve simply decided to be more cautious
3. Improve our early detection capabilities
We have formed a group with our auditors and other security experts that first reported the issue on our channels in order to learn about what tooling they utilize to enable comprehensive and responsive contract monitoring (beyond the Defender Sentinel tools we already have). We are also going to hire a full time security role to be in charge of early warning, detection and response.
4. Always have emergency contact details of past auditors / security partners on hand aside from only core team members
This was our first real emergency scenario in ~ 1 year of operations, so it was a good run through. Luckily, Andrei Simion from Akira Tech was ready and available to help. Various security firms and auditors we have worked with in the past, such as CertiK and PeckShield were ready to offer any help and also reviewed / investigated alongside this post mortem, for which we are thankful
Detailed Exploit Analysis by Akira Tech
Read detailed walkthrough by Andrei Simion of Akira Tech https://gist.github.com/andreiashu/da5909a7230ff67a8c3b4018a9717276
