Defunding North Korea - Onchain OpSec 101

Transcript

Hello [snorts] everyone. I'm uh Elliot Freriedman and I'm the the founder of the uh Clei wallet which is a a wallet for uh high netw worth individuals with very high security requirements. Um today I'll be talking about I'm also a CL 911 uh contributor. Uh today I'm going to be talking about onchain operational security and uh how we can make sure to keep our funds safe. [snorts] I guess this is my slide.

Okay, there we go. Okay, so just an overview of today's talk. We are first going to go over how funds get stolen. Uh what are the most common methods that this happens? Then we're going to look at how do we keep our funds safe. After we look evaluate that, we're going to go into the operational security uh frameworks that we can use to protect ourselves when we're signing transactions. and then we're going to have a conclusion. Okay, so for retail users uh in crypto, the number one way that funds get stolen is through pig butchering scams. And these are longunning social deception consers are tricked into creating a relationship

with a fake person and then that person asks them to make some sort of investment in a crypto platform or project that is not real. Then and so this is this is primarily uh this is all it happens because people want to believe that uh whatever these con artists are telling them. Then we have fishing and this is not to be confused with uh fishing >> uh for actual fish. Uh and what what happens here is there could be a fake website where um the user is asked to sign a transaction that just drains their wallet or in more pernicious cases there are uh ice fishing where the front

end will collect signatures approval signatures and then they will the attackers will store these signatures up and then after the attackers have enough funds to steal they'll send all all the approval transactions on chain at the same time and steal everyone's money which is very very scary. Um and the third method is address poisoning. So this is a a method that has a very very low success rate and how this works is it sends uh attackers use large scale GPU farms to create addresses that look very similar to the user's actual address. They send a test a transaction to that address and now their fake address appears in the actual user's history and then the user goes and

copies and pastes things and they lose a bunch of money and attackers here only have to have a very low success rate and they can be wildly profitable. Now for institutions, so these can be Dows, these can be companies, these can be startups. Anyone who's doing something on chain, the primary way that these uh companies lose money is through spear fishing, which are targeted campaigns directed at employees and key infrastructure. So, a really good example of this was the bybit hack earlier this year, which exploited um the fact that a developer downloaded something that they should not have and they use that to escalate privileges and

and deploy some malicious payload. And another example of this one is uh the Ledger uh connect kit compromise where the LedgerJS package was uh compromised by gaining access to a former Ledger engineer's computer. uh using that to update the the Ledger.js uh package and uh and then you know that that propagated out through Wallet Connect and many other packages in the ecosystem and led to $700,000 going missing and again we have uh address poisoning here and there's also supply chain attacks. So we saw also Shy Hulu earlier this year which was a

replicating uh malware in npm. Um, okay. So now the question is we have all these different types of attacks. How do we defend ourselves from them? And my thesis is the the the biggest operational security mistakes are behavioral and they're not easily solved with code because usually uh when these mistakes happen and this money gets stolen there's a mismatch between the user's intent what they want they think they're signing and uh what they are actually signing. So I'm going to be focusing on how we can change our behaviors to uh not lose money.

So, how do we upgrade our operational security? The number one way that you can stay safe and avoid attacks that are targeted at you specifically or your organization is to maintain privacy. If an attacker knows that you have a certain amount of funds, then you are much more likely to be the target um of of of a campaign that is specifically going after you. And yes, publicly displaying crypto or showing addresses. Um, this this is going to make you a very prime target for for exploitation.

So, you know, if you have an ENS, make sure it's not on cold storage or a Treasury Ops multi-IG. Um, and then for Yes. Uh the the number two uh the number two way that funds go missing is uh blind signing. Like everyone's doing this. Uh you you go to a your favorite DeFi protocol, you go to Uniswap. You're on the front end and they say, "Hey, you're going to go swap token A for token B and you say, "Okay, that's great. I want to go swap my tokens." And then you see a thousand bytes of call data on the screen if you don't have if you have blind signing turned off. And what does everyone do?

Looks good to me. Okay, ship it. Um, and I guess I think that if there's one thing you take away from this presentation, uh, if you stop blind signing, you are going to lose or you're going to be at much lower risk of losing funds because most people are not doing the hard work of verifying that, hey, what we think we're signing is uh is actually what we're signing. Okay. Then wallet notifications. So adding a layer of security that a layer that basically notifies you when transactions are sent from a wallet you control. It's very helpful. It it doesn't stop all of the attacks um but it can let you know in time if something bad does happen.

And then okay separate signing infrastructure. This is this is really really important. So Pablo the founder of OPSSE he gave a talk earlier in DSS where he said basically everyone on a long enough time scale is going to get compromised by threat actors. So if you think if you believe this which Pablo is a a very very credible source on this um you basically have to separate your infrastructure out for the machines you sign on and the machines you do work and interact with the world on. Um because if you're just randomly clicking into links, maybe you get a zero day. You download a PDF, you open it up and now

your computer's compromised. So definitely uh having a separate signing laptop is or a separate uh computer to sign transactions on is very important. [clears throat] Address books are they can they can they could have stopped anyway. So every single one of these things here could have stopped a lot of methods uh of attacks that we see because if you are sending a transaction to an address that you don't know and you've never interacted with before and you do not bother verifying who this person is that or who this contract is, you are significantly increasing the likelihood that something is going to go wrong. Uh for 2FA, this is this is much more for web 2 security. And if you have

exchange accounts, you want to make sure you lock them down and use a different email and different phone number than you use for the rest of your your um financial life. Okay. Token approvals. If you have outstanding token approvals, you you you really shouldn't. Uh, unless I don't know, maybe maybe you're signing transactions so often that it doesn't make sense to revoke because okay, you're always swapping or you're moving between different lending markets. Okay, I get that. But if that's not you, you you probably should not be um doing this transaction policies. So for enterprise um custody solutions, you are able to set policies of who can spend funds

and when when can when funds can be moved and if you have the ability to do this, I would highly recommend you do this. But even if you're not on some enterprise platform like Fireblocks, you can have you can implement transaction policies that are behavioral. So, you can say, "Hey, I'm never going to sign a transaction while I am intoxicated." And that would be probably a pretty good rule. Uh, or I'm never going to sign a transaction when I am uh really under stress or when I'm low on sleep because those are times when mistakes are much more likely to occur. Um, transaction simulation, you should always be doing this uh basically of transactions of any size. And fishing training, this can be

good. Um but again if you separated your your signing infrastructure that is uh that is good as well. One second here. And finally um you need to avoid rushing when signing transactions. uh if you rush and this is attackers use this they they create urgency a false sense of urgency and now once you feel oh my god I need to sign this transaction and you're stressed out your prefrontal cortex will uh be less active and so you're you will be less able to critically think about the transaction

that you are now signing okay for retail a very specific uh upgrade that these uh users can take is to have browser extensions like uh Kerarus or Pocket Universe which actually review the transaction call data on their behalf and run it through machine learning models to say whether or not the transaction looks suspicious. And so if you can have someone or basically a piece of software review the transaction on your behalf um that's a huge win and it can find find issues in your transaction for you. For multi-IGs these are great for more complicated

setups and time locks. These are good for for safe for setups where you want to prioritize security above all else. Okay, institutions. [clears throat] So the the main way for institutions I think to prepare and create secure and not not lose money to all sorts of fishing scams or targeted campaigns is to create runbooks for many different situations.

So, if you're signing something, you should be verifying a request for a transaction across multiple different channels. It should not just be Slack. It should be Discord. It should be a message on Telegram. It should be a message on Signal. And a really, really key thing that I don't think we've seen a lot of yet, but I do expect to increase quite a bit in the coming years, is kidnapping of executives at crypto companies. And so I think that it is very very important to have kidnapping and duress protocols so that if your organization is targeted and something happens, you have a plan in place and you can, you know, make sure that uh all of every

that everyone is stays safe in the process. Um, and I I'm not going to go too much into creating runbooks for this, but I think it's a it's a very interesting very interesting uh area of yes of security. Um and then yes hardening company computers many c many crypto companies don't take web 2 security seriously enough. So [clears throat] having EDR software anti virus tools this is just kind of table stakes in web 2. But somehow in crypto companies we think like no this doesn't apply to us but this is uh this is actually really really important.

Okay. So security engineering what kinds of frameworks can we use to prioritize changes that are likely to lead to good security outcomes in our organizations and uh in our everyday uh onchain activities. So this is a this is a graphic of the security stack and this is how I like to conceptualize writing secure smart contracts. At the bottom of the pyramid we have the cheapest ways to find bugs. These are our unit tests, integration tests, static analysis, higher higher cost ways to find bugs, code reviews, formal verification, symbolic tests, higher level audits and

very high as bug bounties. So, we want to be always using the cheapest methods to find bugs first. And I think that we can apply a similar way of thinking to onchain operational security as we apply to engineering for smart contracts. And here we have a graphic of how we can think about security of of custody solutions um with with a similar with a similar lens which is to say at the low what are the cheapest things that we can do to stay safe and these are the lowest lowest effort highest highest impact and

then as we go up it c it's more and more effort for diminishing returns. So on the low end, you know, we talked about signing rules, signing infrastructure separation. [clears throat] We can look at uh, you know, making sure that token approvals are not outstanding and having hardware wallets as well as, you know, address books. We go up another layer. Okay, now we have simulations and making sure that we're on the right web page. And then we go higher in the stack and okay, we have time locks, we have multi-IGs and then you know very very high cost is your wallet's been compromised. Okay,

[clears throat] we're going to do an MEV rescue, right? We need to try to frontr run an attacker. And that's uh that's not a good place to be. But it is possible if you contact CL 911 or uh and send transactions through flashbots. So in review, what are the common themes between smart contract engineering [clears throat] and uh and operational security engineering for making sure funds stay safe? Um as as low in the pyramid as you can go and invest in items at the bottom of the stack, you should because that is the cheapest way to keep yourself safe. And a theme through both of these um through

both of these fields is the more eyes that you have on your code, the more eyes that you have on your transactions, the less likely you are to uh lose money to some mistake. And the final the final theme I believe is is a Swiss cheese approach, which is that you say, "Hey, we're going to follow a defense and depth strategy. We're not going to say we have just one thing that we do and that's the end all beall. We're going to have multiple layers at every single step to make sure that we're not going to be losing um funds.

And so some some closing thoughts here. We have um [clears throat] we have people in a race. And the way that I like to see this is there's insecurity. You don't have to be perfect. You just have to be a harder target than the next guy. Um, if you're twice as hard to hack as a competitor, that's a tangible advantage to your business because then your risk of ruin is a lot lower. And security failures, they they might look simple on the surface. We might just say, okay, they just signed some bad transaction and they lost all their money. But once you dig deeper and you ask more in-depth questions about the failures, you see that things are not that simple.

and that when funds go missing, it wasn't they just signed the transaction that lost all the funds. It was all the things that they didn't do to keep themselves safe. And all the questions that they failed to ask and one type of question or one type of method that could catch a certain type of attack may not catch another. Here are some further uh readings and resources. And um thank you all for for coming out to my talk. Stay in touch.