UnSafe: When web2 security undermines web3

Transcript

[Music] Hi. So, hi everybody. Thanks uh for coming. Today we'll talk about uh some web two to web3 security. I'm Maya and not him. So, he was supposed to be here originally, but I you'll have fun with me anyway. Uh yeah. Okay. Start over. So, I said I'm Maya. H I'll hope you'll have fun. Anyway, uh we'll talk about the web two to web3 security. We'll talk about what this means. Um so let's talk about the framework. We guard h millions if not billions of dollars in

web3 protocols. Uh we know they consistently get hacked. H people lose their money obviously. uh and web 3 developers have been a prime target of how to get in to these hacks. We'll discuss this a bit later and we'll talk about some attack trends. Uh so okay so when I was getting originally into blockchains this was a while ago um and we discussed we were talking about blockchain security initially it was the security of the protocol itself and then very quickly it became security in the web 3 domain or specifically smart contracts and smart contracts were

continuously getting hacked uh and this was kind of the wild west but we got better as a community So um we started developing standards uh as to how we address these type of threats. Uh but web two uh threats that are continuously addressed by uh offchain entities guarding money such as banks, financial institutions, they they are very on top of security and web two security. However, this doesn't always translate to web two security in web 3 focused companies. So we'll talk about that. We'll talk about specific examples of this and we'll talk about how we can do better.

So uh yeah, so this is a nice chart taken from data from W rect on the recent few years trends in attacks and losses in the crypto world. So we can see that until recently uh more money was going getting lost to web 3 exploits and uh this sits with what we know right there were a ton of uh of smart contracts hacks bugs in multi-IG smart contracts h but we have gotten together and there's now standards for how we implement certain functionalities on blockchains we have monitoring companies um and web3

companies companies also know to spend money on security and audits when it comes to to smart contracts. And um even though exploits are still growing in volume, the uh theme has now changed and actually web two losses, meaning hacks due to h not investing enough in web 2 security have now have now surpassed web 3 hacks in losses in volume and in dollar amounts in the past year. So this is quite surprising when you think about the fact that actually there are there is a long history of protecting against web two

attacks. So there's a lot of tooling there the world of security in web 2 is far richer but somehow we are going backwards in the crypto community losing money to things that other domains are not losing money to or not as much. Um, okay. So, this is uh basically what I've said so far. Um, and we're going to talk a little bit about where people are vulnerable in the web 2 world and uh what we can do about it. So, again, in web 3, we now have tooling, we have audits, we have bug bounties, monitoring, and if you don't have these things, then your project tends to not get taken seriously anymore. However,

erh there are many many web3 companies that don't have dedicated full-time employees to security like regular plain web 2 security securing your code base. H making sure that uh you have proper education on security for your engineers. Um making sure that you review PRs, making sure that your dependencies are in order. Um, and this is a thing that just would not fly like with a bank, right? There is no bank in this in the world, even if it if it only guards a few million dollars, it doesn't have a security team that monitors everything basically. Um, and we see this with the Wazerex hack

um, which was a multi-stig compromise that that resulted in $230 million losses. H there was the radiant capital hack also multi-IGS sign keys getting leaked er because not they weren't properly stored or because of uh social engineering attacks that just got people to either give access to their devices erh by running some malicious code or just um just by storing them in in areas with insufficient security. A lot of companies also store multi-IGs on the same device, different keys to to like

different multi-igs keys on the same device, which is a big no no. And the thing is that we've been seeing these hacks since Mount G. Yeah, this is not this this has been going on for over 10 years. Uh and we we somehow are not learning from it. Um we are also being very confident about using hardware wallets. So we think h okay we'll use a hardware wallet uh like Ledger and that's great because they're really good for security but they're actually good for being a cold wallet right but then we try to use them as a hot wallet because we want to use them for payment so we say okay we'll wrap them in a multistick okay but then Ethereum is not natively built for multi so we need a

web 3 infra smart contracts to accommodate multiix so then these contracts get hacked and then we get kind of better about it and people start using safe uh to handle their multi-IGs h but then they leak their their keys. So we've done nothing to do this or we have setups in which we have a multi people say okay we have a multi-IG with 11 people to sign but actually the threshold is two. So if you think about it a two out of 11 multiig is much weaker than a two out of three multi-IG.

So kind of a lot of things that are pretty basic and in banking they won't happen but we keep doing them. Um yeah so let's talk a little bit about the bbe hack. Um okay so the bybe hack super famous h last year someone went away with uh $1.4 billion in revenue. Yeah too loud. Okay. Uh so 1.4 4 billion in revenue in seconds. Um and this there was no smart contract compromised here. Um again use of ledger with you know is safe and people relying on on the fact

that safe is safe and truly the smart contracts for safe are safe. However uh there was a lack of attention to web two security with the team at safe. Uh so a few things happened there. So let's uh kind of talk about what happened in this attack. So it starts with probably this is not in the slides. So an attempt to h access keys to the bybe multi-igs directly which apparently didn't work.

Probably they were doing a good job at guard guarding them. So what h these hackers did is go to the source. They said if we can't get the keys for the multi-ig for bbeit let's uh go and see if we can control something on the safe end. So what they do is they employ some uh social engineering and they send they hack a telegram account of someone who is a contact of a a developer developer at safe and this developer then gets a telegram message with some link. He runs a link. He presses the link. This runs some uh some code on his device. So it compromises the computer of one of the engineers at safe.

Okay. So the now the Mac is infected and nobody noticed and this is the first fail first failure here right because there was no detection software to h running on safe's end uh to monitor threats like this we'll talk about this in a while now um okay so infected via social engineering now the the attackers sit on this computer and they try to dig around to see what they can do so they find out that they can steal session tokens to the AWS uh to go and look around uh at safe implementations and files. So um and these attackers

probably from North Korea uh they don't like working in the working hours of the people from safe I don't know where they're from. Probably it's the middle of the night in North Korea or something like this. So they tried to introduce a new MFA device uh to AWS for Gnosis safe and they fail. They failed. They didn't they couldn't do it. Okay. So you couldn't add a device. So now what happens? There should be some alert to a device being added to the MFA but there is no alert because no one is monitoring this. So then okay the these hackers are like okay we can't keep doing this. We will get discovered. we have to work when the this engineer is working. So they sit on his computer and when the

engineer is logged into AWS they can fish around at AWS and they get to a bunch of files including the front end of the safe wallet like multi multi-sec. So what they do is they okay they plan ahead they replace some files and they do some smart contract work to that looks very similar to what safe has going with a multi-IG and then at the moment that it's convenient for them they send to the multi-IG participants at safe a a transaction to sign that looks benign because the front end looks benign but actually it's a malicious front end and the transaction they are

signing is not the transaction they're looking for. They were smart about it. They change the transaction data just in areas that are not likely to be discovered. But um nobody notices this front-end files being changed and the money is leaked so fast that it's unreoverable and everything goes terribly terribly wrong. Okay. So, okay. So, so this is kind of a summarization of what we just said. um no entry to the no detection to see malicious code running on the user and device on the engineer's end um which should always exist like pay for for EDR tools don't use offtheshelf free tools

because the hackers also have access to these tools pay for a good company that you trust and don't chip out on this because if you chip out and you don't pay I don't know what the fee is you can lose $1.4 billion. Um okay. So, we what what should what would she should they have done or should we do as a community? We should um make sure a that we pay for monitoring software and uh we are we pay for a security team that is on top of this and that sets alerts correctly. The AWS thing, the MFA device should have been caught. There

should have been have been an alert and this type of alert if anyone would have looked into it they would have seen it's a malicious attempt because there's no way to to hide that um map critical assets the fact that any one engineer can change your front end without any review should also this is also problematic right user end facing UIs Don't allow them to even be changed by one person hope like uh optimally have it reviewed have some alert to a UI file being changed front end file being

changed because this shouldn't happen a lot right never change the UI so if there's a change to the UI this is suspicious especially if we as a company don't know that something is coming right typically people know when the the UI is changing um okay monitor web 2 infra obviously We've talked about this um and learn from the past, right? Because we've seen all of these hacks um people uh changing dependencies, monitor your dependencies, uh pay for pay for tooling that monitors your dependencies to find if you're using a hacked dependency. This is also like we we saw the XC utils back door uh catastrophe. A lot of social engineering

effort going into that. So just pay for something that monitors this for for you if you can't keep up with the literature on this. Um yeah. So and this is kind of getting even worse the dependency issue now with AI. You use AI automatically to write code. You don't check your code. You don't check their dependency. You can be easily inserting a malicious dependency. Um okay. So I think we've talked about this. So obviously SCA tools, pay for them. Don't use the free packages. Uh strong NF MFA. I know it's annoying.

It's annoying to get these uh like you log in and you have to go to your other device and sometimes you have a lot of back and forth, but it it ultimately saves you from a lot of heartache in the end. Just do it even though it's annoying. Um don't auto approve PR. So this is big like a lot of the the hacks that we're seeing not only in crypto everywhere stems from uh PRs that sometimes use either dependencies of that are not trusted or just malicious actors from outside pushing PRs to your codebase that are problematic. So the XZ utils example is a prime example. It's also an extreme example but this happens all the time especially for crypto companies.

You know we're open source. We want uh people to be to we want to be inclusive in our projects. Someone wants to uh contribute. We're very forthcoming. Uh but always always always double and triple check these PRs. Check the code. Review the code. Don't let CHP review the code. Just do the work and review it. Um yeah. So this is actually so my colleague wrote wrote this made these slides and he told me about the threat that I actually was not aware of which is the the North Korea hiring threat. So apparently deep fakes are becoming so good that people are interviewing for security positions uh from for malicious entities

and uh we have actually had this happen both at starkware and at starknet people interviewing we caught it. So, always always always be suspicious if people are interviewing on Zoom. If they're interviewing for a for a security or privileged a position, have them come in personally, pay for the plane ticket, even look at the person, check their credential, look at their social media. Just don't like this is a terrible security hack if this happens. Um, yeah.

So, what can we do now? So, we we've said a lot of things, but let's go systematically and I'll add a bonus one at the end. So, obviously, endpoint detection and response, pay for proper EDR. Pay for it. Don't use the free stuff. Uh, use least privilege principles. Don't have one person that has privileges to everything. Don't have people with privileges to things they don't need privileges to. When you hire someone new, don't automatically give them privileges to everything. Like at Starkware, we have like a 3 month wait period for people to actually have privileges to things that are sensitive

and they only get access if they need it afterwards. Um so um PR abuse again code review code review properly it takes time it takes work but it's part of maintaining a safe code base um supply chain exposures so dependencies and dependencies is super easy because there's tooling out there and there's people keeping registries you just need to do the work to keep up with it and you can do it automatically so it's just really really a shame to not do it uh pay some money. H even if you don't pay a full-time employee to do security, which you should, you always should, just pay for this. Um

and obviously monitor critical infrastructure. People trying to add an MFA device to your AWS. Be on top of that. And the last thing that I want to say here that's not on these slides is actually erh people replacing the UI is a real threat and we now have techn emerging technology to deal with this. So uh we have client side proving technologies. People are now trying starting to prove WASM. You can have provable UI that is verified on the multisig signer end that verifies that the correct UI code was executed. Front end code was executed. H and then you

just cannot do these things anymore. So if you really want to be proactive and security forward then you can do things like this. There are you can there are proofers that proves Rust now people are starting to prove R was um so this is the future um okay I'm not going to go back on this but uh okay so conclusions don't only invest in web three security do your homework on web two security teachs not to click links right these social engineering things are so good they're so good you're thinking Okay, I'm a security aware person. This will not happen to me. They are so good. They will hack it the Telegram account of

someone you know. They'll write a message that resembles this person and they'll write something super super convincing and you're busy and your friend asks you to check something out out like have EDR in place, have education in place. H it's it's annoying but it really really is necessary. Yeah. and and don't hire people that are from North Korea and use the fakes. Yeah, don't do that. Thank you. [Applause] [Music]