Security: The Make or Break For Transitioning from Web2 to Web3 by Shahar Madar
ETHDenver 2023 · February 2023 · 17:41
Security gets framed as the deciding factor in whether mainstream web2 users and companies ever fully move into web3, given how unfamiliar concepts like private key custody and smart contract risk are outside crypto-native circles. At ETHDenver 2023, the talk argues that wallet security, audited contracts, and clearer custody models need to mature before broader adoption becomes realistic.
Speakers
Topics
From ETHDenver 2023, hosted by ETH Denver.
Transcript
All right. Uh, hey everyone. Thank you for u joining the session. I'm Shahar from Fireblocks. Um, and today we're going to talk about all the security considerations they needed to take as developers and founders who are entering this uh space, the web 3 space. Um, many from web two. Um, right. So before jumping in, let me introduce myself. Um, so I lead the security products unit at Fireblocks for those who haven't heard about us. So Fireblocks has been running around since 2018. Uh, founded by cyber security experts who brought MPC um into the
crypto space uh on the mission to secure blockchain. Uh from then we've grown um to supporting over 1,400 businesses uh span out over 80 million different wallets uh for them. Uh and our platform allows them to do self custody and any onchain operation they want from smart contract management uh to just basic transfer operations. Uh so whatever you need, we're here at it Denver to extend that outreach to developers. Anyone who's building um and this why we also have a bug bounty uh feel free to reach out to our booth a little more about that. Um so my job at Fireblocks is to
make sure our customers are safe uh from attackers, from malicious insiders, from anyone who wants to steal their money. uh which means I don't get a lot of sleep uh but it's fun. Um I've been doing tech and security for around 20 years um more proficiently both in like uh public and private sectors building code learning code studying code breaking code uh both from a security research perspective development and product management and um this is my first time Colorado so I'm excited.
Okay. So, when you look at web 3 from the attacker's perspective, for too many projects, it looks like this. It's like picking money off the ground. Uh it's like too easy for the attacker to get in and make profit. And this is usually because either security wasn't top of mind for those developers, those founders, or they just say, "Yeah, we'll get to that later." Or they didn't know how what to do. Um, and this we'll get to that later after we grow big enough, after we might uh be interested uh be interesting for someone. That's a
common approach. Um, and that could be great. But if you combine that with an amazing phenomena that we see on web 3 which is hyperrowth. Okay. So it's like it's amazing. It's like the entrepreneurs dream right. You set up a new you have an idea you create this amazing product and everyone loves it. Okay. Everyone started using that. You have uh hundreds thousands uh tens of thousands of users all of a sudden and it's really amazing right? But if you combine those two, the let's get to security later on together with the hyper growth. So you realize you become a target. You're interesting for attackers very early on. And when you combine those two, you get you get over
$3.8 billion that have been stolen during 2022 alone. And if you go over and expand to previous years, you get over $10 billion. So that's a lot. Um, and why why are attackers so interested in this space? Uh, so the reason is that basically every web 3 app is a financial app, right? No matter what you do, no matter if you have NFTs, project tokens, protocol tokens, tokenized assets, stable coins, whatever you do, basically it's either money or directly correlated to money. and comparing that to the web to alternative where the attacker would
have to steal your data and then sell it to someone, right? So, it's just an extra step. It's like so much easier, so much more profitable to go directly at web three projects if you can. So given this huge incentive, it's not really surprising that we see tons of different attackers and um types of different attack groups in this space. Uh it varies from nation state supported groups. Um Lazarus being the most infamous one in this space obviously, but they're not alone. Um we also have cyber criminals who are entering uh the web 3 space and we're actually seeing
today hybrid attacks where uh an attack group and attacker would reach to a victim to a target computer and then dynamically decide whether to deploy a ransomware to extort that that victim or if they have crypto to actually steal their crypto. Right? Right. So it's like hybrid attacks and show us that those traditional attackers that have grown on web two and traditional cyber exploitations now are going into um now getting into crypto as well. Um and obviously you have those opportunistic groups uh just bunch of guys sitting at the bar saying hey those guys screwed up let's make money off of it. And finally, you have your insiders. People who you
trusted, you brought inside your team. They've been running with you for a while and then they decide to flip to find an artillery upside and drain your project. So, let's talk about your web 3 project. It starts with your team. Couple of people that have an idea and they start working. and they start building this new amazing app. And your your app, your web three project has some different components. It has like the web two interface, the infrastructure, um everything that's onchain, your smart contract code, uh your financial model that you've created, obviously your
wallet that holds like assets and private keys, and some sort of a governance mechanism, usually either a Dow or something else. Then you have your attacker who tries at the same time both to attack directly your project to drain the project, take the money out or go after your team and from there segue into um the your project and gain control over it. So what can you do to to be secure on web 3? We consider the four pillars of web 3 security and together they give
you an end-to-end view of what's important with securing your web 3 projects. It starts with your team, the people. This is the first thing you have. Um the trust you give with them and the controls you have to enforce that trust, make sure it's not abused. Then you have your infrastructure. That's everything that you rely on but don't build yourself. From there you have your code and design. And finally you have inf um you have incident preparedness because something's going to happen. Someone's going to try to breach into you um or be successful in that. But something
you're going to experience something and this is a feedback loop, right? Like after you've done all of that, you go back and you improve your controls, you improve your infrastructure, you improve your code. And this goes on all the time. So let's start with your team. Your team can be compromised in two main ways. First thing we're seeing around is attacker is just trying to hack the people hack to engineers computer like happened on a running bridge hack where Lazarus were able to to reach to an engineer's uh machine and from them from there move laterally to a production system and steal private keys but also we're seeing nation states trying to
insert their agents into DeFi and web 3 projects. We've seen reports that both North Korea and Iran are doing something like that. And the idea is that once you have your insider person, you can do whatever you want, right? It's like having a malware in a say human operative. So first of all, you need to ask yourself who's really on your team. I know it's hard sometimes when you have when you employ annons as part of uh of your project but you need to find a mechanism that you are comfortable with validating their references validating their experience making sure you don't have an insider threat with that second limit your blast radius someone might be compromised someone might be uh a rogue
employee make sure you have basic role permissions make sure when you manage access control to smart contract management administration and deployment. This should be only granted to specific people, right? Like your head of bisdev shouldn't be able to deploy new code to to other chain, right? Um and finally, for anything that's not on chain, make sure you either use MFA or ideally hardware security keys, right? For example, for your AWS environment. Um and last but not least, who is doing security? Who is your security person? I know I know it takes a village right it's not one person job but you do need that one
person who actually is leading about that waking up in the morning asking themsel what could go wrong what can I learn and take from that hack that happened yesterday and bring that back home follow up on actions second is your infra everything that you do not build yourself first thing Here is your key management platform. And the reason it's here and not on the next slide where we talk about code is that in almost all cases, unless you have a very extreme edge case, you wouldn't want to build that yourself. It just requires very niche expertise and when you do go to um to a key management provider, key management
system, make sure it supports both multi-step approvals and multiffactor authentication. So you don't have just one person on one screen, one click deploying, changing, transferring funds, then you should go on and map all your external dependencies. It's going to go bigger over time and that's okay. I mean, you don't want to reinvent the wheel. You want to um build on top of other things that already built. Uh that would be any external services, contracts, oracles, anything both onchain and off-chain that you rely on as part of your risk management, security risk management. Um the great example of what happened to Badger Dow
is that basically the attacker was able to compromise their Cloudflare um API keys and from there own their front end, stealing $120 million from the users. Um, so make sure you're not uh the attacker is not the only one who knows your system end to end. Make sure you're the one who knows that as well and you can do something with that. Now let's move to code. We all love code. Um, many people are developers and there are two stages. All right, first the launch, the MVP. Make sure you test yourself, test your code. There are many
good security products out there that can scan your smart contract code, find known vulnerabilities, found known misconfigurations and alert you on that. After that, define key invarants for your modules, for your methods, and document your code. Document all that first for yourself so you'll know what's going to happen and what you expect your code and your product to do. Second, when you do get an audit, and you should get an audit, um the the main pain point that I hear from tier one auditors all the time is that people pay so much money to them, but also come unprepared.
The result is that you're actually paying tons of money to someone to do code review for you, right? Because auditing is just a time boxed security check. And if you spend all the time just to reverse engineer your project and understand what's going on instead of just reading documentation and and comparing the key environments to your code. So it just throw money, right? And it's too shame because maybe you also waited like six months to get this audit. So it's going to take time to get around.
Okay. Hey, now that you launched, you need to stay secure. First, set up a bug bounty program or partner with someone who can offer you that. Make sure people white hats can reach out to you and tell you when they found a vulnerability in your code. After that, for the parts of your code which are open source, make sure you employ operation security. Meaning if you do find a vulnerability in your code, do not fix it on the open source side before you deploy it on chain.
Otherwise, just giving the attacker free cheat sheet, right, to how you product and unfortunately we're seeing people do that and it's just very bad practice. Finally, make sure you're able to test your key environments. Ideally, every commit, but at least on every release, so you make sure you're not breaking your key assumptions. Finally, we have incident preparedness. Now, six months ago were when Binance experienced um their incident, they responded very quickly. Now, I'm not going to argue centralization versus
decentralization, but I will highlight this. The first loss was about $580 million. Using the very swift response, suspending all the activity, they managed to lower that to 100 million. That's almost 85% decrease in attackers profit and Binance's loss. This is insanely um good response in the sense of cyber security, in the sense of risk management. And the key here is that you cannot respond that quickly if you're not prepared, if you didn't think about this case beforehand. So, do you have an instant response plan? And for those of
you who, and that's many of many of us, right, work globally. Um, does it work if your co-signer is just a Discord handle and it's 3:00 a.m. their time? So, what do you do, right? you need to be able to respond quickly no matter what time. There are many different solutions for that. Um, some involve external trusted parties and we can uh discuss that after. Second, you know your system the best. Make sure you document and identify all the ways that people can attack your system. Um, you can do that with your CISO when you're like hundreds of people, but you can also do that where
just three people. It can take only 30 minutes. Sit down, take a pen and paper and document what do you think could be could happen and um and could go wrong. Right? Once you have that, this is key to success and and being actually prepared for the incident that may come. All right? So to summarize, make sure you know and control your team. All right, this is the first step. After that, be and think like your own attacker. Think about way to exploit your own system and what could go wrong and prepare for that. Help your auditor when they come and help you, but don't
help your attacker. Do not leak secrets. Do not leak vulnerabilities. And finally, don't get caught up by surprise when you experience hyperrowth. It's it happens more often than you think and be prepared for that. That's it. Thank you everyone. Thank you for your time. Feel free to reach out to me uh either in person, I'm going to be here for a couple next day, or over Twitter, email, Telegram, whatever you need. And uh Fireblocks is hosting uh back bounty $25,000.
Uh feel free to reach out to our booth and hear more details about that. Thank you.