Swivilian Report: Initial Audit Finding
A review of the report and our security procedures.
In our blog last month, “Securing DeFi’s Legos”, we noted the idea that in all likelihood most DeFi protocols will at some point face a security vulnerability or issue, whether within their own protocol or an integrated partner.
We first faced this fact ourselves when our partner Rari was hacked back in May (as we reviewed in our post-mortem). We managed to come away from Rari’s ~$80,000,000 loss with no losses of our own due to our own due diligence and previously established security procedures.
That said, as part of our 🐺Code4rena Audit (and the fourth audit of the codebase), a warden that goes by the pseudonym “Ronny Schiatto” found a medium risk bug in our deployed Swivel v2 codebase and reported it to the Swivel team.
With the bug found as well as immediately remediated, and the warden properly rewarded, our users face no impact, and can begin to use the platform as usual shortly.
Our Security Procedures 🔐
As already mentioned, Swivel has documented security procedures for various levels of vulnerability exposure, ensuring proper rapid response can leaves users minimally impacted.
Generally, these responses are first classified into a) issues that arise in an external integrated protocol, or b) issues that arise in the Swivel codebase.
In this particular case, the issue lay within the core Swivel codebase, meaning an immediate pause of the Swivel v2 contracts was appropriate. With the contracts paused, no funds are at risk.
With funds safe, we immediately moved towards remediation. In this case the route for remediation was identified within roughly 10 minutes, implementation was quick, and the issue was resolved within ~10 hours of its initial discovery.
With the remediation now integrated, the currently live DAI market will be transitioning to the remediated contract once the required time-based security delays are complete.
In conclusion, no action is needed on the part of our lenders.
The Report
As part of Swivel’s second Code4rena audit, nearly 50 wardens were inspecting our contracts for any issues that may exist. While inspecting the Swivel v3 codebase, Warden Ronny Schiatto then discovered an issue not in the new Swivel v3, but our currently deployed Swivel v2.
Timeline ⌛
3:07 AM: Ronny reaches out to me (Julian) through discord to disclose that he had identified an issue.
3:10 AM: I respond and take action to pause the contracts, reaching out to the team to confirm the issue and initiate remediation.
3:22 AM: Contracts are paused.
3:25 AM : Issue confirmed and remediation identified.
Workflow & Remediation
Although our principal token (zcToken) redemption workflow had been through four prior audits, the potential issue nonetheless remained undetected in the creation/redemption of matured zcTokens.
Workflow
The potential issue starts with a large flash loan, large enough to generate significant interest in the short period of time that has passed since our recent markets matured.
From there the call to Swivel.sol’s `splitUnderlying` on a matured market returns equivalent amounts of nTokens and zcTokens, although the zcTokens are redeemable immediately because the market has matured.
A call is then made to Swivel.sol’s `redeemZcToken` with the intention of returning the user their flash loan. This leads to the calculation of interest generated by the zcTokens, which incorrectly provides the user additional marginal interest.
Additional calls could then be made to replicate the same interaction, before finally repaying the flash loan.
This would allow the attacker to withdraw unclaimed market funds after a ~3 day delay post-maturity, in our case a total potential exposure of ~$30,000.
Remediation & Contract Migration
After the market was paused, the Swivel team quickly identified an effective remediation.
In order to prevent this incorrectly accrued marginal interest, we modified our ZcToken minting method to ensure zcTokens cannot be minted after maturity.
With this modification, we will migrate to remediated contracts after our security delay completes. At this point we will withdraw all funds from the currently deployed contracts, begin to and migrate all balances to the remediated codebase.
All interactions will be publicly visible on-chain, all contracts will be formally verified through Etherscan, and users do not need to take any actions during this process.
Conclusion
While the identification and remediation of this issue is relatively seamless, any issue that pops up in production deserves significant recognition.
In this case, we thank Ronny Schiatto (the 🐺Warden who helped us) while continuing to improve our security and testing processes. It may have been a part of our security processes that helped to detect the issue (i.e. the audit), however we can always do better ourselves.
Further, this highlights the necessity of bug bounties, as well as continuous review of deployed codebases.
The deployed code in particular had been through four audits, and had processed ~$250,000,000+ in volume before this report. With that context we note the huge value communities like Code4rena provide, and place a renewed focus on ensuring security and recovery procedures are in place for every sort of vulnerability (SSM soonTM).
About Swivel Finance
Swivel is the protocol for fixed-rate lending and tokenized cash-flows.
Currently live on Mainnet, Swivel provides lenders the most efficient way to lock in a fixed rate as well as trade rates, and liquidity providers the most familiar and effective way to manage their capital.
Website | Substack | Discord | Twitter | Github | Gitcoin | Careers