Sec it up: What's brewing in the security tooling space? | Neville Grech, DEDAUB | ETHTaipei 2023

to present his talk hello I'm Neville from ddub I am a security expert working for DW I'm actually a co-founder my background is in program analysis and theoretical computer science and I'm going to be presenting um something about the tooling space that we currently are experiencing but also the tools that we're developing internally at ddub so tdub is mostly known as a smart contract security Auditor in the space these are some of the clients that we work with however ddub does more than just security audits we also have developed two link some of it is free and has been around for a long time actually so contract library is a blockchain Explorer which is designed for security researchers and also developers that want to reverse engineer smart contracts that are opaque so no source code or debug transactions on chain and Watchdog is a security solution which does both transaction monitoring and also deep static program analysis which uses formal verification techniques within it as well so our mission of ddub is to solve security problems for the web tree space and this is a really big problem there's been billions of dollars hacked from web3 projects just over the last month there's been all of these hacks you know Euler has been hacked for 200 million dollars for instance and even though we do a lot of security Audits and that brings in revenue for us I believe that security audits are not obviously they're not perfect right they are on the security side you know we don't find all the vulnerabilities in contracts code um in fact it is actually impossible to find all possible vulnerabilities but on the operational side they are also very human intensive meaning that they are both expensive and it also takes a long time to schedule these and the other thing is that vulnerabilities don't wait for audits you if you deploy or make changes to your protocol and there are small changes you don't think you might need to reorder the protocol but then you know the security landscape or the security structure of your protocol might change but not only that the underlying protocols on top of which you build might change and also there might be new attack vectors that emerge and that were not known to the Auditors back then and so really the solution to all of this is to adopt all security practices there's a lot of obvious stuff over here you know security audits is one of them but also I believe development processes right so writing very simple elegant well-tested code this is easier said than done sometimes you need to sacrifice a few features in your protocol good operational security bug bounties but also lately especially with our products there's tooling as well so there's transaction monitoring and also continuous code verification which kind of does you know the job of the security auditor but on a on a large scale and actually these two things the development processes and the tooling are probably the highest Roi of these I've also been asked lately because we've seen a recent phenomenon as well sometimes hacked funds have been recovered this is uncommon of course there is Tooling in the space for this you know chain analysis does excellent tools for um you know like law enforcement to use but why does this actually happen it is due to bad operational Security on the part of the hacker and so they've been identified and why is that I mean they might have used a centralized exchange or you know used public front ends without cloaking their IP address but I believe that hackers will you know they will learn from these mistakes and you know some future hackers will not make the same so in the security tooling landscape um I've kind of like categorized the tooling that I've seen for Webster protocols and this is based on my own experience you know internally but also looking at the market and also listening to what uh what our clients actually need so anyway there's transaction monitoring and the transaction marketing you get alerted when there are some transactions that are executed on the chain there's a few tools already there Watchdog fortnite tenderly an extreme version of this is Front Runners and Front Runners actually are you know they're very fast they can operate you know in a few seconds and they're able to you know detect these things before the next block arrives then there's men in the middle approaches where there's transactions have to go through a third party before being executed or get canceled exposed back though and also there's finally there's code analysis and tier improving this is probably the most interesting class of tools out there because these perform deep semantic analysis of the code base which is technically impossible but you know we're getting there um for for many kinds of vulnerabilities we can actually find these using program analysis techniques however we don't believe in a few things so Front Runners and also men in the middle approaches we don't believe that these are actually going to solve your security problems so for one hand you are assuming with a front run that the attacker will submit their transaction to a mempool and that then you can simulate this transaction and before this actually gets mined you can you know go in and pause the protocol you know send transactions directly to the miner via flashbots however in reality this doesn't work first of all it's only supported on ethereum because the you know the time between blocks is large enough to do so but even even on ethereum itself like the attacker might actually not use the mempool you know they they could simply use flashbots you know I for instance when I use you know uniswap I also go through flashbots personally for my personal transactions not to be front-run by by Mev Bots the other thing is that even if all of this is not the case since the space is decentralized there might be yet another front runner in this space that is there to be making money and if you know if an attack transaction is submitted the other front runner which is malicious might actually you know get there before the tool that you have and actually it is alleged that the Euler attack the first transaction might have been frontrun okay now men in the middle Solutions I've looked at you know a couple of these tools here's an example of these so the idea is that if you write if you have a protocol it uses utilizes you know erc20 tokens you can wrap them in another token and apart from implementing things like balance off and transfer you also Implement function to to freeze the funds okay so then if you know a user hacks your protocol you know you can quickly like freeze the user's funds of course there's multiple problems with this the protocol is no longer decentralized the ux and the complexity issues increase but also can the attacker simply like if if these tokens have any value they can potentially be transferred translated into you know ether or something which cannot be blocked so this this is a problem as well so really with a data we focused on kind of like both extremes the proactive approach which is code analysis and tier improving approach and also the fully reactive approach which is transaction monitoring okay starting wrong with being reactive running proactive because it's not possible to find you know every single bug automatically proactively so you gotta use different approaches all right so in Watchdog the reactive approach is transaction monitoring so you can write monitoring agents using macro infused SQL it's a SQL language that operates directly on streaming streaming blockchain data okay I'll show you an example when I give a demo and then there's the proactive approach which does deep code analysis so this uses program analysis techniques we model all possible executions with a lot of caveats of the smart contract to find vulnerabilities and some of these executions will be executions that were very interesting to us as security people but then we also utilize tier improving techniques we've written our own tier improver in order to significantly reduce the false positive rate so I'm not coming here to show you a tool which which does not work and say for instance that's you know had it been used on some other protocols would have saved funds was that actually already has prevented a number of hacks specifically on the proactive part the code analysis it has you know figured out we figured out how to use these analysis to find real vulnerabilities on real protocols and with that came you know a number of bug bounties so for instance from Harvest primitive Finance precursor to photo combo D5 saver and a few others multi-chain so 10 large bug bounties over the last couple of years we've used Watchdog to find all of these vulnerabilities of course there's a lot of extra work that needed to be put in to create a proof of concept and all of that and to interpret the results so these are not by all means they're not very easy tools to use Okay so I'm not gonna switch over and actually give you a demo so okay so this is the reactive approach of Watchdog so this does transaction monitoring and we've taken a unique approach to implement this so the idea is that when a transaction gets mined on the blockchain we can actually see all the executions all the evm stack traces that that been produced there and we actually turn those into a relational approach we turn those into actually database tables however the thing about this kind of data is that it's streaming data so by the time you are finished there's going to be new data that appears on the blockchain that you also need to process so rather than a batch processing approach that you use in something like Analytics tool the streaming approach would work slightly differently say for instance I want to create I want to find out whenever someone um withdrawals funds from tornado cash as an example right and I want to build up a list of people that are withdrawing from tornado cash and I want this list to always be current so you know in real time this is how you would write as such a query and the idea is that the the decoding of the arguments that are passed when tornado cache is called actually happens in real time so you don't actually need to contact us and tell us can you add tornado caches one of the monitoring things you just write it as SQL queries that automatically decode all the data involving through transaction as you can see it's five lines of code to get a list of tornado cash recipients that is updated in real time this is a real-time table now let's say I want to build up on this um say I wanna say all right so we've got a list of tornado cash recipients now I want to build up and see um contracts smart contracts that have been deployed by these people okay I want to get these smart contracts and also build up a list of that that is updated in real time as well and potentially I might want to get an alert whenever a um you know a new smart contract is deployed in that but you would get a lot of alerts so this is not an interesting thing to do we gotta you know build up on this a little more Okay so this is actually how to write it finally here we've built a query which takes you know these smart contracts that have been deployed by users of tornado cache and we see whether they actually can reference our own protocol because they've either deployed either in the deployment code of the protocol they've have the one of the addresses hard-coded of our smart contracts or they've used it in one of the Constructor arguments and potentially we can also see whether they've used one of our initialization arguments so once you do all of this you get you know the ability to create alerts and to be reactive to events like this on chain okay there's a few other example I can show you like say for instance you want to see whether a multi-sig owner changes you know this is a this is the query to write okay and again and since every protocol is different you will need to have a general approach to transaction monitoring okay on the proactive side so on the vulnerability analysis the Deep vulnerability analysis what we have is an approach which actually takes the smart contract code which is deployed on chain or which is uploaded to the system by um some other integration and starting from the byte code okay we extract high level information starting with disassembly our own internal representation and finally the decompiled version contains the same structure almost the same structure as you would get in the original source um but this is a normalized structure which we then can apply the security analysis to and the security analysis are actually what find vulnerabilities you know days and weeks in advance because they analyze the smart contract code almost as if you have a real law that they're doing that so we've got an analysis for re-entrancy but also like many other things that are novel like for instance you check certain assertions in one function but you are not doing the same thing in another function which achieves you know the same effect and that's kind of like a catch-all vulnerability analysis that you get there so moving back to my slides okay so the re's a few other practical considerations um that happen in the transaction monitoring say for instance you are constructing things intermediate representations of um lists of addresses and things like that in order to query them efficiently and be able to be extremely fast in your reactivity so that you are able to you know have a very you know short lag like a few seconds and be able to react we've constructed within the monitoring system the ability to materialize intermediate results and index them um and there's you know various materialization approaches okay so interesting thing that people always ask is well how can you determine all possible executions of a smart contract well in theory it is an impossible task to to actually do it generally however this is one of those hard problems that a lot of computer scientists have been working on over the years and if you want to learn more about you know static program analysis and the techniques that we have invented for for Watchdog and some of its components there's you know some literature in in the academic journals um that we've developed over the years um but I'm gonna give a nutshell in a nutshell how these kind of techniques work so we start off with the smart contract which is a computer program and we turned the smart contract into nir we do it via decompilation we turned into an intermediate representation which is more amenable to analysis which kind of looks like this over here and in this representation everything is normalized you don't get complex Expressions you know Loops are you know very easy to reason about and then we turn that intermediate representation into a logic based representation and this logic based representation is you can think of it as a database which is specifically designed only to do program analysis it's a special database it's uh it's got um you know it's in memory it constructs a very efficient queer plans when you've got highly recursive queries that you need to be doing if you're trying to do program analysis and understanding of the program and it needs to be extremely fast because you know we need to model almost all possible executions of the program okay so it's almost like a database but um you know for very complex recursion in the queries in fact in you know in in our product you would find internally you would find like thousands and thousands of queries that reference each other in a mutually recursive way so and then um we also use tier improving and we've actually written our own tier improver in order to improve the false positive rate of the analysis so a static program analysis what can actually kill such an analysis make it not useful is if it comes up with a lot of false positives because there's so many things that a program can do that you cannot reason about very precisely you end up you know in some in some analysis tools flagging a lot of the lines of code for many spurious vulnerabilities that cannot happen in practice however with the steer improving approach we only keep you know executions and behaviors that are you know proved to happen under some circumstances of course there's there's also caveats in here but the idea is that using this this tier improving techniques uh we can model things like you know the program is swapping its own funds on an amm rather than the user's funds and this should not be triggered by an untrusted user except in some other circumstances and things like that we can model all of these basic properties another example you know a programmed Computing interest rates via oracles should check that the price is in stale right and so you have to check in the smart contract code that there are these checks and that these checks actually refer to the price and and things like that and you know all of this is Con you know fully automatic right you don't need to uh you know actually do this yourself there's also catch-all um things like you know there's multiple ways the user can change important storage variables then all of these ways should check similar properties before they proceed okay so what are the results of such an approach um specifically I hear I'm referring to the proactive security code analysis so we've discovered a vulnerability which if it had been executed would have led to the draining of a billion dollars worth of wealth and this wasn't a protocol called multi-chain okay we call this um Discovery Phantom functions it's a novel kind of like mechanism here so look at this code so this is code from multi-chain in the multi-chain there's a smart contract where you can deposit funds in two different ways so on the top way on the top you deposit funds by first approving the smart contract and then the deposit calls transfer from and that does a safe transfer from which pulls your funds into the smart contracts there's nothing wrong with that approach by itself however there's a second approach deposit with permit which utilizes permit and for those who don't know how permit works you basically sign something on on metamask before you actually call the smart contracts and you provide that signature as part of the call and what permit does is it checks that the signature is valid using ecdsa encryption cryptography okay so once that if this is valid this is not gonna throw an error and then the transfer from will proceed okay now try to think try to think how is permit implemented on rapt either on wet okay possibly the largest token this is it so why this is it permit does not actually return anything so permit as a function it returns void so the return data is of the function or for those who understand the evm internals is actually going to be empty so this actually obeys the ABI of permit so when you call permit you know the code will be called you know the function will succeed so now if I get and we call these kinds of functions Phantom functions okay so these kind of functions that were not specifically implemented but you know the the fallback observes the same API they're fandom functions so now let me get back to the code that I was showing you um in the first function here most people were actually using this function right so they were approving they were doing an infinite approve and then that meant that the smart contract had thousands of infinite approvals right and then over here you could actually exploit this the positive permit over here by supplying Rapides as one of the tokens and obviously that that was a very popular token so that would have led to over a billion dollars worth of of currency that would have been stolen luckily that didn't happen but still not not everyone revoked their approval so there were you know a couple million in Lost funds so in summary there is no Silver Bullet to Smart contract security however there are a few approaches that we believe in you know including code analysis audits bug bounties and monitoring um to learn more about you know to get some security Alpha follow us on Twitter thank you [Music] since fourways great talk um anyone has questions thanks for the presentation I'm really curious about the Watchdog you presented uh so it looks like a query system that could carry all the information um real in real time on chain uh using a SQL like language um I'm curious about the how how do you collect all the information on train and store it so well in this way that can be query so easily and how how fast is the response times and also other transactions in the memory pool also will be inserted into these database in real time okay sure so there's three questions the first question is how do we do it so basically we have our own re-implement not re-implement this we have our own Forks of existing nodes and these Forks of existing nodes they actually perform ETL into a database uh so I went through new transactions some new blocks our mined we take those transactions they are executed and then um you know we take the evm frame and we we put everything into a database so that's a standard ETL process you know etherscan does something like that as well internally second question is was the delay so the delay between the block getting aligned and that information actually going into the database is around a couple of seconds one or two seconds right so there's that delay to account form because the ETL process is you know quite a little bit complex the third question is whether we could do the same using the manpool transactions so transactions appear on the mempool we could you know just take the transaction from the man pool and apply the same process that we don't do actually yeah but it's theoretically possible for your static analysis tool where you had the specialized database for and this is the question how how do I suggest um to implement permits or to use permit to oh yeah that's which you need to watch just give up sure um yeah I'm not that familiar with with the differences between permit and permit 2 actually so yeah sorry okay all right so since again for the last uh great presentation [Applause] and the first half of the afternoon session is over so please take a break for 30 minutes and come back to the ticket track thank you