How to steal $1M from a DeFi Smart Contract - Bartosz Barwikowski

are you in are you hackers or in cyber security no okay yeah you are perfect perfect sorry okay get it get it so you know I'm going to speak about dream of every hacker about finding a b which allowed me to steal $1.1 million in 15 minutes uh in a smart contract of course I didn't steal them but it was possible so I will detailing story about this but let me tell a little about me I work for haken it's a cyber SEC security company from Ukraine uh I'm mostly doing layer one protocol Audits and I found during the last year last two years around 70 critical issues and this presentation will be about one of them but before we go to the issue and what happened let me tell you how it started so the story starts very very early year ago I had a very interesting audit of project called radic radic is a l protocol probably You Don't Know It uh they asked me for an audit I did a three months audit for them was able to find eight critical issues and then uh they went with another audit uh where they got 10 out of 10 score uh the all audits of the radic are public so you know if you search for radics engine audit haken you will find them so we can read them and the important thing about radic is that actually I like the the solution their platform uh you know their main goal uh was to make blockchain for VII which is user friendly so I like the concept I started using it uh I checked the wallet I was checking the ecosystem and was creating some tools for them a year later in April 2024 uh I found very interesting uh decentralized application running in their ecosystem it was called weft Finance it was a very simple lending platform where you can borrow and land three assets nothing uh nothing hard to code but let me tell you why it was interesting so it was very interesting because they were they were offering 82% returns when you landed them found when you added liquidity this is a huge amount 82% you know if I see value like this it's either high risk or scam to me because you know normally anything above 20% is is by default that it would be amazing offer if it's not a scam or if it's not a high risk so fortunately I do audits I have some experience so I decided to check out is it legit offer or is it a scam because if it's legit I'm going to invest out of money in this okay so fortunately they had their source code available on a GitHub so I started to checking it the code was huge few thousand lines of code you know it I had to spend few hours just to understand what's going on how they work I was wondering you know they a pretty complex Logic for a lending platform where you can only lend and borrow free assets so in the end I decided to verify if all the assets they have on the platforms all the loans and collateral is it is it real or not because they can easily claim something else on the website while while in the on the blockchain is something else so I decided to write a program for that uh which will just you know check every loan they have in the platform and if it's correct or not so when it comes to checking the loan we have both healthy and unhealthy loan so in the loan you have collateral this collateral needs to be discounted because you cannot like use $10 to borrow borrow $10 because it's too risky so usually when you put uh $100 you can borrow other coins for $50 and all you need to have is that your Deb the amount you borrowed must be always less than this collateral if it's too high like you have this depth to Collateral ratio above 100% then your loan is unhealthy and it needs to be liquidated so basically the platform is taking your collateral and repaying DEP by using this collateral so I was basically checking if all the loans are healthy and there's enough collateral to pay for every every loan in the system so as I said I create this program I checked all the loans uh I simulated it on the copy of um of myet database basically clone the database and was running my program against against it I verified everything and it was okay when it comes to all the loans all the depbt and all the collateral the platform was legit of course there were other cases which I had to consider like what will happen if the price changes a lot but you know they had very very high margin uh of safety because they were discounting this collateral by 30 to 50% even more so the risk was low so my assumption was that the platform is legit and this offer with 80% APR return is okay and I was ready to to invest uh in the platform but during check when I was checking the source code I noticed something very interesting uh their project was very complex as I said you know it was a simple Landing platform but the code page was huge 2,000 lines of the code and just like 20 tests very complex logic so I was almost sure at this point there are going to be some issues especially that I didn't see any audit of their platform so I started to dig deeper and I was searching for some potential issue and I quickly notice that the most dangerous part of the smart contract is a liquidation process because it works like a flash loan okay so when someone has an unhealthy loan and the platform needs to take his money to pay uh pay for his debt it has very complex logic because it works like this first you get the collateral from the loan in and in the same transaction you need to repay the depbt of the user so it works like a flash loan uh where you get the money in the same transaction up front but later you need to repay them this is usually very complex thing to code it's very easy to make mistake with that so I was almost sure at this point there's going to be some problem with that okay let me show you on a diagram how it work so we have a loan which is unhealthy there's too much depth so the platform needs to take the user user money and repay the debt so it starts uh by getting $52 from the user in this case then uh the platform can then um then the user who's taking uh the SC Terror can do anything with this $52 but later in the same transaction it needs to repay uh repay the depth of the user so yeah the idea is that you can take at this in token X you can swap it to token on some exchange and repay the dep very a logic where it's very easy to to make a mistake so I started to looking for a potential issue issues with that okay and I notice one more very interesting thing which wasn't available on a website but uh they had this logic in a smart contract which was a delegated loans so basically you can have um a single collateral for which you can use to have multiple loans so for example you put uh $100 U as a collateral and by using it you can have three different loans yeah and the idea is that you can just have uh that you can have like subusers or uh your friends to whom you can borrow um who can borrow from you stuff like that but of course if uh depth of all the smaller loans is higher than uh than the collateral then you start the platform needs to liquidate um the delegator and when I was checking how the delegate is created it work like this first you create a normal loan the loan is represented by NFD basically you want to take a loan you get an nft all the data is stored in an nft so when you wanted to create nft which allowed you to um to use the collateral um of the delegator so basically uh take a loan by using U the other loan assets I know I know it's a pretty hard but later we uh I will show you on the diagrams they were checking um for the following thing um the requirement was that this um nft which you wanted to conver to this different type of nft um has to be crash so in this case uh it wasn't allowed to have any collateral and by that they it also didn't um allow to have any loan so they were basically validating uh if the if this NF is fresh or not but there was Ed Case uh in this creation as I said uh they were only checking for existing collateral but they didn't check if there's any depth in this loan which they're trying to convert to link with a delegator and that's something that could be abused so what would what should happen when you have a delegator and delegate and you want to add um another delegate who already has a de in this case it's this delegate to uh uh on the right side yeah it's also right side for you okay so in general when the new delegate is added and he already has a Deb then the value of De to Collateral and depth for the delegator should be increased so we started with $10 depth we added $20 depth uh from delegate 2 so we end up up with $30 of collateral so this is how it should work however it's not how it worked in the practice there was an issue with that where when when I was uh trying to link um a delegate who already had a Deb this $20 then um this value wouldn't be added to a delegator so we would end up with uh still $10 and 20% depth to Collateral uh for a delegator so that's an issue uh but it's not a critical issue at this point actually we cannot abuse that because it doesn't allow us to do anything okay we were able to link uh this new delegate with adep to delegator but but it doesn't allow us to basically do anything at this point it doesn't allow us to take the more dep because delegate to already had a dep so it's not a critical issue but fortunately or unfortunately there will be ways to abuse it by using other issues okay but the question is is it even possible to create a Lo with no collateral because how how would you do it um so if you take a $50 loans you need to have $100 of collateral so it's close to impossible to actually create uh such loan where you only have a depth and no collateral I mean the price would need to change by a lot of the price of the token would need to change by like 100% which is actually impossible and to be honest the Assumption was right that technically it was not possible to create a loan with only debt and no collateral however here comes the complicated logic with the flash loan yeah so when uh when the loan uh was about to be liquidated because there was uh more depth than discounted collateral as I said it first started by removing the user poater so in the first stage we take uh this uh in this case 52 collateral from the loan so we ended with the smaller discounted collateral and then we we repay it later so there is actually a way to lower this uh collateral amount without changing a dep but as you can see in this diagram we are only able to to take small portion of this it's not like we can take um all collateral from the loan because we cannot take more than the depth is and the depth is usually two times lower than the collateral so is a good starting point but what we want is get the collateral to zero which we cannot do with this approach however there will be another issue which will allow us to do it yeah okay in the liquidation process there's another bug which I quickly notice and The Bu allowed to start liquidation of the same loan multiple times so this is how it's how it looked like um when the loan was unhealthy we started the liquidation then we're able to start liquidation of the same same loan second time taking all the collateral which is left normally it shouldn't be allowed because it's like taking flash loan inside the flash loan uh so so it's like re-entry back but in this case um they were thinking that's okay because uh even even if um I start this liquidation twice the transaction will will fail because fair I will take this $100 collateral but then when when I will be trying to repay a depbt which is $100 by the system then uh the transaction we fade because the loan had only $52 of Dept and I was trying to repay $100 of dep which doesn't exist so so they were thinking or maybe not that such scenario even if possible cannot be abused because they were right it's by only using this it was not possible to abuse it but what we managed to achieve is having coll collateral equal zero zero so if we can create a transaction which uh is starting to this liquidation twice we can add this point convert this loan with only dep and no collateral to loan which is linked to another collateral which is became which is just becoming a delegate I really wonder that's uh that you know the connection uh when it comes to diagr s work differently uh when I present when I'm making a presentation right it's changing uh how it works is it because the resolution okay never mind okay so here's how we could um abuse this double liquidation with uh linking it to delegate first we have a loan which is unhealthy we start uh double liquidation of the loan so we take all the collateral there's only loan with a de then we can link this loan to a delegator because as I said this linking is only checking that collateral is uh is empty which shouldn't be possible to have such loan but in this case it's possible then we can link this uh loan and later after linking we need to repay this $100 uh of depth uh because otherwise transaction will will fail and in this case it would even if we tried something like this the transaction would still fail because we didn't repay this Deb I mean we tried to repay more we tried to repay more when we had to yeah amazing graphs okay but you know it's easy to follow you know it's go right to right to right next time I will just use images okay so there's a way to make it work so we we start with the same uh liquidation so first we start the liquidation twice uh we lower collateral to zero then we link this loan to a delegator and then we take another $50 of loan for the same uh delegate so now uh we can take the loan because when we link this uh this loan with no collateral to delegator delegator could have more uh collateral like let's say $500 so uh it allows us to take uh new loans for this delegate number one which we just created so the idea is that we create take $50 of uh of more depth and now when we try to repay $100 uh which we need to repay uh from this double liquidation we can actually do it so we managed to create a transaction which actually worked and allowed us to link a loan which has no collateral but only dep to to a delegator yeah pretty complex scenario but uh we manage to do it and actually what does it accomplish we'll see in a second uh where the issue is with that yeah some some quick summary uh of the process starting double liquidation linking to the legator taking more depth and then repaying uh all the depth so everything uh sums to zero okay and the thing is here's the uh here's the summary of the delegator what is happening during the during the process first when we start let's say we start with an example delegator this delegator have $400 collateral 200 discounted collateral and at this point it has 100 depth so it's using like 50% depth to Collateral when we link uh when we start the liquidation and we link a new loan this one with $50 depth um it's being it's linked to a delegator but the sum of the depth and depth to the collateral is not updated it stays like this uh then when when we take 50 more dollars of the dep theator is updated because um taking more cler work correctly we end up with uh 75% depth to Collateral ratio and in the last step where actually the issue is when we repay right now this $100 of a de then all $100 is removed from the sum of the depth of a delegator so at this point we are able to remove that $50 of the Deb from the delegation lowering the depth to Collateral value but as you can see uh the real depth which was at the beginning $100 is still existing because we didn't repay any depth of the delegate delegate one so we manage to actually lower the Deb by $50 and this is where exploit is by repeating the same scenario we can abuse it many many and many times and always lower this uh depth of the delegator I know it's a pretty complex probably you know hard to understand but later I will be posting more detailed article on on hacken website so you know this story is interesting and you want to know it in details it will be available okay so I had the idea and I started to code exploit which wasn't so simple okay so I spent like 30 hours it was you know the beginning of the May so everyone has having uh was having a vacations at least in for I don't know how it works in other countries and I was spending that time uh to C the exploit it was it took much longer than expected I had to spend like 30 hours and called 1,000 lines uh 1,000 lines yeah because I ended up with doing a lot of transactions I had to do like 1,000 transactions to to to execute the exploit when I finished coding it I run it of course I was running it against copy of the main net which I had locally the exploit was running around 15 minutes that's why the presentation title is how to Ste $1 million in 15 minutes it was doing like four transactions per second sometimes it had to wait for like 10 seconds um to to let the platform update its data so it was running and running of course we are not going to wait 15 minutes for it to finish we'll just skip to the final results of the exploit and it was able to extract everything from the platform yeah after running this 15 minutes so it took 15 minutes to extract take everything from from the platform with that exploit with 1,000 transactions and $1.1 million in total okay so what happened next when I only noticed that uh there's this issue first thing I did I contacted the the platform on the telegram and I asked them about the back bany yeah classic approach uh and they were fine with this we negotiated a a an agreement what we're going to do if I find an issue and I can prove it and at this point I start started to coding the exploit it took me two days uh to finish everything when I had it ready uh I contacted them again I said that hey I found a critical issue and I have a proof I send the code uh and tell him tell them how to run it locally so they can verify everything they did in a few hours they uh confirmed that I'm right and they were quite impressed with how how by abusing the small issues I managed to create a critical issue and was able to steal everything from them they fulfilled uh the their side of the agreement they fixed all the bugs which I shared with them and after all the bugs uh were fixed I invested $1,500 on their platform because they were offering 80% returns so it was still a pretty good deal all I had to do is the fix the issues and yeah it was actually amazing deal I made $2,000 on that during the last three months because it was in May okay but what would happen in worst case scenario so let's say someone else found the issue and decided to steal everything so $1.1 million would be stolen the we the company the small startup which was hiring seven people will go bankrupt and they would had a lot of they would have a lot of troubles uh their token which was worth around $2 million uh when it comes total market cap would drop to zero probably the radic it would be the first hack in radic DT ecosystem so it would also affect them uh a lot and I expect that they to their token would also go down by a lot especially that the most of the assets were in their token so the hacker would need to swap it to some stable coin if he wanted to steal it so the total damages would be huge but fortun did it happen it didn't happen Okay so for the end of presentation how to prevent such issues first thing don't keep features in a smart contract which we are not using yeah I mean they had this delegation process which they were not even using uh but was still available for me to abuse this was this was very surprising to have such complex logic not and not even using them another thing is keep your smart contracts as simple as possible if you have some complex feature like flash loan and you don't have much experience with that then just don't doubt it because it's so risky and potential gains are very very low so it's not worth to add such complexity for this few per extra gain have a lot of tests that's for sure this is the first thing uh which tells me about the project quality so if I see a huge complex projects and 20 test test then I'm sure that there will be some issues so you know if you ever go for AIT always has test have test because that's the most important thing have an audit yeah I mean if they did an audit even even with different comp from Factor probably with most of the companies uh someone would be able to notice this those issue pretty quickly because they were very easy to spot I've seen them after just few hours of just check the C and the last thing which I recommend is having a back Bounty back Bounty plot program which are pretty popular for web free there are many payouts for more than $1 million when it comes to back bounties and there are many interesting platforms to have it listed on and there's also important thing for the new ecosystem so the radics which you probably don't know uh was a new blockchain it was a new ecosystem the uh just launched a platform last year and the problem um is that even if your platform your technology and everything is amazing the people the clients which are using it they can make mistakes and it's not your fault that they are making a mistakes but if on your platform your clients will be hacked for $1 million then it will also affect you so it's also very important to monitor what's going on in your ecos system and somehow cooperate with these projects to make sure they go go for the audits or in the worst case have some back Bounty program for entire ecosystem so a hacker finds a project in your ecosystem and he can hack some other project in the worst case it should go to you to the owner of the ecosystem of the blockchain platform because paying a back Bounty for him will be still much better than letting this other project get hacked or something like that because the damage for the entire C system will be huge okay that's it for today so I'll be later posting the whole story on the blog with more details where you can uh read it and try to understand it um in more details so if you want to see it uh then follow me on Twitter or check a hen site I will be posting the story within a few days and if you have any questions or you are interested in the topic feel free to catch me and let's talk about it I can explain everything after the presentation in detail thank you