DAPPCON 2025: Defending self-custody - Lukas Schor

Transcript

[Applause] Yep. Uh good afternoon everyone. Um today I want to talk about uh probably the most impactful event uh that affected self custody this year uh which is the the hack on by bit. Um this is uh not a simple exploit. It was a very targeted attack by a nation state actor on on by bit and I think uh it's something where we should take the time uh together as an industry to reflect on what this means for us uh how we approach self custody uh what takeaways we can uh yeah take from that uh so I

want to spend all of the talk uh about that about the takeaways that we took and that the industry uh should also kind of internalize Um yeah, I'm sure most of you have uh followed uh this incident and are mostly aware of what happened. Uh but for those who are not, I just want to briefly give a summary. Um so uh the North Korean sponsored uh state actor, the Lazarus group, was able to compromise the safe wallet front end. Um and using that was able to deploy code that was very tailored to by bit which was using uh the safe wallet front end. And actually the the code that they deployed

there uh what it did is it's first it prevented one of the signers of the by bit multisync to sign at all. So completely blocked that for some reason. Uh and second all the other signers uh when they would use the safe wallet front end they would see the transaction they want to do uh but the front end would uh forward a different payload to the ledger devices. Um and this was used then in order to uh to trick the the signers of the multisig uh to to confirm this transaction and this transaction which was a malicious transaction upgraded the account. Uh so it did a delegate call. It uh upgraded the account to another singleton which is a

malicious smart contract which then allowed uh the attackers to take full control of that account. Um so yeah that's the the rough summary. The outcome is very unfortunate. Uh by bit lost 500,000 E uh during that process. Um and yeah it's it's been my view uh the most impactful event uh on self custody as mentioned. Um so let's go into uh the learnings there. Uh first one is secure self custody is a constant battle. Uh secure self-custody is not a solved problem and I don't think it will be ever a completely solved problem.

That's the thing with security. uh there is no perfect security. Uh you can just maximize as much as possible harden different systems. Uh but perfect security is a myth. Uh but that means that uh securing self- custody is an ongoing process. Um especially as tactics of attackers change as the environment changes as also the industry the tooling that we use uh the the stacks that we deploy is is changing. Uh so it's something that we cannot as an industry stand still. Uh we need to constantly evolve uh respond to tactics, build up new defense systems. Um that's one thing. It's constant but it's also an unfair battle because um yeah when we

look at custody uh in in custodial solutions um the attackers uh need to compromise just one entity. That's the the thing that we don't like about intermediaries about custodians that they become this central point of failure. Uh but then the investments into security uh to protect against these attacks they're socialized across all users. Uh in self-custody the the protections the investments into security need to be tailored for each user. uh and that's uh is is just an uphill battle because on the other hand you have uh actors like the Lazarus group who are willing and able to invest

millions of dollars just to hack one user because if it's a big enough user the investment actually is worth it. Um, so that's just means that uh um the users uh themselves need to actually be fighting this battle against potentially much bigger entities and this creates a a very imbalanced uh battlefield. Um yeah, but that also means actually that we as an industry should uh should give the tools to the users in order to fight this battle. Uh I think that is clear that different users depending on uh the use cases they need different defensive

tooling and uh especially uh users at at the scale of bipate they just need much more hardened security and much more uh tooling in order to to stand this battle. Takeaway number two uh even strong onchain security can be broken through offchain trust assumptions. Um as an industry we've invested in a lot into onchain security into audits, simulations, formal verifications like we've really done a lot there. Um but users are not interacting with Solidity, they're interacting with JavaScript, interacting with um like offchain components, with wallets that they download from the app store, uh with a lot of things that are have on top of

the onchain security. And that means that uh we create an extended uh transaction supply chain uh that depends on a lot of components on libraries on relayers on indexers a lot of off-chain infrastructure. We're kind of building this uh web two stack that sits on top of the web three accounts and uh that is uh needs to have be dealt with in the same way that web two security needs to be dealt with and it needs different approaches than uh the onchain security.

And there um the key thing is that the longer this transaction supply chain gets, the more complex it gets, the harder it is to ensure that this chain doesn't break at any point, that there's no weak link in it. And um the the real challenge there is that when uh such a chain breaks, it's quite easy to point where where is the weak link. Uh but the hard part is at any point of time before something breaks to make sure that each of the links are is hardened maximally and the more complex we get uh building these web two solutions up on top of the web three stack the harder this gets for us as an industry.

So for takeaway number three and that's actually for me a silver lining here is that client diversity differentiates self custody from uh from custodians because um after the the hack the safe team right away took down uh the front end as it investigated and uh remediated hardened the security of the front end um and that required the the front end during that times of uncertainty and the the work that had to be done it it it wasn't possible to keep it uh online and in any case in traditional finance when the front end is down even just for maintenance users cannot access their their assets they're completely locked

out I think here was good to see that during that time there were projects from the ecosystem stepping up uh offering alternatives um u products that have been existing before uh being able to help users uh do transaction during that time. Uh there's uh mechanisms like a CLI uh that they can run locally. There's like a decentralized front end on IPFS uh the eternal safe. Um you can run the stack uh on your own which also a lot of users actually do and uh which also I think should be uh supported and that that should get easier. Um that but that meant that during that time uh in safe custody that there's no need for

for bank run because someone else um kind of uh yeah someone else withdrawing funds from their accounts doesn't affect anyone else and that that I think showed the power uh of self custody in the end. Uh but it also showed challenges where um even though there are a lot of solutions out there where you can interact with uh with your safe account um like some of those uh products they also dependent on uh the transaction queue uh which was also taken down during that time. uh some some projects have the their own transaction cues.

They have some redundancy. Uh but that also means that we need to think client diversity through the entire stack and we cannot just limit it to to the front end and we need to make sure that we can decentralize as many parts of the stack as possible and I think this is relevant uh generally for for self- custody for different D5 protocols as well uh that they have access points beyond the canonical interface. Um it also is very relevant uh in the context of uh smart accounts uh and 7702 where uh potentially like very custom implementations may not have this redundancy and then they become suddenly dependent on the availability of one

specific front end. Um that's something where further investments is needed and uh especially on the safe side. I think there's uh yeah certain things we we took from that learnings where where we need to make sure that there's redundancy across the stack. Takeaway number four uh we need better tools to educate and and education to enable users uh to verify transactions. Um yeah, we we often say don't trust verify and u really this ability to as a user of self custodial solutions to uh be really the last line of defense and be able to verify uh the

transaction down to like the payload the methods that are being called like this is this is really a key thing of our industry but it's also easier said than done and I think that's uh something where we need also to invest further uh where in this case by bit verified they they verified what they saw on the front end was what they intended to do. Uh but that's not the the full verification that's needed to really have this last line of defense because the front end told a lie. The ledger devices told the truth and they relied on on the front end there. That's something where education is needed, but also better toolings in order to make it actually feasible for people to to verify the transactions that they sign.

And there's already a lot of initiatives at the back of uh the BBIT incident that uh is working towards that uh both in the safe wallet uh front end where there's better ways to uh guide users to tooling and better ways to to verify transactions. Uh but also different ecosystem players. Ledger is pushing for clear signing also together with with MetaMask. um the safe utils uh tool from from open zeppelin and also from like an Ethereum cord um like community member who wrote the the initial uh script like these things are needed but they we we need to do more there because it's uh uh yeah it's still it's still too difficult to to verify

transactions even with with these toolings today and like we need to make sure that people can really have human readable instructions that they uh that they confirm on a trusted device or trusted uh wallet and that needs yeah we we need to do more uh takeaway number five we don't just need stronger security but we need layered security and to explain that um right now essentially we have two layers two highle layers of security one is the security of the transaction supply chain uh that goes from like the the front end that you use the RBC, the um the the SDKs, uh npm packages, like everything, every line of code, every

dependency in there, um that uh kind of is is part of actually crafting or turning the user intent into into the actual payload. Um but the other layer is the transaction verification. And that's really this last line of defense I I talked about where the user can verify on a trusted hardware or or software the the the payloads that that they're signing. And while I think we need to harden both of these layers, I don't think this will be enough. Um I think we need additional layers of security that actually can ensure that even if those assumptions break that the outcome is not catastrophic. I think

that's uh yeah that's can can be achieved in in in different ways. Um like uh this can be on a on an application on a protocol level where it could be like hooks in the context of a modular amm. It could be assertions that are enforced by a sequencer. uh different ways that we could actually have execution guarantees on transactions. Uh that even if the the user uh signs something wrong, kind of these fail safes catch uh the the bad outcome. So they can at least reduce the harm. And here just a call also to the community especially people building on

safe uh to explore guards because they can really enable that. guards. They the essentially a plug-in that does uh pre and post transaction checks on each transaction and that m that enables things like enforceable policies whether they're provided by an application, whether they're provided or set as custom policies by the users. Uh but there could be policies like my safe can only transfer this amount of uh of assets to this specific other safe or or something like that that then every transaction no matter what you sign needs to fulfill this check and otherwise reverts. Um guards also can enable things like co-signers where

there's external parties maybe a decentralized network uh having uh yeah the right to uh check transactions and either give a thumbs up or thumbs down and uh therefore allowing more uh more of these fail saves to live whether they're onchain whether they're offchain uh to to provide these execution guarantees. uh also resource locks that's also a topic that's uh becoming more popular generally that's uh in a way allows like additional escrow logic uh before assets leave an account uh but like the there's different ways how it can be implemented in safe uh there's actually projects already doing that in

different ways um hyper native blockade they have such cosigners um yeah Josera has their trap system like the zodia zodiac uh team has built this already way in the past, but like we really need to push on that front because this can build up a third pillar of security uh which makes sure that we have fail safes in place in in in case the other assumptions break. Just one one simple thing that the safe team has been uh building now is a delegate call guard which essentially would just limit to what singleton's uh uh how can be upgraded to a curated set and this would have closed at least this specific attack vector that by bit uh

experience uh but the design space is much broader than that and like it really allows to cover many different attack vectors in in different ways. Now to the last one and need a sip. So final takeaway for for today self custody needs to become our cipher punk. Again I think there's always this tension in whatever we build between on the one side uh simplicity UX mainstream adoption and on the other side the the values of cipher punk which is censorship resistance privacy and security. And I think that especially in recent years where we as an industry

wanted to push for more mass adoption, we wanted to onboard more users. Uh this can easily dilute the the very values of what we're building. Um and that's something where we need to be mindful at least of tradeoffs but also actively uh push against and make sure that we we retain these important values uh of our ecosystem. That's something at least at at SAFE we want to double down on that. uh through a new initiative which is safe research uh which really uh aims to solve the hard problems of self-custody around censorship resistance, security and privacy. Uh these will take a lot of uh lot of work. They're not easy

problems. Uh but that's important that we continue to to invest into that part as well. And like there's a lot of problems. It's just subset of of things that we need to uh cover there. And yeah, for everyone that's part of Safecon tomorrow, which I highly recommend. I think it's on the fifth floor here at the Dubcon uh venue, uh I would suggest uh you come by the talk uh at 2 p.m. uh from Richard who's actually leading this initiative where he can tell you more about what that actually means and uh how that uh yeah, how that will look like.

So I see time is up but um maybe to end with um yeah uh there's a lot of people in this room that are fighting this this exact battle and I know that uh it's often very hard uh because it's it feels very much like an uphill battle like there's a constant new threat uh threat actors that we need to consider. there's uh yeah, it feels like a never- ending uh kind of thing because we we've been building for a long time. We've been hardening security across the board until we see a lot of uh hacks and exploits uh on on a on a monthly basis.

Uh and I just want to thank everyone that's that's fighting this fight together with with safe. Um I think it's especially also in in today's world where we see um financial censorship, we see data breaches um of of centralized uh parties, we see even intermediaries u sponsoring military parades. Um like I think it's it's it might be the the most important uh fight that we're uh we're doing. And so I think it's uh yeah crucial that we keep at it. we we don't give up and we really uh retain uh the passion for self- custody and we're uh yeah also the the values of uh of kind

of our industry and don't lose that. Uh yeah, that's it. Thank you very much. We've got time for one question. Okay, so who's got the best question? Well, if not, oh, best question right here. Do you have any practical tips for teams that want to avoid such supply chain attacks?

Um I mean there's like the the boring answer which is like u there's certain standardizations especially in in web two SOC2 compliance MDM files like there's have like the the best practices just in web two there's a lot of uh literature uh training that that you can do like that that needs to become a must have uh for for the industry um that's that's one thing uh but maybe the more practical uh just assume at any point of time that there's a target on your back and that's feels like paranoid and uh but it it really is important because like we uh we need to assume that it is and we need

to operate always under the assumption that someone at this very moment tries to infiltrate our systems, tries to infiltrate the the team uh be hired uh in in a position uh as like um somehow trying to get to our users because they're actually not trying to get to to us when we're working in South Ki but to our users and we need to make sure we're operating with the interest to to protect the users uh there and uh that needs a little bit of paranoia and like always uh thinking twice about everything we