Future of Threat Prevention by Andrew Beal - We can detect exploits, but how do we stop them?

Florida Foundation has anybody heard of Florida no okay well good um you'll learn a little bit about it today um we are the steward of the Florida Network Florida Network's a decentralized network that sits on top of the seven largest evm chains and we monitor on-chain activity for exploits suspicious activity anomalies and other things we've been live for about a year were used by a lot of major defy protocols exchanges custodians and end users [Music] um and the networks emitting millions of alerts a day at this point uh the title of my talks the future of threat prevention in web 3 we spend a lot of time thinking about how to not only detect exploits but also stop them once we detect them and so we're going to talk a little bit about that uh today so here's the three things we're going to cover first how Florida detects on chain exploits I'll kind of walk you through the anatomy of a of an exploit um talk about how we detect things before they actually happen before a loss occurs once we detect it and the question becomes can you prevent it the short answer today is it's really difficult for protocol teams and bridges to stop an attack even if we tell them about it in advance but we think there are a number of Alternatives that uh we'll start to see more out there in the ecosystem over the next year or two okay so how does Florida detect on-chain exploits so most exploits map to these four stages in web 2 you would call this the kill chain we don't use that term because it's confusing when you're talking about things in the context of a blockchain but um uh anyway most smart contract exploits Bridge attacks defy exploits we'll go through these four stages so funding preparation exploitation and then money laundering funding usually looks like this I'm an I'm an attacker I have funds already but I don't want my attack to be linked to my wallet I use every day so I'm going to obfuscate the source of my funds through tornado cash in advance so you'll see money laundering through tornado cash or some of the Privacy preserving protocol up front um once they've done that they'll use those funds to then deploy and fund a new smart contract on chain this is the an attacker contract this is the preparation stage this is setting up an attack and then moving to exploitation then they'll invoke that contract and uh steal funds and then they'll do money laundering post exploit as well so the vast majority of hacks that exist you can kind of map to this uh these these four stages here so how does Florida detect things so we're looking for activity across these four stages we're actually looking at more specifically we're looking at for patterns of activity across these four stages so I just kind of walked through a really basic uh process an attacker will go through tornado cash funding new contract deployment invoking and then money laundering after the fact so we have uh hundreds of bots that are running on the network that are were built by us built by other developers that are looking for um individual signals in each of those stages so there's a bot running on Florida that just looks at tornado cash withdrawal activity there's another bot that just looks at new contract deployments um there's another bot that does nothing but analyze op codes in new contracts that are deployed there's another bot that simulates every contract that gets deployed across the the seven chains that we that we support and they're constantly firing alerts and we're looking for signals or we're looking for patterns in those underlying alerts so the goal is to detect and exploit in the preparation stage prior to a loss happening so and you'll see some some of the signals that were that were watching uh in those first two stages are listed there below I know the font's a little small now the challenge is that once you the farther you go to the right on this on these stages the higher confidence you are that it's actually an attack the challenge is that you have less time to actually prevent it as well right so it's a balance so The Sweet Spot is the preparation stage that's where you can get relatively high confidence alerts um and you still have a chance to to either prevent something or or mitigate it so some learnings from year one at at forta um most exploits are not Atomic I think that's a misconception we actually can detect some exploits before a loss occurs so these are the two good things in green unfortunately even with advanced warning most protocols cannot prevent an attack and that is because the only threat prevention mechanism teams have currently is a pause mechanism and pause buttons are unfortunately far too slow to react if you have let's say five minutes to respond to an alert that's that's that's that's that's uh not enough time for most teams to sort of execute their kind of multi-sig sounding process and pause a protocol right and this is not surprising because pause buttons were not created to uh you know stop an imminent exploit right uh they were they were really meant to one decentralized control and then respond to sort of code vulnerabilities where you had a little bit more time to to address it so if pause buttons are too slow what other Alternatives uh are are out there what else should teams be thinking about with respect to prevention mechanisms so I'm going to run through a couple of that uh we think are really interesting so first one is asset segregation D5 protocols and bridges are effectively giant hot wallets um it's one of the reasons why you see hacks in such large dollar amounts in this ecosystem because funds are pooled together um so the question becomes can we segregate defy Assets in a way that still preserves the user experience but like maybe minimizes the attack surface a little bit better um and I think we can draw some inspiration here from how crypto exchanges manage their their their custody right um most centralized exchanges keep the vast majority of their Assets in cold storage and just a minimal amount in hot wallets right to satisfy daily withdrawals but everything else is offline um so there might be some inspiration we can draw there another thought is that um you know we can impose uh withdrawal limits on protocols and bridges right let's so let's say a bridge that has a billion dollars in tvl you might only be able to withdraw 25 in any 24-hour period right so with something like that you automatically kind of minimize your your risk by 75 percent um and 99 of people that are using that bridge aren't probably not going to be impacted by that because very few people are moving um large amounts of money um the last bullet here is interesting because there actually is a bridge team working on this today and there'll probably be some more information published shortly about that so I'm really excited about kind of asset segregation and and withdrawal limits with respect to bridges in particular okay um before I get to the next one um I Heard a great analogy recently about a pause mechanism and sort of the inefficiency around it and the comment was from uh the CTO in a large audit firm and he said pause buttons are effectively the equivalent of like shutting down a bank anytime the bank gets a suspicious transaction right or a bad check is written and when you think about it that way you know the it it pause buttons are clearly uh kind of a a round Peg trying to fit into a square hole here um the solution's not really fit for for a purpose right um do we really want to shut down the bank every time there's a suspicious transaction probably not um so perhaps a better alternative is taking action not against the protocol itself right but taking action against like the the malicious actor the transaction now that you can detect it in advance right can we screen that transaction can we screen that transaction out um this is how C5 manages risk today right if you're a banker of fintech you don't you don't shut down your your business your exchange right you just you pause or slow down the malicious transaction or the high risk transaction until you can figure it out Um this can technically be implemented at the base layer you can implement it at the application layer there's a bunch of different variations of this um but imagine a protocol being able to say I want you to run all transactions with our protocol against these rules before they're processed and approved right [Music] um you can apply negative and positive reputation right so you can let good things through or you can slow bat things down um there are teams working on this today as well which I think is really interesting so transaction screening and asset segregation I think are two kind of exciting emerging uh threat prevention mechanisms that we'll see more of next one time delays and simulation so at forta we have talked about since the very beginning kind of the concept of a simulation Network where let's say there's uh a 10 million dollar kind of flash loan transaction right from a brand new wallet address I have I have no idea who that is there's no reputation associated with it and it's you can't you know discern the intent of that flash loan um at first glance so why don't we ask that person to sort of prove that that transaction is okay so simulate it on a separate Network first and run it on the current state and show us that there's no sort of malicious result right and then with that access station you can come back and you can run it on the main Network um so I think there's a lot of there's a lot of simulation networks are really interesting um technically standing something up like this is obviously requires a lot of effort um but um I expect to see something like this as as well okay front running this is probably one that uh some of you may be familiar with uh you can monitor are you historically you have been able to monitor the public mempool and um detect exploit transactions before they're processed pay a higher gas fee and front run those transactions uh block SEC is a team that's been successful with this in the past and this has been sort of you know a an approach that white hat hackers have used to save funds however the proliferation of flashbots and other private men pools l2s Etc um are giving teams like block SEC and other white hats less visibility into pending transactions and so we're not particularly excited about the kind of the future of front running I think it has diminishing returns over time and um as as visibility decreases I think this is just going to get harder and harder to do so we're not not putting our eggs in this basket automated circuit breakers so this is kind of like an automated version of a pause button um it's been talked about kind of agnosium after any large exploit um they work particularly well for stock exchanges [Music] it's also possible in defy to set up an automated trigger right but there are risks in in doing that so any team that I think is thinking about doing this needs to be very thoughtful about how they implement it one is you need to have a tolerance for false positives right so if you get an alert if that alert's not 100 accurate all the time then you may be positing your protocol uh when you when you didn't need to right so there's a trade-off between being able to act fast and being accurate second is that it's subject to manipulation from competitors and hackers so if you're pause button triggers or the conditions on which it will trigger our public and other people can see that it means Bad actors can also see that and you know manipulate it to their advantage um and DDOS your system and the impact from a pause can also be widespread stock exchanges are very kind of insulated right they can shut down without causing kind of a huge ripple effect um D5 protocols sort of but just you know because of composability and other Integrations you shut one thing down it it has a larger a larger ripple effect so you need to be very thoughtful about when and how you do that okay um something a concept that's come up recently is uh transaction reversibility so off chain reversibility exists today so this is a very manual process right but um you uh protocols will often negotiate with a hacker post exploit to try and get those funds back so I'll call that off-chain reversibility right um and maybe they'll pay a bounty to that to that hacker right but there have been several proposals put forth recently to actually add reversibility features in erc20 and 721 contracts um one proposal was from a research team at Stanford um I think the lossless team has also uh has has functionality like this as well so there's multiple teams that have thought about this and experimented with it um I think it's really interesting it's perhaps a nice complement to some of these other things we're talking about the challenge is that you know it assumes that a loss has still occurred right and you're sort of winding the clock back after the fact which is not a is not a it's an imperfect uh sort of solution and has its own complexities associated with it uh cyber Insurance you know this is not a prevention mechanism per se right but it's kind of a catch-all um net after the fact um I think interestingly um I'll just call out the last bullet there things like asset segregation and transaction screening and time locks and simulation will will lower the can can lower the risk profile of your protocol such that it's easier to get uh Insurance because for you to get insurance someone else has to be willing to take the risk right and right now the risk profile of uh protocols and bridges is extremely high so therefore the appetite to underwrite that risk is very low so we need to to balance that out um some some Alternatives here to or some uh some uh considerations here when you're thinking about these these seven uh Alternatives I I went through um and I'll leave you with this um any team bridge that is thinking about threat detection um thinking about you know improving their pause button and experimenting with some of these some of these other Alternatives needs to think about what's the cost to the user if we do something different that increase fees um is there additional friction does it by slowing transactions down some of you might have had this thought right if we're if we're screening things and slowing things down what's the impact to the user experience there is that something that you could tolerate is that something your user base will tolerate um there are likely impacts on both composability and complexity so those are things that need to be to be weighed decentralization another key key question who's responsible for making some of these decisions who's responsible for what's deemed high risk and what's not who's responsible for determining what's a potential exploit and what isn't right um risk of censorship one of the biggest I think uh you know conversations around threat prevention is how involved does this community in general want to be when it comes to sort of the transaction processing flow and identifying things early on and perhaps filtering them out right or even even sort of flagging them as good or bad right so there's a lot of there's a lot of conference conversations that that have been had and will continue to be had around that question um Effectiveness is obviously one of the big ones is it actually going to help can you prevent the attack um and then availability is the solution available today is this something that's going to be available in a couple months more near term or is it a long-term thing uh all these all these are helpful when you're evaluating uh these alternatives so that's it for me if anyone's interested in learning more about forta or um continuing the discussion around threat prevention in web 3 uh you can reach out to me on on Twitter or Telegram and I'll I'll be around here the rest of the week thank you [Applause]