web3 security: Incident Responses for DeFi retail users | Marco Lau, LazyOtter | ETHTaipei 2024

uh gmgm uh thank you all for coming my name is Marco and today I'll be talking about uh web three security particularly incident response for D retail users okay so I'm the Project Lead of lazy a I'm I'm not a de I'm going to disclaim that about that first because you know like it's not not going to be a very technical thing but I wish I can have the coding skills but I don't yet but so yeah so a little bit about lazy order and we're a native project on scroll and what we want to do is want to bring like um proactive security to all uh retail users and here here's my um a couple of my show shows and the QR code and yeah and if anyone want to check out know more about us you can scan the C code here and yeah go so a little bit about the current background you know like defi Market has been getting warmer and there are more and more defi activities recently but so did like security incidents so you can see up here in the uh in the news uh that compared to last year the same period of time there's a 15% increase in uh security incidents and yeah so it means that maybe it's time for us to pay attention to defi security now and what comes to your mind when I talk about def5 security I believe most of the people would think of like fishing scams or defi hacks but did you know which one is actually more severe Yes actually uh defa hacks are eight times more severe than um fishing scams and we're going to look about that more later so we're going to go through fishing first we can see the number here know last year there was 295 million that was um stolen from fishing scams and 324k victims which is quite a lot you know it's a crazy number and it comes in all forms of attacks from like like Twitter social medias or like other like Discord or even ads but I think people are getting more aware of it in the sense that we all know that we shouldn't like click on some ad or sponsored links and you know because apparently Twitter and Google aren't doing a very good job in blocking away these kind of things and yeah we know we you check the domain first and there are even more solutions like coming up that like some kind of like Chrome extensions browsers that tell us oh this is like a a scam link stay away from it and yeah the try uh the point I'm trying to make is that there are more um solutions that uh or as a user we can actually Pro proactively do something to protect ourselves from these fishing scams we just have to be more careful and yeah but then how about defi hacks uh before I go into defi hack I just want to give a shout out to our partner slow Miss because um we're going to drove from the report a lot and yeah it's a very insightful report and you guys should take a look if you have time so what was the how was the def attack incidents in 2023 uh 2.4 billion was hacked in that year and which me it's actually eight times the number of like the fishing scams and unlike fishing scams you know like uh these kind of like um def hacks are harder for users to protect themselves and you know like if we take the average TL from last year 48 billion there it means that there's a one in 20 chance that your money is going to be hacked or you know like Patrick uh and and as Maron um Sharon he even interpret as like you know every one person every 20 person there's one person's money going to be hacked in defi so yeah you see like the incidents has hack incidents have been going more and more lately and what can users do to uh what can we do to protect ourselves is are there any solutions well one of the more famous One is actually uh called inent response it's something that the project side couldn't do they can basically um embed something into uh some um response to their um developers workflow so like if they detect anything happen then they can automatically pause a PO and take some actions you know so they're going to identify threats you know prepares like how to uh respons to it and then they're going to ongoing monitor it respond and then improve a up contract upgrade at ATC you can see like these are the actions they can take you know they PA p request token frees and something but the thing is like these things like the project side have to like actually adopt these uh insance response so yeah this is like the framework of open zeins Defender I forgot to mention about it but yeah but if the project side did not did not um Implement these kind of uh codes into the developer workflow and how can a retail users protects you know unfortunately right now like most of the when it comes to like us users if we want to protect ourselves from these Divi acts maybe like the only thing we can do right now is like um D you know like we can do our own research we can look at like whether project is legit it's safe or not but it's always easier said than done you know um most of us I mean like for me but like also most of the people I spoke to like you know they they look at oh is the Contra audited you know like are there any like has it experienced any hacks sorry is it before like do they have any backers that's how they try to verify whether decide whether they should put their money inside or not but has it actually occur to you that you know the smart contract audit might not be the same code as they deployed you know like also like you know like um the scope of audit can actually be tailored you know the project site can choose what kind of code to audit so if you see an example here you know kagi Finance like actually in the um smart contract audit report it pointed out that oh does um the the the project site only asked us to verify this part of this scope of like the the the audit sorry this this part of the code and not to look at other like codes where there's obviously like a a back door or Ruck pool contract inside but then I it still managed to pull off like a 2.1 million R hack so it's kind of like people are actually like uh they just like you know lot not lot of people draw into this report and things you know and so these kind of like things keep happening so yeah smart contract audits are actually not for like our as users to use as reference it's more for like the project side to kind of get a cloud and yeah and another thing about like dyr is like the complexity of like d you know like they are a lot of like different hack types of hacks you know like you see a report here from slow Miss like if you distribute all these caes or incident causes and then you can see like repo uh contract uh vulnerability account compromise flash attack price mation there's a lot of different types of attack and maybe like not um maybe like all the developers they know how to what what these are and maybe they can look at like whether um the the risk are inside the smart contract or like maybe as a project in general but most of the retail users they might not be able to know how to mitigate this kind of risk and there are not like really any solutions or any uh other accessible tools for users to use to to actually for them to uh protect themselves and this is like what we wanted to do some uh tools for users to um protect themselves from from these hacks so I'm going to introduce like how lazy a works we have a layered defense approach to security it's kind of like how uh open saplings like um incen responses different layers we Iden identify like the the risk po R by by doing a risk rating on the projects and then we monitor the risk uh onchain offchain activities we verify like it through other like tools we have I'm going to explain more about this later in uh in the case studies and going we're going to decide a response to like Emery drawal or front run that those hacks if we have detected it so the main difference here is that um this is like we we act as a risk layer for users to interact with the project instead of having the user to actually embed like something in the code so if you look at it Di here it's an illustration of like if previously if user can choose to like direct uh directly interact with projects by making deposit directly to the projects but now if we have this uh layer here risk layer if they deposit to these um projects through our layer the funds will be protected in a sense that we're going to keep helping them monitor all those transactions on uh on chain and off chain wise and then if we find out or anything that is um attack is going to this project then we we can help them to emergency withdraw the funds back to this risk layer and note that this layer is actually doesn't keep any custody of like the users assets like all the funds goes directly 100% to the project the only time that the money is going to be in this layer is when there's an emergency withdrawal like some we think uh there's a we find that there's a hack going on to these projects and then it will withdraw the money back into the pool okay now let's look at like how we do this risk rating framework so how you going to identify risk you break it into three categories like technical economic and operation so in technical we're not looking at like the codes itself because that's a job of the smart contract but um at smart contract audits but like what we do is we try to break into look at other things like oh whether like like I mentioned earlier if the codes that they audited is the same as the one they deployed and then if not is are there any back doors we're going to um look at like the deployer address is it associated with any U pre exit histories um you know like economics wise we're going to see like oh what kind what is the tokenomics the collateral mechanism if it's a lending protocol what's an amm like formula uh what's the like Oracle they use and operation wise like the team background and any legal re this kind of things so basically these are things that you know like if a user if they want to find out like they spend a lot of time doing their own research they might be able to find it but you know like I said like not everyone has a time or like they want to do so and then next next up we're going to detect and monitor the risk for them so this is like the framework of like our monitoring it divides into onchain transactions and offchain activities so onchain we monitor everything that we can see on a blockchain and offchain wise like there are some data like show shows like or like other news you know like the project teams like the the show shows what what what do they say or anything like these kind of things we can also Monitor and this um framework is devel uh derived from like um the risk rating that we have made we we identify what kind of risk then we we can use this kind of like um uh framework to monitor those risk and at the same time like uh we also reveal like 341 hack incidents in the previous uh in the previous years and try to come up with the framework that it works but we also tailor it to different projects of course so and then like we respond to a risk once we identify any threats so if you see like um the whole flow is oh we're going to have some like threat intelligence where we going to monitor different we're going to get monitor onchain transactions and then off wise we're going to verify or if we receive this kind of like threat um notice we're going to verify it through offchain we're going to look at like oh um is it is it real or blah blah blah and you got use some security testing tools scanner contracts you know or or transaction simulations and then yeah and then also scan for like malicious address and everything and then we're going to respond I'll show like the example in the case study later so some of you might wonder like why does this like emergency withdrawal thing will work and actually like in most of the hacks there are actually it's in different like phases like there's normally in four distinct phases of hack from like funding uh preparation testing to exploitation until the money laundering so normal hacker like they would just like uh fund from like maybe tornado cash first and then they're going to prepare and test the contract and see if it works first before committing into like the attack and then exploitation where the real thing happens yeah see a data up there you can see like 70% of the hacks are actually in multiple transactions like I said test first and then attack and 50% of the time like the attack time frame is actually more than an hour but 98% of the time people only find out when the attack is over this is where like you see it on like the social medias on Twitter everything saying the heck has been happened but we think that actually by monitoring all these oning transaction staying alert to it like there actually three golden windows that we can take action before the whole hack completes and this is what we want to do like before like the whole hack completes we can at least save part of the funds you know uh this is a a a kind of like diagram that is shared by like Peter at the def5 security Summit and some of the famous hack you know rer Finance are like I don't know how you pronounce it but you know multichain like wow like poly Network here and like you see all these time frames like from hack until the whole hack is complete actually there even enough times that for us to respond to it but if we don't like but if we don't have any monitor turn to if we're not staying alert to it then you know we only find out after it's completed so yeah um next up I'm going to look into like how our layer approach would deal with all these security incidents like the ones I mentioned earlier repol contract vulnerability like account compromise fashional attack and price insulation so first up for um code vulnerability we're going to look at like like I said like oh for risk rating we're going to see if the audit coverage um the audit version is the same as the deployed version and then like other results you know like if they has State any we're do into the report and see if there's any risk findings you know but then the team choose to mitigate you know like or we can look for like have they done anything like the reention attack mitigations check effects interactions these or like if they use like the uh re-entrance guard Lobby from open zpp these are to avoid those re-entrance attack their amm formul um if it's it's a DEX see if they have verify with like form of verication and then if all is good you know it doesn't mean that it won't change because like we we still have to monitor because like maybe at one point they will upgrade their contracts you know we'll see an example later so we still have to monitor on any contract change if so we're going to see oh if there's a new contract is this contract is it save the coverage you know the results and then has it been smart contract audited and if if not we're going to scan with those security tools like Slither and see if it's like uh any back doors in it and then we're going to of course monitor the reentrance attacks and then for R PS we can look at things like oh the team background uh who are the founders like is a team transparent if if we can find like the founders are public and think like what what are their previous uh uh uh experience or project experience you know we can see if they're clean out and then for deploy address this is very important like you know like when they deploy their smart contract the project as it associated with previous excess scams or anything I'll see an example later and yeah that me is a multi sake or not you know like if it's multi you know like one person can just like rle the whole thing you know and then are these all multi wallets legit you know are they associated with any hacker activities previously and then for audit coverage you're going to see like yeah uh it's a a version like same as a deploy version is there any sketchy thing inside yeah and then like the earlier example you know like we're going to monitor it by seeing Oh if there's any uh new contract upgrades are there any back doors you know and then any parameter changes because some of the hacks are like they kind of change the parameter like the change of article provider and then do a price manipulation attack so these are all kind of things that we can keep monitoring and account compromise um is a I mean wallet multi sake you know and then so so even if one of the uh accounts are actually like um compromised like there are still other wallets that can protect them and then it's a time lock you know like time lock is like when when even if like the account compromised they upgrade a contract it still takes time for them for that contract to kick in you know and then monitor any AD me changes you know like if and then contract equates these are things where you can detect on chain and then lastly for like the economic risk going to U include it into like um price manipulation and Flash attacks and then easy for like price manipulation we'll see what kind of Oracle they use like do they use chain link or not you know or what or other oracles because if it's other oracles we'll see like how how how kind of how how do they provide those priz data is it easy for them to manipulate those priz and then for Flash loan we're going to see if they have like something called like slipage tolerance mechanism and yeah and then uh ongoing for monitor you can look at like the if they have if they suddenly change Oracle provider then it might be a Oracle risk you know like the liity dep you know like this is like sent to which prices can be manipulated and we can monitor for fast own and everything on chain as well so I'm going to uh at the end towards the end I'm going to go into like two case studies one is called magnet Finance the second is called Shido Network and see how it works so magnet Finance is like a project that is in uh the project side was involved in previous exit scams and the funny thing is like sa xbt actually called out this um this project and said like oh this deployer address is directly linked to some previous exit scams but you know like an hour later like I don't think people react quickly enough to it so like an hour later um uh they Rock pulled and 6.4 million uh million USD and then yeah so it's a very and then like the team even got back to Zach saying like oh let's do a 5050 split so it was a very funny thing you can look it up but then the point I'm trying to make is like sometimes like um the deploy uh for these like rock pull hacks we can avoid it by looking at the deployer address maybe like it already has some like previous exist Gams and yeah and in our case like it wouldn't even pass our risk rating because we already identify this deployer address has like some malicious like activities in the previous years and then the second one is Shido Network and this case is a bit different is that um they the ADM ownership was transferred and then they upgraded contract with the hidden like back door in it and then they withdraw the money so in our framework like how it would work is like when the moment they change this atmin we would already detect it onchain to find threat intelligence and then we're going to go offchain and look oh whether they have made announcement uh regarding this um smart contract sorry this uh admin change this I mean and you know the Discord at Twitter or government proposals have they have they announced this you know and then we're going to at the same time scan the these new ad address is safe or not and then we'll decide the response and then at the second time like when they did this smart contract upgrade the hidden back door in it like we would already detect a contract upgrade and we can scan offchain wise using the AI to see like if they made announcement on this like um change in upgrade in smart contract and then we can see if this new contract is like audited like the coverage and everything the scope of audit and then we can also scan this new contract if there's any back doors yeah with our security testing tools and then we decide a response and normally like in the first two stage we already find out something suspicious and we draw it back to the layer already and finally you know like at the third one like when the money is withdraw when when uh hack already take took place and happened you know like we can detect asset drain there's much not much we can do at this point already like we can trace a transaction but we can also like use a postmortem analysis to kind of generate the PC to find out what is the root CA of this hack and see if there's any um other projects that can be affected with this hack as well and kind of uh see how we can mitigate it if there's other projects that can have this kind of risk so yeah that's the two case studies and that's it for me thank you everyone if you want to connect then here's my Telegram and if you want to check out more about us then feel free to scan our code here thank you so much Marco and now we have five minutes Q&A time does anybody have question for Mar so uh so when you say you can emergency withdraw funds for users but I I'm wondering what's the mechanism behind because um it seems like the user need to approve like approve you to spend his or her LP tokens or or precise some some some um data to to do that and also um I guess the Emer emergenc withdraw is based on front running right but but when when the hacker not Broadcasting uh hacking transaction into a public memory pool or done everything in the Constructor something like that how can you deal with that okay thank you for a question and wait I'm trying to go back to the slides but right okay um the first question was like they have to approve something so um basically how works is like we act as a risk layer so um they deploy to our layer first the money and then when we withdraw the money it will be back to the layer instead of directly to the uh users's wallet address and but this layer is secur in the way that first of all we audited it and the only person who can actually withdraw from this layer is if you have the tokens the deposit tokens so if the user when they made the deposit they have this like um token to withdraw from this layer only any other people they can withdraw from this token so you're right about it like we don't we directly withdraw the money back to the user's wallet but then we go back to the layer instead so this layer is another smart contract you mean sorry this layer means a another smart contract yes it's a smart contract so so they need to trust you in advance yes okay do we have more question for Marco if you have any further questions please feel free to approach Marco