Webinar | Decoding Blockchain Disasters with ULAM Labs and EBC

we're on probably SL can be moved yeah so could you move to the next slide yeah probably it's not full I'm not sure full screen or not yeah and next one okay yeah okay so yeah my name is Conrad I I the CEO of theam labs yeah and together with me is lukash our blockchain engineer and we will be talking about the uh about the security uh of the web free applications yeah and possible hacks yeah and how to prevent them yeah so today basically you can uh learn how to look at your uh decentralized app from the security point of view how to find and classify all potential attack surfaces and how to design your application uh to prevent or minimize those attacks yeah and the agenda yeah looks today plan looks like that yeah in the part one talking about the about the smart contract Security in part two I'll be talking about the about the infrastructure security and all uh like or on both parts here we'll be talking about the U we'll be talking and providing real life examples yeah uh with the explanations and the good practice how to avoid them yeah and I think we can start here yeah will be first one yeah so iting my thanks yeah hi again I'm Luke and by coming here today you made an excellent decision to save millions of dollars on your next the app project and with smart contract security it's always best to learn from others mistakes because they can be very costly I believe it's the first time since online payment processing where application code actually controls that amount of funds that we see in the smart contract world and the thing is smart contracts are up 24/7 no downtime the funds can be gone at any instant and well you'll learn why smart contract security has been all the r with Audits and how to protect it as best as you can so let's start off with a bit of a warm-up at the very beginning with Mount gox the big hack and well for those who don't know what happened well I hope a lot of you do but for the for the not so ogs the exchange got stolen had over 600,000 Bitcoin stolen and what's very interesting about this is that this didn't happen overnight and this attack didn't even take one week or one month these Bitcoins have been gone missing for over for a few years and only then someone has noticed so this has been and I believe it will be the biggest hack in terms of Bitcoin stolen like denominated in Bitcoin and here there's a little I want to introduce a little mathematical concept called the invariant and the cool thing about invariance mathematics is that it's something that nearly changes and when you think about the gox let me propose to you some simple simple invariant that would have totally AED this problem so here you can think that the the sum of all balances on the exchange should be equal to bitcoin Holdings and well this makes it much easier to test and audit your smart contract code if you think just a little bit differently and now what happened to mount gox well it's a long time ago but it's easy to imagine something like this happening inside a smart contract where just money goes missing over time and in fact it did happen with compound and someone only noticed this attack after $80 million worth of compound have been stolen from the smart contract and well in case of Mount GX it was just it could have been just a simple invariant implemented and checked and compound well the the hack also wasn't very difficult it was just like a single missed calculation next up we got reentrancy and the famous or should I say Infamous Dow hack well it was very controversial at the time not really because of the hack itself but because of the aftermath we all know ethereum ethereum classic that was the result of actually a smart contract bug and here what is what is reentrancy if you're not familiar with the term it basically means that you're able to call the same smart contract from within itself or within other smart contract so let me give you a simple example you're withdrawing money from a smart contract and then it gives you a call back so you can do your own bookkeeping however you're going to abuse this feature and you're going to call withdraw again before the smart contract was able to update its own State and therefore withdraw the same ethers again and again and again and just continue doing this and well in the older solidity version it was like pretty much impossible to see some of these edge cases now the the environments have evolved and a lot of new blockchains actually prevent re-entrancy at all and it's like for example Aptos or Cosmos all these blockchains don't even allow this sort of the thing to happen I believe reentrancy has been a the bane of all evm chains and this is especially big with uh flash loans where you can take all of the assets of a given smart contract and well nowadays we have ways of dealing with this but it is a serious serious risk if left unchecked another big hack actually starting a series of big hacks in 2022 a lot of these were on salana which was a pretty new environment to build in and well the thing you have to know about salana was that it is very very Bare Bones experience in program in you don't really get a lot of framework you don't really get a lot of safety assumptions like in Cosmos it is uh it is a much more baren environment to work with when you're developing smart contracts and because of these reasons is the one of the biggest hacks of 2022 actually the biggest hack happened and it was the The Wormhole exploit so what happened here was the the attacker was able to fake a signature from sorry a vaa from Wormhole and mint their own wrapped ether on salana and how this happened was that they they did not steal any private Keys no of course not uh it was really just a simple simple replacement of of a special account that goes with with a transaction to the blockchain and this this little issue has actually been patched in the official salana crate on crates IO four months before the exploit happened so well really if so this is actually shows that if you would compile the smart contract in with the new version of the library you would see that there's this major issue going on and well this shows how important it is to be up to dat with the new releases and updates in the community and the software that you're building with and while this the the attacks I'm showing here they were not that sophisticated either the the Wormhole exploit was really just an abuse of two lines of code so two lines were just wrong they should be fixed and this is really doesn't require you to do any crazy uh sophisticated multi-layer transactions but you can just find one small if inside the smart contract code that is faulty and this issue it was apparent in more than one smart contract that was exploited in 2022 on salana here we have other examples one of the one of the biggest ones was cashio and Grandma Finance um well with cash which was a decentralized stable coin there very similarly the attacker was able to replace the account going in with a transaction and Supply their own worthless coin and just mint as many stable coin this decentralized stable coin as they wanted now this this also wasn't that crazy of a hack because here really if you look at the at the code and Analysis of this situation is that well it was actually two if statements that could have been different which would have totally avoided this hack so really just like two lines of code out of maybe a thousand that were wrong and it resulted in pretty much all the tvl gone and similar thing happened with cremma Finance which is a concentrated liquidity amm but here you know when you have those little ticks and the concentrated liquidity market like Unis V3 if you're familiar with it the liquidity is placed in those little slots so and in salana and Crema Finance this tick was each stored in a different account so the attacker found out that you can actually Supply a different account and again there was one check missing to see if this account is valid and because of that again the the attacker managed to just take a lot of fees under fake tick and just go away with eight millions of dollars uh it's important to know that cashio and Crema Finance were not audited at the time of the hack and the last one here is tinyman which was a decentralized Exchange on algorand this time but a very similar situation happened so basically here um the smart contract allowed you to withdraw from a liquidity pool let's say you have usdc and Bitcoin and there was like a little Quirk inside the code which allowed you to withdraw when you're removing liquidity you're burning liquidity you could remove Bitcoin and Bitcoin so you you just say hey I want to withdraw one Bitcoin and 31,000 Bitcoin or whatever the price was at the time and this yeah right so three million bit dollars in assets got stolen and other $3 million doll were frozen forever and cannot be recovered anymore and it's important to note here that tinan was actually audited by one of the top auditing firms and they're are very reputable and it's still slipped through through the auditing process and well we wouldn't actually know if this issue was implemented after the changes were made after the first audit report because well they have been some critical issues in the tinyman exchange before the audit which have been fixed and we don't know if it was just missed in the review or it was introduced with the fixes so so here I want to actually propose an auditing strategy that avoids these issues and brings your chance that the smart contract is secure to the highest possible level first of all let's start at the very very beginning the smart contract audit uh auditing process starts with the the the quality of your code the review and testing now I couldn't stress this enough it sounds very intuitive but I've seen many many different times this actually not being the case and the goal of code review and testing is that you have a smart contract code which is actually where we have fought through all of the architectural changes and designs that you need for this this application to operate and now if you supply let's say you potentially take this smart contract which is not finished to an auditing company you're not going to get enough value because you're you're paying money for the smart contract uh for the smart contract audit and should the smart contract be in a poor shape or poorly designed you're just going to get back information about the all these issues and the important thing to know when you're going into the audit is that it's only valid for this specific code hash or a GitHub hash so only for one this one specific comment the the audit is valid so if you make any significant changes or any changes at all really the audit doesn't apply anymore so it's really really important to get this first part right so if you have just one developer working with the code the biggest value for money you can get if no one else can review the code is hiring a freelance auditor and this step is really the by far the cheapest way to find major or critical issues with your smart contract code I don't want to talk about this too much it can be done of course uh as the code is being finished I want to point out that this this approach with multi-step auditing process doesn't actually slow down the release because right after the freelance audit the freance auditor of course is going to work with you all the time it's not like you have to wait a specific amount of time for the report it's going to come the the bugs the bug reports are going to come as you work on the smart contract and the next step would be to work with a smaller auditing company especially a one that has a unique set of skills especially coming to the niche you're working with so for example if you're working with algorand you might want to hire a auditing company and leverage their it is inside this environment especially if it's a niche auditing company and now you do this smaller company audit because you're going to get much more flexibility uh in terms of times and pricing and this is very important that you have a one audit done and then the second one as we've seen with tiny man another audit probably would have saved this the smart contract and once once you have this first audit you can actually go into production so this process that isn't slower than the original one where a we see a lot of companies just go with for one big audit spend all of the money in one go I don't think this is the right approach I believe it's better to just keep a keep some flexibility and and then after this is finished you can go for a big well-known reputable company to put this stamp we know it is important to have this information on your website when you're building a cryptocurrency project and then not only you're going to have this stamp you're actually going to sleep better knowing that your smart contract is in fact secure um one more thing I want to discuss as a little bonus as uh while working in at ulam I've had a lot of different different smart contract designs I've done many of them and because of the the ways we've been testing and producing our code we've been able to build over a dozen smart contracts and those who have been which have been audited didn't have any high or critical V vulnerabilities so has been a pretty great track record and one of the crazy great ideas that we've come up with was micro contracts and I want to introduce this because it's been very particularly interesting to me and the idea here is that if you have a certain smart contract or a set of smart contracts you're going to you're GNA not going to mix logic and assets together that don't work together so for example let's say you have a farming smart contract what it does is locks user funds and in turn gives them some rewards like standard farming you give liquidity tokens you get some protocol Rewards or something else and and here uh a lot of smart contracts are based on the basic synthetics taking which is like 60 lines of code and with this it looks pretty secure it's fine but if you're going to add some more features to your farm like rewards for longer stakers Etc um you're going to run into this scenario where users are putting money into one place and your smart contract has 1600 lines of code and it's not really using these funds except for withdrawals and you're putting all of this money at risk Without Really any need to do so you're just want to lock them and it just needs takes just one line of code that is wrong or one missing check and all of this money is gone so this is why each user could simply have an escrow account and this is especially convenient for low gas blockchains where the gas is cheap and you just create an eser account for each user and this escro account lcks the money and updates the farm simple as that and now what you've done is you have moved all of these assets as risk into a smart contract which only the owner can interact with as like 10 lines of code long so you can audit just this small part of code and then you can supply as many lines of code that you want into the farm because the only funds that risk are the rewards it themselves so you don't even need to audit the main farming application because uh the assets at risk are very low so I love to see new modular smart contracts especially with the new EIP diamonds and well I I hope to see more modular smart contracts on the ethereum network and because it's easier first of all easier to audit easier to read easier to make sure all the logic makes sense and one more convenient thing you can make safe flash loans without worrying about re-entrancy if you put the flash loan smart contract separate from the main application all right and uh with this with these words I want to finish the part of smart contracts but it's not everything that will make your D app secure thank you yeah thank you go okay let me share my screen my screen with the slid yeah can can someone confirm can you confirm that you that you see uh yeah it works okay great yeah so okay so my part will be about the infrastructure security yeah um so um yeah smart contract is the is not the only one attack Vector yeah when we check the the history of the hacks yeah for the last let's say I don't know 10 years yeah uh yeah we can definitely see that the there are many many hacks uh done on infrastructure itself not only on the smartphone tracks yeah and we can compare probably we could even compare like a the amount stolen or even amount the number of the attacks yeah it could be even it could even exceed the the smart contract ones yeah so yeah this is obviously uh um important area uh to to check yeah and yeah so basically this is yeah now you can see like how a typical infrastructure of the decentralized centralized application um looks like yeah with many many parts here some Parts could be missing uh here but uh uh I think I think it's it's it covers most of the of the scenarios yeah so yeah uh on the white squares yeah you have a typical component starting from the browser yeah that the user is accessing the the the US application then you have a uh DNS here content delivery Network front and backend blockchain if you host your own note yeah or it's it's if not yeah it's outside of the structure and then you have a build system on the right you have all possible act vectors not all possible yeah but most common let's say that you have to you should take care and and watch out uh yeah and in the next slides I will be going one by one here and explaining them with and giving giving examples so let's start with the first one is cross side scripting um it's quite uh common attack was quite common attack in the uh times when the PHP was the main language yeah in the web two yeah before the crypto it's still it's possible yeah in more sophisticated ways but to understand it yeah if someone haven't hear about it yeah so the most common uh example is like let's say you have a your application there's a user can post a comment yeah for something yeah or there's a forum and can someone can uh submit a a post yeah or topic and the posts yeah so what we should do is that after after user submits the uh the comment yeah when we render this comment we should escape the content yes so that he will that the user won't uh that is not able to inject the the JavaScript uh into the browser so that it will be executed on all users uh browsers yeah so this is the the most common attack here it doesn't happen in these days because we have a um modern framework like react yeah and yeah and those those Frameworks they Auto uh Escape all the all the variables yeah so there's nothing to worry about in most of the cases but when we are doing something custom yeah like in this example here uh the wallet connect yeah uh this a was this was a back in the wallet connect protocol and what happened is that they were doing something custom and they had to um take a variable from the URL and put it into the script and they probably as far as I was able to understand they rendered it the the JavaScript in the back end yeah with that variable and that variable was uh it came from the URL yeah so the you could prepare a a specific URL someone could click on it yeah in the URL there was a script that could then be executed when the user click on the that on that link yeah but obviously the hack the the back was discovered before uh before being exploited yeah but it shows that the that the cross scripting are still possible yeah and crypto and or where fre applications are are uh still uh you still can do that on those applications yeah so you need to watch out here yeah so next one is the the the entr modification yeah mostly in DNS yeah let's call it like a yeah uh DNS hijacking uh yeah so here the attack looks like yeah someone takes your DNS entries here change them yeah and point to the to the to the fake website mostly it's quite hard to make this happen yeah cream Finance yeah was compromised yeah a couple years ago uh and they said that this was a the the the their DNS provider was compromised here uh in the way either the the employees employee did that or someone else yeah I don't I don't believe on that one yeah I think that the the in most kind most of this uh examples I will be I will be showing them more in the next slides here it's like a yeah they their credentials probably were compromised or they were sharing DNS credentials yeah to with let's say I don't know marketing team yeah because they they were preparing some advertisement URL someone just ch those entries yeah there was no logging yeah yeah five or more people were sharing the same credentials yeah and then after the attack yeah nobody were able to nobody was able to uh point out who who did that yeah so that that one yeah the next one is the the injecting mpm uh package obviously it's not only about the npm it's not only about the nodejs this could happen in in Python on Ras or any other language yeah the the the nodejs and and npm is the the worst probably environment like because the the because there are many dependencies yeah basically so if you are building a a front end application or or desktop JavaScript desktop application yeah the dependency tree is really large yeah so so yeah in this example yeah there was a I'm not sure how many of you remembers that the bit pay wallet yeah the most popular desktop and I think mobile um wallet for the for the Bitcoin uh yeah was compromised completely compromised in the way that yeah they had many dependencies yeah and yeah and the the the not not even their direct dependency but the dependency of the dependency of their dependency yeah was like a some really small Library yeah I don't know I don't remember one I don't remember which one yeah but it was like something about sorting AR yeah something some really small Library yeah and the auor of that Library noticed that oh my my is used by this big Bitcoin wallet yeah with many users yeah so what I could do I would just place some small m c there yeah bump the version publish it and just wait yeah until it will got get into get into the the bit bit pay wallet yeah and after like six months or a year or something that yeah it got there to the bit pay wallet yeah and the code was the most code was really simple it was like if the balance of the Bitcoin is more than 100 coins 1,000 coins yeah 10 private key to the anonymous server somewhere there in like a one of the Obscure countries yeah and yeah yeah this way yeah the millions were stolen yeah it was like a really huge really huge shot yeah probably still uh those coin I I I think those coins are still lost yeah nobody were able to point out to the who was the attacker um there because the the outter of that labor probably was completely Anonymous there yeah or he yeah something like that yeah um what else yeah yeah so this is like a obviously you if you are building his prot application you are getting famous yeah and and the author could notice that uh that yeah he's he he use his package yeah then then you could have a problem you always have to watch out for this scenario okay so next one is injecting the code here you can inject the code in many different places here probably the easiest one and then I have really good example here is the content delivery Network yeah because yeah most of the people thinks oh content deliver Network it just caches the things yeah so yeah we don't need to care about it yeah uh and yeah I think that the the places in the infrastructure when you think that they are not important yeah are the best one to to to to compromise I would say yeah nobody look look at them yeah so so this is the best one and this is this example is from the algal system my Alo wallet was a web based wallet similar to the previous one uh yeah but just it was run in the browser and stored private keys in the local storage u in the browser what happened is that someone compromised yeah the content Network injected malicious code that as far as yeah I can imagine did exactly the same so if the balance is uh substantial yeah yeah send private keys to Anonymous server yeah and it happened yeah for the my wallet and millions dollars was were stolen then um yeah and nobody was able to point out who did that yeah this is the worst part yeah worst part yeah so this is was the worst part and this is the common scenario in most of the infrastructure HS yeah um yeah that will I will provide probably more later uh explanation yeah so so next one is like a modifying build script uh so the build the the build script the build system your continuous degration continuous delivery uh system is like a something that similar to the to the uh content delivery Network yeah it's there yeah it works it builds your your artifacts etc etc you don't care that much about it you don't treat it as a purity in your security uh procedures etc etc yeah but yeah this is the best place to put a malicious code yeah to to add to add some code here that will be executed later on on the back end on the front end yeah whatever yeah here the example is really prominent one yeah it is like from two three months ago I think and what happened is that the XZ uus is a is a really tiny library that is used by SSH demon yeah and one of the contributors who was prob as far as remember was Anonymous uh yeah placed malicious code in the build system there in the development pipeline um uh and was not undetected yeah basically yeah so nobody checked what is that yeah because it was just a bu system yeah later on uh yeah someone was running the SSH demon yeah running some test on on on on it yeah on the new version and noticed that oh the establishing Connection in this new version it takes uh 400 millisecond more yeah and this guy started investigating what happened yeah why what was the what is the reason behind that yeah at the end yeah just found out that there's a there's a there's a back door basically yeah in the S yeah that allowed basically to uh to establish connection to any Dem so really serious problem yeah it was discovered basically in last minute because the the the build the binaries of the S demon was already there in the in the alpha and beta version of the most famous news distributions like Dean Red Hat probably as as far as remember yeah so like I said yeah really serious uh um uh uh thing that yeah shake that was everywhere in the news Okay so next one is like a infrastructure itself yeah this is kind of the umbrella umbrella back some kind of the basket for all the things yeah so so it's like any if any anyone will have access to infrastructure yeah yeah he can do nasty things yes you should always remember to uh to look at your infrastructure as a whole yeah not only like a I don't know hosting your back end hosting your front end etc etc yeah even like a GitHub itself yeah make sure that um that let's say yeah everyone has a two Factor notification enabled yeah enforce those on the GitHub settings you can do that yeah then you should have protected branches yes so that nobody can push to to those branches only through the PO requests yeah so then you can notice you can do code review yeah you can accept those P requests yeah so you can see the code is is there because if you don't do that yeah how you will notice that someone pushed a tiny comit yeah with comment fix or something like that yeah to your to your branch here with Mal SC and then then uh couple of more comments here that will hide this one committee yeah probably could be unnoticed uh uh yeah so this is quite important yeah so next one yeah it's like a yeah let's go to the to the best practices to avoid infrastructure attacks yeah but before we go there yeah this obviously like probably everyone noticed right now is that the yeah most of these attacks on the infrastructure require requires require privilege access yeah so it's like yeah I not that everybody of you could say that like how this could happen yeah that someone got privilege like a got privileged access to the to the infrastructure yeah yeah it shouldn't happen yeah but yeah we should safely assume yeah that most of them I would even say like all of them uh were done by the Insiders yeah uh yeah and then the worst case scenario is that they they uh they they are the it is really hard if you cannot point out who did that yeah because you don't have you are sharing all the things yeah it's really hard to uh to prevent those attacks yeah so the best practices is like a um they need need to take this into consideration yeah so okay so next one next slid I will be listing all the best practices probably not all of them but the most I think from my perspective the most important one you can track uh them you see if you are um if you are following them yeah and track your score yeah just for your own uh um curiosity let let's see that yeah so the best practice is that the so the you should treat each contributor as a potential uh Insider thread yeah this is really important because if you are doing that yeah um and if you're doing that uh and you you are designing your infrastructure keeping that in mind yeah all external attack will be all external attackers will be nothing to worry about probably yeah it's like yeah if the if you are secured against Insider attacks yeah yeah probably there will be the The Outsiders yeah will be will have much harder job to do yeah then you need to identify all potential attack surface in your system Yeah so basically go through through after the webinar probably go through the my my checklist checklist and check all those things yeah how you cover those elements we pointed out yeah yeah so this is also important yeah then the next one is like a if you are if you you have a contributors yeah all of the changes to the infrastructure yeah deploying the new code updating the network all those things should be loged yeah because if you do that yeah then then Insider won't be able to pull off any any attack yeah because yeah yeah it won't be unrate un trustable uh yeah and he will be cut later on yeah so this is important then uh this is also like super important yeah obviously two contributors shouldn't should never share the same credentials yeah because yeah if you share credential to any part of un infrastructure yeah you won't be able to point out yeah who did that yeah because five people yeah were had access to the DNS system for example yeah then there there there are moments yeah in the when you are developing your applications that you need some kind of the Privileges super admin rights yeah let's say yeah B on production and you need to investigate or something like that yeah bad thing yeah what yeah you should limit amount of the the amount of the people the number of the people who have access who have super ad me privileges probably I would say to the one yeah which is a c so then if there is something bad happen yeah there was a hack yeah C is responsible for finding the designing the system so that you can find out who did that yeah if not will be the one to blame probably yeah either as attack area or the one that who have who was not able to design the system in proper way yeah yeah this this this probably works for a team like up to I don't know 10 20 people I would say yeah the larger probably yeah yeah this this is getting more complicated and then probably yeah to make sure that there's no manual work in between yeah and um there's no manual work in between you should have fully automated continuous integration Contin deployment pipeline yeah so that yeah everything is automated yeah there is no manual steps so nobody can mess up in the middle uh the process and hide something yeah next one next slide here is that we have through the during the development process often what happens is that you need to update the build system itself yeah so to make sure that you have a continuous integration continuous deployment continuous deployment uh pipeline for your build system yeah so that yeah if there's a you have a Engineers yeah they can update it on the themselves they don't need to uh ask CTO to to to update it yeah this will happen uh quite this happens quite often yeah and this this will basically slow down the whole development process yeah then obviously yeah that one yeah needs to be updated manually yeah so the C should be should be only the one who changed that uh yeah the next one is like a limit your dependency because the I said in the bit pay wallet Yeah the more dependency the the the worst the worst you are yeah and yeah and then the when you are upgrading your dependencies you need to be extra helpful yeah it's it's in most cases it's a it's a nightmare yeah to update the dependencies yeah especially the more the more famous you are the more T you have yeah yeah it's like good luck with that one yeah you either sit with the really old dependencies yeah probably with some bugs yeah uh maybe security issues yeah or versus you you you upgrade one of your dependencies and then you need to spend I don't know how much time yeah looking through all the the the the looking through all the changes yeah that because the in the the modern tools like npm probably gives you the ability to okay give me all the changes to sub dependencies yeah when I upgrading that one yeah and give me even def yeah so we can look for the defy but could be massive ones yeah so yeah good luck we've done that one yeah the worst case probably yeah and next one is the um um everything should be part of your infrastructure yeah and especially probably DNS and domain register should be part of of of your infrastructure as well yeah so if you let's say use goad or yeah go probably let's say quite good one yeah but still yeah it is it should be under under the same infrastructure so if you use AWS I would probably move thef and Dom register to the under the AWS so you have everything under same roles same users yeah same privileges etc etc yeah and you don't have a separate account there yeah uh yeah worst case scenario there if you have only one yeah like I said only one account for the changing the the the analysis really bad one yeah same with the content delivery Network I know the cloud flare um is super popular yeah yeah it's like three clicks and you have super fast content uh everybody loves it yeah but it's a problem yeah it's then you have to have two separate accounts two separate sets of accounts here for both infrastructure and cloudware and both AWS and Google Cloud platform has have the own content Network I will just move it there there to have everything under the same roles users yeah privileges yeah and the last one uh is that yeah if you are hiring or have a new CTO the new CTO should rebuild the whole infrastructure from scratch yeah because what could happen is that yes old CTO could be really nice guy yeah etc etc but yeah you never know him yeah he could leave either a open some some back door for him or for someone else or accidentally there was some some kind of the things that he thought he will fix later on yeah but yeah forgot yeah and he was yeah he move on to different job yeah so yeah uh and then yeah you you change your CTO one 12 month passes yeah and and H happened yeah and then oh who did that yeah probably someone from inside team yeah you check your inside team yeah nobody is to blame yeah and then you don't even think about that it was like an employee or it was a CEO from a year ago yeah so if you are if you you are getting track if you are getting traction with your application you have a massive TV it's growing yeah yeah and you have those practices the best practices you don't follow them yeah probably should appoint okay yeah the CTO CTO should rebuild whole infrastructure from scratch yeah take back all the Privileges yeah and rebuild everything from scratch yeah and give the new privileges to new users to new contributors yeah and then you are probably much safer uh than previously yeah and probably that that's all yeah and now yeah okay we gave you like all the best practices yeah how to how you should do yeah and now it's your turn um yeah we give you like a three uh three things you can do right now uh to make sure that your your your security is in the good conditions in good condition yeah first of all yeah you can U use the link .io consult yeah to to book a consultation either with me or ukash later this week and uh yeah we can help you we can at least yeah try to point out the how you can move with your security setup yeah the next one is like uh we prepared the the uh the best practices checklist yeah in form of our of our PDF you can you can take it yeah you can just yeah do your own work after the this webinar yeah I believe I believe it will help you uh a lot um and then yeah obviously if you have any questions I will just uh unmute all of you uh and yeah you can start asking questions yeah uh right now uh give me a second yeah uh where you can unmute people yeah I think everyone should be able to unmute themselves so yes I'm able to unmute myself thank you thank you very much K and hookas for the presentation I hope yes everybody can unmute themsel if they have a question so yeah please go ahead with questions hey uh this is Taron and I have a question yeah sure am I audible yeah okay sure yeah so uh what about some internal infra so in in in our infrastructure we have some internal applications like you know liquidation liquidation BS and uh you know uh uh the different kind of bots that that does make use of uh the sensitive information for transaction signing like you know uh the the private key of EA do you have any special recommendation for these kind of internal application which which are just meant for you know as a as a gatekeeper for a protocol or application that yeah it really depends yeah because you don't need to have any private Keys stored in your buend to be still uh so you can someone could still hack it here probably so for example yeah do you have any front end that that craft transactions uh no these applications are uh primarily or Solly you know to run inside the inside the cluster so they're not needed to be exposed outside world what they do yeah what they do like for example say liquidation bot so we have a liquidation bot who's job is to uh so we we are basically a D5 protocol you know and the liquidation board job is to check for you know any any positions that are unsafe and just just you know perform Liquidation on top of that now as they have to perform a transaction we have to keep track of you know the primary keys or the the the private Keys you know for for U so for example if this yeah so if you have a b as as far as I understand that does that it just just liquidates positions here so this could be done by any user yeah so it's quite safe probably yeah you don't need to keep it as a as a as a super secure element yeah because it doesn't do anything special yeah in that regard yeah but for example if you have a landing Brewing protocol and you have a Oracle yeah that that provides pricing yeah to your contract yeah this a completely different scenario yeah because you could force liquidate people uh there manipulating the price I yeah yeah thanks yeah true any other questions please yourself please go ahead hi uh I have a question uh regarding uh the usage of um Hardware wallet for example when you want to go to an exchange and make a swap for example then you have to approve um the connection to from the website to the wallet and then also give the permission to the smart contract to interact with your Hardware wallet and in this case I wanted to know if there are some best practices to avoid for example some exportation that means that some fund are stolen or so when giving the accreditation for uh uh the signing operation yeah like from the user point of view or from the the user for example I go to case but I don't think that it's so much Rel but for example if you go to g.o and you want to do a swap then you have to uh approve um the signing operation uh from the smart contract to authorize a swap and then I got like a kind of warning saying okay warning this smart contract is not audited so the that there might be a risk that you your fund are stolen get stolen so that's yeah like Yeah Yeah from the from the user point of view it's completely different different like how we should probably run completely different webinar how it looks how the secret looks like from the user point of view yeah but obviously the signing up any transaction is always a I think yes so you need to basically take any any you need to be extra CES yeah when you are doing that checking the transactions transaction here whatever what what what does etc etc before you sign it yeah because it's like even the authorization could be a malicious transaction yeah that you are signing yeah so you have to be just super super careful cous yeah so meaning that um if I am if I want to do a simple swap I would have to check uh from the user point of view I would have to to check the smart contract or at least see that the smart contract was audited in order to be sure that yeah yeah yeah exactly obviously you need to trust the application you are you are interacting with is one thing and the second thing is not even if you trust it even it's un swap yeah you need to make sure that the basic that the what you are signing with your either online or with your Ledger device yeah is the thing you think you're are assigning yeah so yeah there Le two points yeah to always check and and then the third one is obviously if you the worst case scenario is that you are doing some something really is simple yeah oh I don't know yeah you go to some kind of website and then there's a a transaction that you need to sign yeah for sending I don't know one amount one one one piece of the token um yeah worthless token yeah to somewhere else yeah and you think oh this is like a stupid transaction yeah I don't even need to think about it yeah yeah this is any any transaction you are signing yeah they could be malicious one and could empty your wallet yeah so it's yeah so any signing um action yes should be really um we need to be really careful so um Al there some some way to mitigate the possibilities of that or just maybe using reput reputation exchanges also or even though it's not sufficient yeah yeah like I said two points yeah reputation one thing but the second second part is obviously making sure that you know what you're assigning yeah even if you use the the reputable brand yeah because you never know if they are hacked yeah or maybe you are accidentally on the wrong WR application okay thank you thanks yeah I have a question yeah yeah algor is using different types of storage like local storage box storage and This Global Storage is there any risk of using different kinds of storages like this doesn't it cause any security issue this question to Yeah Yeah so basically with with algorith each different types of storage they actually have to be used in different types of scenarios because unlike ethereum where you can just allocate a huge map and just put all of the data into this one data structure you can't do that in algor because the global storage is limited in size it's like a fixed amount so you have to use the local storage if you want to store per user data of course now when they invented boxes you can use boxes for this but in in general uh well you just have to think about the trade-offs it's really all about trade-offs with Al Grant and storage so it's not like one solution is particularly more secure than the other but you always have to consider that if you add another type of storage to your application there is some risk associated with it so it's more like you're actually if you're using Global Storage local storage then if you're adding boxes there is a chance that you will make some mistakes so it's like more like this way if you use more storage types there's more risks thank you yeah sure if you had more questions about storage on algarin go ahead Yeah well yeah we still have a time so other questions here from from other people yeah yeah well some somehow with boxes it like it almost looks like everything converges to just eum maps in my my opinion I have a general question like uh I'm actually working on this algor I'm doing PhD now oh is is it possible that I can join as an intern in your lab like I have to spend some time uh other than in other country like I'm in now Italy now I have to shift to some other country for some time because it is included in our PhD program I had to spend some time in other lab in other Research Center is it possible for you to try in your lab yeah yeah definitely we have open positions here on our website here so feel free to apply there with your C okay thank you thanks perfect I guess that's it right no more questions right or if not now it's your time well conell Lucas thank you so much for the presentation and for the audience every everyone thank you so much for joining us um I hope you learned a lot you know how to proceed with uh when you need to do an auditing probably start with someone doing the first uh the first step as I could see maybe a freelancer then you go to ulam labs and then if you need the stamp from one of the big auditing firms then you do that as the last step thank you guys so much um I'm sure we'll see you also in EBC in October later this year um and yeah I think that's it from my side conell and Lucas do you want to say final words yeah well thanks all for staying so long and coming to this presentation hope you learned some valuable insights into the topic of auditing and security of web free apps yeah yeah thank you Victoria for having us yeah and thank you all of you for joining us today thank you all guys and see you hopefully all soon bye bye bye by thanks guys for