Security: The Make or Break For Transitioning from Web2 to Web3 by Shahar Madar
Ethereum Denver·Mon, Oct 9, 2023, 12:00 AM
03/03/23 Security: The Make or Break For Transitioning from Web2 to Web3 by Shahar Madar "With the expansion of digital assets as the world evolves to Web3, every application has essentially become a financial application. With that comes a lot of security risks in Web3 that didn’t exist in Web2. We need to look no further than the persistent DeFi hacks to understand that security can no longer be an afterthought for developers. DeFi projects scaled at unprecedented rates with insufficient security in place, making them honeypots for hackers. Web3 projects will be next. In this session, Fireblocks’ Head of Security Products, Shahar Madar, will discuss security considerations for Web3 builders — from the open-source nature of Web3 to the immutability of smart contracts to developers’ ability to build back doors to projects. Building in Web3 is a much more complex process and building security into the code takes a new approach." Shahar Madar Head of Product, Security Fireblocks "Shahar Madar is Head of Security Products at Fireblocks, an easy-to-use platform to create innovative products on the blockchain and manage day-to-day crypto operations. He is responsible for maintaining the integrity of the Fireblocks platform and ensuring the highest standards of security for all of Fireblocks’ customers. This includes providing customers with full visibility of their day-to-day operations and implementing strong security mechanisms to prevent and detect attacks effectively. With more than 10 years’ experience in cybersecurity R&D and product management leadership, Shahar was previously VP of Products at Paragon, a digital intelligence and mobile security company. Prior to that, he spent eight years in the Israeli Military Intelligence (Unit 8200), eventually leading a team of 20 security researchers in cutting-edge cybersecurity research. Shahar holds a B.Sc. in Mathematics and Computer Science from Ben-Gurion University of the Negev."
Transcript
Very good. Hello everyone. Thank you for joining the session. I am Shahar from Fireblocks. And today we're going to talk about all the security considerations that you, as developers and founders entering this space, the web3 space, should have.
Many come from web2. That's how it is. So, before we begin, let me introduce myself. I run the security products unit at Fireblocks, for those who haven't heard of us. Fireblocks has been operating since 2018.
Founded by cybersecurity experts who brought MPC to the crypto space with the mission of securing the blockchain. Since then, we have grown to support more than 1,400 businesses, encompassing more than 80 million different wallets for them. And our platform allows them to perform self-custody and any chain operation they want, from smart contract management to basic transfer operations. So, whatever you need, we're here at ETHDenver to extend that reach to developers. Anyone who is building, and that's why we also have a bug bounty program ; Feel free to stop by our booth to find out more.
My job at Fireblocks is to ensure that our customers are protected from attackers, malicious infiltrators, and anyone who wants to steal their money. Which means I don't sleep much, but it's fun. Hey. I've worked in technology and security for about 20 years, in both the public and private sectors, creating, learning, studying, and deciphering code, from the perspective of security research, product development, and management, and this is my first time in Colorado, so I'm excited. Good.
So, when you look at web3 from the attacker's perspective , for too many projects, it looks like this. It's like picking up money from the floor. It's too easy for an attacker to break in and profit. And this usually happens because security wasn't a priority for those developers or founders, or they simply say, "Yeah, we'll look at that later." Or they didn't know what to do.
And that "we'll see later" is when we've grown enough, when we might be interesting to someone. That's a common approach. And that might be okay. But if you combine that with an incredible phenomenon we see in web3, which is hypergrowth. Good.
It's amazing hypergrowth. Good. It's amazing . It's like the entrepreneur's dream, . It's like the entrepreneur's dream, right?
You come up with something new, you have an idea, you create this amazing product and everyone loves it. Good. Everyone started using it. Suddenly you have hundreds, thousands, tens of thousands of users and it's truly incredible, isn't users and it's truly incredible, isn't it? But if you combine those two things it?
But if you combine those two things , let's leave security for later, along with hypergrowth. Then you realize that you become a target. You are interesting to attackers from a very early stage. And when you combine both things, you get more than $3.8 billion that was stolen during 2022 alone.
And if you extend to previous years, you get more than $10 billion. So that's a lot. Uh, and why are the attackers so interested in this space? Uh, the reason is that basically every web3 application is a financial application, right? No matter what you do, whether you have NFTs, project tokens, protocol tokens, tokenized assets, stablecoins, whatever it is, it 's basically money or directly correlated with money.
And comparing it to the web2 alternative, where the attacker would have to steal your data and then sell it to someone, right? So it's just one more step. It's much easier, much more profitable to directly target web3 projects if you can. So, given this huge incentive, it's not really surprising that we see tons of different attackers and distinct types of attack groups in this space. Uh, it varies from groups supported by nation-states.
Lazarus is the most infamous in this space, obviously, but they are not alone. Uh, we also have cybercriminals entering the web3 space, and today we are seeing hybrid attacks where an attack group or an attacker reaches a victim or a target computer and then dynamically decides whether to deploy ransomware to extort that victim, or if they have crypto, directly steal their crypto assets. TRUE? Exact. So these are hybrid attacks that show us that those traditional attackers who grew up in web2 and traditional cyber exploits are now also venturing into crypto.
And obviously you have those opportunistic groups, a bunch of guys sitting in a bar saying "hey, those guys made a mistake, let's make money off it." And finally, you have your infiltrators. People you trusted, people you brought onto your team. They've been working with you for a while and then decide to betray you to find extra profit and drain your project. So, let's talk about your web3 project.
Start with your team. A couple of people who have an idea and start working on it. And they begin to build this amazing new app . And your application, your web3 project has different components. It has the web2 interface, the infrastructure, everything on the chain, your smart contract code , the financial model you 've created, obviously your wallet that stores assets and private keys, and some governance mechanism, usually a DAO or something else.
Then you have your attacker who is simultaneously trying to directly attack your project to drain it, take the money, or go after your team and from there move into your project and gain control over it. So, what can you do to stay safe on Web3? We consider the four pillars of web3 security and together they give you a comprehensive view of what is important to secure your web3 projects. Start with your team, the people. This is the first thing you have people.
This is the first thing you have . The trust you give them and the controls you have to ensure that trust, to make sure it is not abused. Then you have your infrastructure. That's all you rely on but don't build yourself. From there, you have your code and design.
And finally, you have incident preparedness because something is going to happen. Someone is going to try to get into your system or succeed in doing so. But you will experience something, and this is a feedback loop, right? After you've done all that, you go back and improve your controls, improve your infrastructure, improve your code. And this continues all the time.
So let's start with your team. Your team can be compromised in two main ways. The first thing we see is that the attacker tries to hack people, hack the engineers' computers , as happened in the Ronin bridge hack, where Lazarus was able to access an engineer's machine and from there move laterally to a production system and steal private keys. But we also see nation-states trying to insert their agents into DeFi and web3 projects. We have seen reports that both North Korea and Iran are doing something like this.
And the idea is that once you have your person infiltrated, you can do whatever you want, right? It's like having malware in a human operation, so to speak. So, first of all , you need to ask yourself who is really on your team. I know it 's sometimes difficult when you employ anonymous people as part of your project. But you need to find a mechanism you're comfortable with mechanism you're comfortable with : validating their references, validating their experience, making sure you don't have an internal threat.
That said, second, limit your radius of impact. Someone could be compromised, someone could be, uh, a dishonest employee could be, uh, a dishonest employee . Make sure you have basic permissions for each role. Make sure you manage access control for the administration, management, and deployment of smart contracts. This should only be granted to specific people, right?
So your head of business development shouldn't be able to deploy new code to the chain, right? Um, and finally to the chain, right? Um, and finally , for everything that's not on the chain, make sure you use MFA or ideally physical security keys ideally physical security keys , okay? For example, for your AWS environment. Um, and last but not least , who's in charge of security?
Who's your security officer? I know, I know; It takes a whole team, doesn't it know; It takes a whole team, doesn't it ? It's not a one- person job, but you do need someone to lead, someone who wakes up in the morning asking themselves: What could go wrong? What can I learn from that hack that happened yesterday and bring it home? Keep track of the actions.
The second thing is your infrastructure, everything you don't build yourself. The first thing here is your key management platform. The reason it's here and not on the next slide, where we talk about code, is that in almost all cases, unless it's a very extreme case, you won't want to build that yourself. It simply requires highly specialized expertise, and when you go to a key management provider , make sure they support both multi-step approvals and multi-factor authentication. So that you don't have just one person on a screen, with one click expanding, changing or transferring funds; Then you should go ahead and map all your external dependencies.
It will grow over time and that's okay. I mean , you don't want to reinvent the wheel. You want to build on things that are already created. That would include any external services, contracts, oracles, anything inside and outside the chain that you rely on as part of your security risk management . A great example of what happened to Badger DAO is that, basically happened to Badger DAO is that, basically , the attacker was able to compromise their Cloudflare API keys from their own front-end, stealing $120 million from users.
So make sure it's not you, or that the attacker isn't the only one who knows your system inside and out. Make sure you are the one who knows about it and can do something about it. Now let's move on to the code. We all love code. Um, many people are developers and there are two stages.
Okay, first the pitch, the MVP. Make sure you test yourself, test your code. There are many good security products that can scan your smart contract code , find known vulnerabilities and misconfigurations, and alert you about them. After that, define key invariants for your modules, your methods, and document your code. Document all of that for yourself first, so you know what's going to happen and what you expect your code and product to do.
Second, when you get an audit, and you should get one, the main pain point I hear from top-level auditors all the time is that people pay them a lot of money, but they also arrive unprepared. The result is that you're actually paying someone a lot of money to do a code review for you, right? Because an audit is just a time-limited security check. And if they spend all their time just reverse engineering your project and trying to understand what's going on instead of simply reading the documentation and comparing key environments with your code. So it's just throwing money away, right?
And it's a shame, because maybe you also waited about six months to get this audit six months to get this audit . So it will take time to achieve it. Alright . Hey, now that you've launched, you need to stay safe. First, establish a bug bounty program or partner with someone who can offer you that.
Make sure ethical hackers can communicate with you and notify you when they find a vulnerability in your code. After that, for the parts of your code that are open source, make sure to employ operational security. This means that if you find a vulnerability in your code, don't fix it on the open-source side before deploying it to the chain. Otherwise, you 're just giving the attacker a free guide, right?, on your product.
And unfortunately, we've seen people do it, and it's a very bad practice. Finally, make sure you are able to test your key environments. Ideally, on every confirmation, but at least on every release, to make sure you don't break your key assumptions. Finally, we have incident preparedness. Now, six months ago, when Binance experienced its incident, they responded very quickly.
Now, I'm not going to debate centralization versus decentralization, but I will highlight this. The initial loss was about $580 million. Using a very quick response, suspending all activity, they managed to reduce it to 100 million. That's almost an 85% decrease in the attacker's gains and Binance's loss . This is an incredibly good response in terms of cybersecurity and risk management.
The key here is that you can't respond so quickly if you're not prepared, if you haven't thought about this scenario beforehand. So, do you have an immediate response plan? And for those of you who, and there are many of us, right?, work globally. Hey, does it work if your co-signer is just a Discord user and it's 3:00 a.
m.? m. in your time zone? So, what do you do, right time zone? So, what do you do, right ?
You need to be able to respond quickly, regardless of the time. There are many different solutions for that. Uh, some involve trusted third parties and we can talk about that later. Second, you know your system better than anyone else. Make sure to document and identify all the ways your system can be attacked.
Uh, you can do it with your CISO when there are hundreds of people, but you can also do it with just three of you. It can take as little as 30 minutes. Sit down, take a pen and paper and document what you think could happen and, uh, what could go wrong. TRUE? Once you have that, it's the key to success and to being truly prepared for any incident that may arise.
Alright ? So, to sum it up, make sure you know and control your team. Okay, this is the first step. After that, be and think like your own attacker. Think about ways to exploit your own system, what could go wrong, and prepare for it.
Help your auditor when they come and help you, but don't help your attacker. Don't reveal secrets. Do not reveal vulnerabilities. And finally, do n't be surprised when you experience hypergrowth. It happens more often than you think, so be prepared for it.
That's all. Thank you all. Thank you for your time. Feel free to contact me, either in person, I'll be here a couple more days, or via Twitter, email, Telegram, whatever you need. And Fireblocks is holding a $25,000 bug bounty.
Hey, feel free to stop by our booth and find out more details about it. Thank you.
Automatic transcript — names and jargon may be misspelled.