The Unseen Threat: Why Attackers See What Developers Miss | Bartosz Barwikowski - Hacken

Transcript

[Music] hey everyone today I will be speaking about the Unseen threat why attackers see what developer Miss I'm going to speaking for my own experience because I work in cyber security for quite a lot yep and of course yeah it works so yeah I started hacking 15 years ago it started very early you know I was the first kid to get banned during the high school during the it class when I tried to hack the other people uh with Koger so it started very early also I joined uh web Tre in

2013 when you know the Bitcoin was was was still growing up now I remember I had 200 Bitcoins back then it still hurts so yeah for the last three years I work for haken is the cyber security company I found around 70 critical issues and I also found a lot of issues in back Bounty programs so yeah the hacken itself is the cyber security company web Tre cyber security company we do almost everything AIT pant tasting proof of reserves we work with the big clients I even managed to find an issue for binance but let's let's finish on that and let's think how hackers think to be

honest I'm only telling from my own experience but I think it all starts with curiosity just a simple question how the things work what will happen if I change something can I somehow bypass the Restriction you know the same story when I was kid I was the one who was disassembling the toys to see how they work the cloaks or some other stuff because it was more interesting than than the to itself to create something better from it was more interesting than just the toy itself and I really love that so you know I would like to show you how I think when I start working with the

projects when I start the audit when I do some back Bounty I will show you 10 places my top 10 and general patterns where I search for the issues it's mostly from my own experience I don't know if everybody other hackers work the same but good luck with making a general R ranking so this is my private one okay let's start with number 10 it's the code ported from another platforms or languages yeah so in many cases when we have a project for example in solidity and the team is starting to moving it to Solana or sui Aptos they try to copy everything they have because the product

is already audited and uh it works it works so far so let's just copy it but it's not so simple because there is a lot of platform specific behavior so if they have developers who don't have really an experience with other platform they just want to Port it because they think it's easy it's a very big trap and a lot of companies fall for it recently I was working on such project and they were porting from from rust to move to movement and you know it should be almost the same but they made two critical mistakes in their project yeah so they made an issue with filtering data at the bottom is the

example so in the OR original code it was Oracle project in the original code they were parsing data for every Oracle every feed they had and it worked and it worked correctly it was taking the time stamp of the first uh package and then it was verifying that time stamp for all other feeds packages is the same but when they ported this code to movement they decided to do an optimization and they added option to filter data to receive only data for given feed from the same signate data and of course they made made a mistake because later when they verified this data they verified

only filter data so all the other data which was in the package for the other feds was not validated at all but later in the same code part of this unverified data was used to calculate the time stamp it allowed to move time stamp into the future for an oracle pretty big issue the other very interesting issue I had uh was when code was ported from 64bit platform to 32bit platform so you know right now almost all the code runs in 64 bits but there's very rare case which is web assembly which uses usually 32 bits and by doing that they assume

that nothing can go wrong but it did because the change that the size of U size changed for from four from eight to four bytes and it introduce overflow and it was possible to manipulate the signature verification okay next category nine code using algorithms I really love algorith algorithms algorithms because uh before starting my cyber security career I work a lot with optimizations uh games algorithms so I have a lot of experience in this so I always check how the developers use the algorithms even

the simple one like sorting like fighting median median or some mathematical calculation do they they know about the complexity or not are they handling edge cases correctly because uh the interesting fact is that actually there's a lot of developers who don't really have experience with algorithms or the only thing they have like maybe sometimes they don't even know what's the difference between stable and unstable sorting but if they don't know that don't don't know that they can introduce some issues in the projects and I will show you one issue like this this one is very very very stupid but I got 50k back Bounty for it so uh it should be interesting and the

issue was that one project it was layer one project used base 58 instead of Base 64 to encode the data when you know emitted events for example or some logs Etc they were using base 58 and you know there's not much difference there's only four characters difference when it comes to base 58 and coding but there's one hidden problem which costed them 50k and it's complexity base 58 has n squ complexity so the thing is if you start feeding it with a lot of data the computations will take a lot of time minutes sometimes even hours and base 64

don't have this problem so yeah simple mistake and someone was would and and a potential attacker would be able to take down the entire network just by sending a huge transactions with base 58 so yeah a stupid mistake but it happens I was interested if AI would be able to find out this mistake because right now we're having a lot of uh tools AI based to se for mistakes I asked CH gpt1 Pro yeah I subscribe uh if it's safe to use base 58 it said it is safe okay so I asked it okay in this structure which they had in their

project it was used for emitting events and serialization of data is it still safe it said Yes again so I asked it even more directly what are the risk involved with base 58 and it didn't know so for me that's a good thing it means I can still keep my job for maybe few years okay next thing number eight code on which multiple developers work together this is hard to show in a practical example and it would be a little unfair but the thing is when I'm checking the code sometimes the difference between code quality is very visible I can see that there's one

experienced developer the lead who's taking who create amazing code but he has like two others who make mistakes and sometimes just by following the other developers those who make mistakes it's very possible to find the issue because yeah because focusing on the weakest point is the best idea and sometimes the developer can be this weak weakest Point okay next thing recently updated code especially old code so let's say we have some big project it has a lot of Legacy code and and they want to introduce a new feature and to do that they need to change something in the old code and the problem is when they do that sometimes

this old code changes Behavior or some other code which was used for something else like in many cases the updates like this are being done in rush and it's from my experience it's quite usual to make mistake especially when changing something in Old code so have a lot of tests okay next thing code integrating with third party components okay the problem with this is that usually the developers don't assume how to handle the situation if something goes wrong so okay what what should what should we do if Oracle starts to

returning wrong data or if it has some danial of service and don't work correctly there are or even or even worse what if this third party will want to somehow abuse our own smart contract uh from my experience like 60% of project don't assume such thing they just you know integrate with third party and they count that everything will work correctly so this is the place I always uh I always check especially that's out of project have small mistakes low sity issues not dangerous at all but sometimes the low severity issues can lead to high or critical severity issues

in other projects okay number five complex code with L of tests so sometimes when we have very ambitious project like using zero knowledge proof or like doing Perpetual decentralized exchange Landing Market you have a lot of complex operation a lot of math and and when I see one thing there's one special thing when I see that the code is not tested then it's a huge red flag it means that almost for sure there's going to be something wrong with this because if the if developer cannot even test its own

code then it says a lot about the project so I always check those places so yeah and the next thing with very complex logic is that sometimes if even if you achieve 100% test coverage there are still some edge cases which okay maybe in total everything is covered but individual in individual cases it's still very very easy to to miss something yeah I found for I have an example of such issue two years ago I found a critical issue in binance zero knowledge proof of reserves they were using pretty complex uh solution to calculate the assets they were link they were dividing

it into the batches linking with with each other and I found an issue which allowed to fake this their proof when they were linking one batch with another so yeah I won't be going into the details if you want you will find it uh in the internet uh the whole story so yeah search for binance Z proof of Reserve uh haken and you will find the whole details about the story okay next thing number four dangerous places in the code so there are some dangerous thing like cryptography Randomness oracles serialization I love serialization and the thing is that

people think that those functions packages are easy but they are not they're not easy at all they require very specialistic knowledge to use them correctly so yeah uh when I only see someone trying to use those thing or even worse some trying to some change them somehow or customize it then it's another red flag because uh yeah the complexity behind it is is really huge I have some example for example with Randomness this is when I you know I didn't find this issue but when I read about this Jesus it was it was amazing so imagine that we have a blockchain game rolling a dice

and it has some Randomness let's say Tex is from chain or it has some built-in Randomness and you send the money and based on this Randomness result you win or lose money and the idea was that when you lose money the smart contract will use more gas so yeah and there was a very small difference between winning and losing a money like few percent uh difference in a gas and someone managed to abuse it just by setting maximum limit maximum gas cost of the transaction yeah so every transaction he was sending if it wasn't winning it was reverted because

there was not enough gas but when he was winning the transaction was successful so yeah crazy crazy Edge case s go for a cryptographic function for example hashing like okay we want to create some hashing function which will just generate something unique address for some input data and if we don't do it correctly we may end up in situation where different datas will result in the same hash like in this example it all depends uh how we enter the length uh of given given field because combining some things together we can use them to generate an issues so yeah and if

everything but it the thing is it will work everything would work perfectly test will work correctly but uh if a hacker sees this then he will know how to abuse it yeah number three multi-step operations multitrans actions okay this is another very complex case because it generates a lot of edge cases so if you have you to do like three operations to make a transaction or I don't know lend some money from Landing market then pay off your depth then there is a lot of opportunity to introd to find some issues because everything can happen between two transactions the state of

the smart contract can be changed uh liquidity can be changed prices of the token can be changed and in many cases uh not all edge cases are considered and the same thing like with the complex code if there's no test for it if I don't see test of such scenarios that's a huge red flag as I say uh if you cannot test something you shouldn't be writing it and it's get even worse if you add flash loan and I found uh one very interesting issue with this it was on Landing platform by doing very complex transaction I was able to create exploit which would be able to steal $1.1 million so yeah this was my biggest issue I found when it comes to number of

money imagine this being able to steal $1 million of course I didn't do it I you know explained the whole issue how by doing this eight steps by doing some crazy stuff in the transaction like starting liquidation twice and creating one more loan doing the liquidation you can steal the money money get an advantage over the landing pool and of course they fix the issue pay some Bounty the whole story is also publicly available I was speaking about this during the Defcon few months ago you can search for Landing platform hen exploit and you will find it okay next thing number two re Reinventing the wheel

coding something that shouldn't be coded sometimes the developers are very ambitious they want to do everything by themselves so if they start working on things like Custom serialization Custom cryptography custom peer-to-peer something which is already you know very available then it's a very very high chance that they going to make some mistake with this those things are extremely hard to code there are hundreds of such cases and in every situation I've seen that a project is building something themselves because they have a better idea or something like this it always end up with a mess seriously so it's a very big red flag

when projects try to do everything themselves yeah there were there were some cases but I'm going to skip it because I have last minute so last thing number one the most my most favorite economic attacks those are are perfect because sometimes even Auditors cannot detect them yeah because for many developers and Auditors not all of them of course they don't understand economics between uh economics of a given project for example Landing Market where they make money where they lose them what are the risk and if they don't understand it it can be easily abused let's give you an example let's say we

have a landing platform we can borrow usdc we can borrow ethereum and we can use some mem coins to add collateral but those m co mem coins meme coins have very low Market uh liquidity pool in this case by buying those mem coms for $20,000 we can raise the price to $1 and use it at as collateral would would be worth $1 million borrow $200,000 and steal the money yeah those are the perfect attacks yeah last thing and I'm finishing and the most important thing is to combine it all

together okay so yeah if you combine everything together then you get the best results thank you [Applause] a moon walk across gas feet Graves my main Net's Smo than your M's VN