YFI Dai Vault V1 lost 11M due to an exploit by hacker(s) yesterday. What can we do to ensure idle funds are not at risk to similar things in the future?
1 Like
AFAIK Idle wasn’t at risk from this kind of exploit.
How do we ensure idle funds aren’t at risk - we can’t ensure it never happens - but we can significantly reduce the risk by security audits of contracts (which were done).
4 Likes
The attack was creating exchange rate imbalances in Curve's 3pool thanks to massive use of flash loans as described in yearn disclosure post here.
In Idle specifically we do not interact with any exchanges currently, so an eventual price manipulation should not affect Idle users. In addition we have some measures that prevent users to deposit and redeem in Idle in the same block which is what is needed to make flash loans useful.
That being said, this does not mean that the Idle protocol is bulletproof, no protocol can be considered 100% secure imho.
We have made audits in the past that you can find here Audits - Idle and maybe another audit could help make the current code even more robust, but for example another complimentary idea could be to setup a formal bug bounty program too (see recent armor.fi case).
Also having a better support (ie lower premiums) for coverage would be something that should be considered and to make this happens probably some incentivization is needed on that side.
8 Likes
I’ve already sent the team an email in this regards but have heard nothing back from them… I was a security engineer for over 5 years.
It also looks like from the post above me that they take security seriously which is a good thing but the forum forums are injection’s if the character’s are not sanitized. If the application was not sanitized code injection can occur. And to be clear IM talking about a different vector than what was used against Dai vault V1.
Indirectly, entire DeFI reputation - and numbers - suffer from each exploit in any DeFi protocol.
Affordable cover and bug bounty programs are important. Also, demonstrably responsible development and keeping smart contract complexity under control. When complexity is stacked up, APY adds up, but vulnerabilities multiply.
This incident is a good example how a latent vulnerability plus an innocent-looking well-intentioned change of a parameter can result in huge exploit.
1 Like
As the space grows this will be less of an issue. No systems are perfect. Ever. Certain technology is extremely complex and with complexity come opportunities to take advantage of said systems. It’s a natural symbiosis.
If we don’t want any possibility of hack’s we go back to pen and paper and that’s not going to happen.
This was scan only. I parsed the executive summary… When I deliver an exec summary to a company I actually show screen caps of the attack / vector that would affect the company if in fact one was found… The last company I worked with was Novartis.
If your auditor is not doing this… I don’t know what to say. Your company is new and unless the auditor is top of the line in Italy (Are they top of the line? A legit audit is VERY expensive) I’d shop around so you can get a consensus of what a good pen test is.
I saw no manual review of code. I only saw a statement saying this is what they did. I saw no proof. Did they actually do a manual review of some of the common attack vectors??
Some of what your scan showed vectors attackers could use that would cause a double spend issue… Others were scanned as “severe.” Were these mitigated by your team? The security engineers won’t do this for you, unless it’s part of the scope of engagement.
Security is a different world from developing. Be paranoid about the safety of you product and clients.
Cheers
Hey, if you found an issue in Discourse feel free to open a bug on their issue tracker or submit a bug bounty here HackerOne . What you mentioned is not a security issue on our side, and for sure it’s not related to smart contracts which is the focus here.
This is not the web2 world, audits on smart contracts works in a different way, please document yourself