Researchers and Auditors at the Core of the Development of a DeFi Protocol

Transcript

hi I'm Mark Weiss and so some of you may know me as your exercise on Twitter and today I am going to present the importance of Auditors at the core of the device protocol so I'm currently independent security researcher and a private auditor at Ambit Finance I do private auditor I'm also a lead senior Watson in Sherlock D5 and I'm a security auditor at Paladin security so as my talk involves how an auditor researcher could help in all the stages of modified protocol I will first explain those stages and how an auditor could be helpful in them

the first one is development it's the stage that goes from the ideation the design of the code base and the architectural decisions um normally researchers have audited or gone through hundreds of code bases and they know the best architectural decisions and how to better design each type of code base and for instance if you are doing a borrowing and lending protocol where you want to use an dynamic or a fixed interest model whether you want to use upgradable or an upgradable contracts which type of them you want to use where you want to use a proxy pattern TPP or your ups and if it's non-upgradable

where you want to use a registry based architecture Hand by hand with a testing suit so article Auditors could help similarly in both of them the third state would be the audit the audit would happen once the protocol has already the contracts ready for minute this would be most once the testing suit has a range of more or less 100 coverage whether the protocol already also used fuzzing or reduce the internal found revising or or Echidna or whatever tooling and for independent researchers and all it could consist in a Security review that would you would you would just give the protocol and give the the report to them internally

um once this report is done uh the protocol would go to mainnet or even they would set up a bounty with any of the bounty platforms and in Maine that the researchers are are very useful because they have already a lot of experience there and there are so many things that can go wrong that their experience could be very helpful to complement the stages we would have the root causes of hacks in edifi protocol I would highlight six and uh the first one we lack of knowledge lack of knowledge would be anything that has to do with like re-entrances and their overflows or or even not understanding some eips like the AAP 150 that it's basically that you would forward 63 It Forward 63 out of 64 of the remaining

gas to external calls or other Apes like 2929 where you would choose the gas that spent on on all codes like call it changes depending whether the call has value or not the second the second root cause I would highlight it's like external vectors external vectors would be like private key leakages or something turned into the Auditors itself Point number three would be contract maintenance depending where you're having for instance an upgradable code base or non-upgradable you would have to upgrade the contracts point to the right implementations if you have a registry based architecture you have to deploy new contracts and just set up the new state variables and number four with the architectural errors architectural errors wooden glove whether you are handling correctly

external contracts where you're having for instance fallback oracles if you need them anything that has to do as I said before with um interest rates uh models if it's fixed or dynamic for landing borrowing protocols anything like that type number five we have logical errors logical errors would be anything that has to do uh specifically from for that code base that the the developers developed for instance some state that has that should not be getting at some invariant that you broke or the code which just can get to a denial of service state that you cannot recover from and six and last would be deployment scripts with it's very underlooked but by a lot of protocols and actually there

are a lot of Errors there which normal audit firms neither independent researchers do review so I I prepared an example for them so this is a contra a contract where it has it has two permissions the operator and the and the owner owner being the root permission and a correct deployment script for the contract would be basically that you would uh call The Constructor and just set the owner address and after it was called set operator and set the operator address as you can see in this contract there is only one there are more functions with highlighting one function withdraw funds that it should be only uh be go going through with the operator address as you see on the require on the last required that it checks that the that the

signature recovers it's equal to the operator so the operator should be the only one to be able to withdraw the funds in a faulty deployment script for instance uh the the developers would just forget to call set operator because it's not on the Constructor and then would cause if this is underlooked and this is uh in mainnet and the funds are just entering the contract anybody would just be able to steal all the funds because as you know EC recover with a faulty signature would return zero and it would it would pass the required signer is equal to operator so to complement all the set on uh beforehand uh here we have the benefits of having Auditors and researchers in your D5 protocol and this would complement everything like the like we spoke the root hacks

and uh the status so firstly it's the benefits in war rooms the benefits in war rooms as we know a lot of researchers have been uh mostly experienced researchers have been in war rooms before War rooms generally happen with a a protocol gets clearly demanded that now we know that happens pretty much every week so they are quite common and there's periods of time where it's critical to to act fast and and basically it's just you are in in a lot of stress and and all leaders and researchers are usually on that stress and they have experience on this so it would be a critical point where Auditors would be able to help protocols here secondly would be breakdowns of Bank boundary report that goes together with proof of concept building

pretty much any researcher auditor builds proof of context at least weekly and it's it's very critical for for for protocols to actually be able to do this proof of Concepts fasting in case they are exploited as it goes together a bit with the expertise in war rooms and same thing with uh with breaking down background reports we know that backbund reports are not always the best quality it depends on the experience of the of the of the hunters and there are a lot of times that you can say where a bucket's actually valid or Not by just looking at the report but it's not always that case there are reports that actually come with a very low quality there are findings that actually go come with a very low quality report that they

are underlooked and they're probably not very good to understand by the protocol so as Auditors have really have been through a lot of reports they could just help breaking those down implementing the fixes then you have much cheaper than paying a critical Bounty researchers and Auditors are not cheap neither but would you rather spend half a million in a critical warranty or just hire two researchers uh that they probably are not going to cost that money and you might be able to save it and largely a security-based approach on designing protocols this goes a bit with the with the beforehand design explained it is clear that a lot of bugs actually are in the code bases because they are not designed correctly it's it's

critical that the code base have a secure mindset when designing them and and Auditors do have it so they could advise in the best way to those protocols so thank you um I am Mark any any increase that you have about private auditing anything about the the presentation itself anything you want to ask me you have my email my Twitter so yeah I'm open to answer your questions