Real-time Whitehat Hacks / Arthur Gervais

Transcript

foreign [Music] yeah sorry I I should have gone to the green room but uh yeah missed that so thank you for your for your understanding um today we're gonna discuss Whitehead hacks um so who lost money in HEX really nobody so who made money in HEX I was to nobody okay okay this is a surprise but um so in in general like we don't really have a clear definition of what a hack is at least not a formal

definition right um so I kind of like would like to put it in the bucket of Mev for now right so we have this minor extractable value that most of you I guess are familiar with it's this concept where well you do have a blockchain state right a different liquidity pools different amounts that can be traded uh different bonding curves and you can extract value from that one possible Mev source is arbitrage right liquidation sandwich attacks all these sources are really Mev and attacks are somewhat in between their maybe also Arbitrage and they may also

be partly liquidations right um so we don't really have any formal definition right so I really take this with a grain of salt when it when I speak about attacks don't take it too formally um because we don't really know so far um okay so how many of these attacks are actually happening out there in the real world um we did look into the last four years of D5 and we found about 181 D5 attacks so these are not all the attacks so this is not an exhaustive study but we we've tried to be as let's say scientific as possible so we try to categorize attacks in this uh so-called sok paper systemization of knowledge

paper we have big tables there and and a lot of analyzers I I won't bore you with the details today we're just going to discuss about a few key points that are interesting but I I do invite you to to check out the paper if you if you want to look deeper the total amount of losses are about 3.24 billion US dollars so that's not a small amount um and the practitioners Community has equally published numbers that are quite helpful um so here for example I'm citing D5 Lama which has a great interface and they're also trying to categorize attacks in in similar time frames but again we don't really know what an

attack is right so typically when some people are losing money and they're crying about losing money and somebody is winning money then sometimes this is labeled as an attack but again we do not have any formal definition of what an attack really is so how does an attack actually look like right so what is the kind of the the architecture of an attack so to speak right so I'm just going to depict one example it's a bit more ancient example it's actually one of the very first flash loan attacks maybe you've heard about it B6 was attacked twice actually in the beginning of 2020 and this is actually one one example of how an attack looks like I

don't really want to go too deep into the into the details here but we can if you want um if you have any questions here but on a high level right the attacker is taking a flash Loan in in point number one he's doing some exchanges then a lending position and then he's paying back the flash loan right so that's on on a very high level what this attack does so the attacker in this particular attack had to spend about 120 US dollars in transaction fees and he got out 634 000 roughly do you think he took all the money he could have taken he didn't right so we we tried to analyze this attack back then and here's

also the link to the paper uh he could have gotten 1.1 million if he would have executed the attack with the optimal parameters so please if you do execute an attack at least optimize your parameters right don't leave don't leave money on the table for the back Runners right it's just no point so this is just the the uh like like how an attack looks like how the architecture of an attack looks like in this particular example of a flash loan and many many similar attacks nowadays that are flesh loan based are really similar in in the overall architecture right so but now you may Wonder well there are these flash ports and peer-to-peer and Front Runners so how are these attack attacks actually

executed nowadays right um back back in the day there was no flashbots actually um so everything went over the peer-to-peer network but how does the supply chain so to speak look like today right how is an attack executed nowadays in if you look at the x-axis here we have the time um and if you have an attacker if he's submitting a transaction to the network you can see here and that this transaction txa may be visible to everyone right so that's not a private transaction if an attacker goes over the public P2P Network um that's a that's a publicly visible attack um and and this is still happening today uh

by the way we have uh I think just two or three days ago there was one attack that went over the the public UTP Network um can recall the name right now but um roughly 50 percent of the attackers nowadays go over over um so-called private relayers okay but here in this particular example right if we see an attack on the peer-to-peer Network what could happen well an arbitrageur or a front-runner could detect this transaction and then perform two things either a back running bundle so bundling the attack and back running the transaction with an Arbitrage or

um the front runner could try to replace the attack with its own attack and diverting the revenue towards its own address instead of giving it to the original attacker this is also something called generalized front running or imitation attacks if you if you want to look this up and what's interesting here is why do we why do we have here this part where these transaction may also be sent over the public feed-to-peer layer anybody an idea why we would do that why would wouldn't we just go over private relayers much safer no it's not public

any idea why we would even if we're using private relayers such as flashbots block x route Etc why would we still try to want to go over the public P2P Network anyhow it's because of the market share of the relayer so roughly 90 percent are using this proposal Builder separation artists PBS so 10 of the miners are still or validators are still vanilla so to speak uh validators right so if you want to increase our odds of actually making it into the next block we should still go on to the public P2P

Network right um okay cool um so we've looked into these 181 attacks that I mentioned at the beginning and we found that 81 are effectively executed over the flashbots API that accounts for roughly 600 million US dollars so it's it's not a small amount but some of these attacks I I may note uh here for example so obey Finance uh actually um and this was rather a whitehead hack so the the project at the time found the buck and then executed them themselves and they went over flashbots in order to prevent these generalized Front Runners right so they use the private

infrastructure so to speak as a as a yeah to secure their rescue operation if you will um so but what's funny is we found that six out of these 18 were effectively accelerated Barbie trash Traders so the attacker or I mean we don't have any ground truth right so whatever whatever I'm presenting today is based on my evidence but maybe maybe that's wrong right so I don't have the ground truth the attacker didn't tell me that yes they did that so um but based on our evidence we found that six out of these 18 accelerated attacks were bundled by by an Arbitrage but and background um over for example a flashbots relay

so they got kind of helped they got got help from from the Arbitrage Trader and here again this brings us back to the initial attack if you perform an attack not only you should optimize your parameters but please also do Arbitrage behind right why leave money on the table right um okay so um another interesting Insight that we found from the study is that the like 56 of the attacks are not executed atomically so even if you use a flash loan the attack itself may not be Atomic because maybe you first deploy an attacker contract that I could detect right minutes before

you do execute the attack so and there's this life cycle where we have initially we have a contract deployment then at after some time typically minutes sometimes days even there is the first attack transaction and then there may be many attack transactions until the last attack transaction so just to give you an example the Euler Finance like I'm sure you heard it right roughly 200 million lost Luckily everything went back recently the first attacker transaction of the Euler hack only took about nine million dollars and I think the second transaction hit after 10 minutes or so 10 minutes is an awful long time right why didn't we exit the liquidity pools right just doesn't

make any sense like why did we watch what happens and what what unfolded in front of our eyes right um I mean we should have we should have had um automated intrusion detection and prevention systems here right in place that ultimately automatically remove liquidity from this boot okay and I mentioned to you well we can observe when the attacker is deploying a contract but you may say well it's hard to understand what the contract is doing without having a transaction that executes one of the functions and so on yeah sure I understand but what we can do is we can learn from past attacks by conducting a similarity analysis right between past attacker

contracts and past vulnerable contracts as well and then try to somewhat see whether there's some similarity and then ring the bells we did a very simple study I'm sure you can't come up with much more fancy and and probably more accurate schemes but we we took we took the byte code of of these for example victim contracts as well as adversary contracts we chop them into engrams We performed we created some embeddings and then tried to see how similar they are right and at least according to our naive analyzes here we do see that quite a few of these adversary contracts and victim contracts are very similar right

so again what are we doing right why are we not looking at the data and trying to correlate it to past events and we can really improve security by quite a bit all right so I want to dive into two case studies the first one is a bit more elaborate the second a bit quicker and we will start with actually uh so to so to speak a cross chain attack maybe you've heard about the elastic swab attack in December 13th of last year it happened on Avalanche and on ethereum elastic swap had a vulnerable contract a similar contract deployed on Two Chains and it got first attacked on Avalanche right so here this

this red logo is Avalanche this here is ethereum and we have four transactions the green check mark indicates that the transaction executed successfully the red check mark indicates that the transaction failed so in the what we saw first here is transaction zero that we have a function name called go I labeled this as an attacker I don't know whether it's the original attacker but I assume based on the evidence that I have that this is the original attacker and we have found in three transactions on ethereum here so why do you think that transaction one failed

based on the evidence provided here will sort of Robin um so the attacker was successful on Avalanche right and he was apparently the only one right there was only one entity so to speak right so he he had success there right and you're right that on like on ethereum there was a bit different setting

uh it's not about the configuration but rather competition so we have here on on ethereum we have the what we labeled as the original attacker then we have a the white attacker labeled as white attacker again we don't have ground truth but that's what we believe there is and the attacker here execute or try to execute apparently a similar function similar to the attack that he previously did on Avalanche maybe this indication helps you yeah I guess that the white hacker used

the fastball like the other relayer on the public and absolutely so transaction two here was front running transaction one because it went over it went over relayer it went over a private relay in this particular example and due to the fact that transaction 2 was mined before transaction one which I understand may not be visible in this in this representation but but um but from from an on-chain perspective transaction 2 is effectively front running transaction one therefore transaction one can no longer execute with the parameters that it wanted to right because probably it touched some

liquidity pools that were empty then um but then why why do we have this third transaction uh this fourth transaction here transaction four this goes back to the previous slides where we discussed why should we go over both networks the relay networks and the public peer Networks do you remember so this transaction here went over the P2P Network and this transaction went over relayer so it seems like we have an adversary here who's playing two games right he's going once over the public peer-to-peer Network and once

over relayer Network okay um I want to emphasize that this time difference here is quite important what we found is that the attacker and the white attacker they only appeared within 250 milliseconds right so what we conclude from this is that we have a we have a whitehead hacker who is bilingual so he can both speak peer-to-peer Network and private relayer right he's apparently doing some generalized front running because 250 milliseconds is rather quick right that's automated for sure it's still not high frequency trading fast maybe but it's quick um and he's quite good at bribing too so out of the 523 ether that were

vulnerable in this particular attack he paid 15 percent as a bribe it's not little right and then he took a 10 Bounty and he paid back the rest that's why we label him white attacker right uh don't ask me where this 10 comes from it's somewhat a decentralized agreement among among white attackers and victims apparently at the moment yeah okay what about the second incident so the second incident was uh the saddle case in April 30th last year a saddle is similar to kerf It's A and A packed coin amm and so here the an

attacker took money and then later a bit later the block SEC team were able to secure another 3.8 million dollars and if you look on chain this is what we can see now I have a question for you why why can the white hat in this case extract another 3.8 million although the attacker already took 9.2 million what what the hell happened here again yeah I said before some Arbitrage which was not collected very good point so the the

attacker probably didn't take the Arbitrage that it could have taken but in this particular case it was actually the parameters again from the attack that were not chosen optimally right so again the attacker here just left money on the table and by tweaking the parameters we we investigated this this attack actually there were like two or three parameters that you needed to tweak to to get the remaining 3.8 million and due to the 24 minute time difference this was apparently not executed Atomic like like automatically through uh through some program but through very quick manual inspection and reaction like like really fast for humans all right cool

thank you so much for attention [Applause] thank you so much uh there's still some time so if people in the audience have any questions uh now is the right time so we have there um sometimes like test hacks on chain before doing a big hack what what could be the reason I mean the attacker could could do this locally in the local Fork to test the heck why why hackers do like test tags on chain right um uh it's beyond my understanding I'm not sure why like you can so easily

um connect to an archive okay I mean maybe they don't have access to an archive node but even that that would be uh weird so to speak right um I mean there's no reason why uh why not to connect an archive node uh fetch a later State and see how much profit you can extract or even as an attacker right you you can over time you can estimate okay should I hit today or maybe tomorrow is the all-time high or right I mean like you don't know how much liquidity there will be tomorrow in the in the pools right so I I'm not sure to understand and why that why not they're not optimizing attacks and why they're not uh executing them atomically yeah I mean I I don't want to give tips to to hackers but but we need to

understand what what we can do to prevent the attacks and that's why we need to understand whether they default too right um it's a cat in Mouse game at the end of the day at least uh when when doing these kinds of Whitehead hacks any more questions oh there's one uh can you sorry sorry can you wait for the microphone hi so you mentioned we need to prevent the tax what can we do to prevent the tax thank you that very very relevant question so security is an in then in um in-depth uh uh I mean defense and death approach really right so the more layers

you have the more likely is that you will defend your assets and that means an audit is the first layer but it's only the first right and that's not the only it shouldn't be only the only layer so in default in particular I believe it's crucial to have real-time defense mechanisms so for example you can have a monitoring system where if there's a certain amount of liquidity being extracted from a pool that you're invested in right then you should have an automated process to take that money out right or if you see an incoming transaction on the network layer you need to have some kind of intrusion detection system that classifies how abnormal is that transaction

right and then you may want to pause trigger an emergency pause of the D5 protocol if you can right so 50 of the D5 protocols we looked at are having um emergency pause mechanisms they are often unfortunately very centralized um but according to our data they triggered on average in six hours only the pause after an attack so there's literally seemingly no automation so far um and I think if we just have more more layers more more defense layers really and we don't just like naively Stand By and attack being executed over hours we should be much

better off in D5 and and secure the space good a very cool presentation and uh based on your data which D5 Protocols are being attacked most often and which users like a normal Traders LPS arbitragers and so the we have a table actually in the paper where we categorize which D5 protocol type is being attacked the most often in terms of frequency as well as in in value lost I think in both dimensions bridges are the most brittle so both in terms of uh I know actually the yield farming I

think has the most hits but the same lost value as Bridges while Bridges have roughly half of the number of hits in terms of attacks um as as as yield farming protocols yeah roughly speaking these are the worst yeah so I think we have time for one or two more questions if there are any oh there is one um do you think that all the math attacks are bad because you might also think about them like I mean they are like a Robin Hood they are uh like a robbing the Ridge and giving back to the poor especially if

the rewards are distributed through liquid stacking to others right I'll try to not judge whether an attack is good or bad I'm sorry um like it's it's like asking is a sandwich attack good or bad right is it okay to take money away from Sandwich attackers or not I'm not sure um so I'll refrain from judging but it's it's true that's a good question that everybody should ask themselves um and yeah it's not clear uh it's it's it's I think it's very subjective so to speak as a as a question yeah so how would you judge the security of T5 as compared to traditional Finance

then we I'm not an expert in traditional Finance so I wouldn't want to um uh to to pretend I am there so but I I see the space being very amateurish still uh with respect to to real-time security really right um because audits I mean I think the community has has gotten really good at doing audits um but through the experience that we've seen through the empirical data that we've seen it should be very clear that's not that can't be everything right um and it doesn't make sense that the bridge for example is allowed or a user is allowed to take out all the money of a bridge in one single transaction right why not have like some kind of a circuit breaker there so they're very simple

means to to improve overall D5 security through these different layers so so circuit breakers uh real-time intrusion detection systems um pause real time pause activations if your protocol already has it why not um and so on right so there's I feel it's still very amateurish at the moment yeah well thank you so much again thank you