SecondFi Hack Update: 16.1M ADA Stolen, Recovery Timeline Explained

Okay, guys, we’ve got some updates around the SecondFi hack incident and there has now been an investigation to try and find out who is behind the attack and where the funds are actually going. So I’ve got all the details here for you guys. But first off, just a public service announcement. If you are seeing emails coming through attempting to help you and support you through this hack phase of SecondFi or Yoroi, you will see that they are phishing attempts.

They are scams. Do not click on any of the links. Don’t engage with them. They are all fake.

The SecondFi team are not communicating via emails. All the communications are being done via the X account and via their technical support. You can follow them at X.com slash SecondFi app links down below for you guys so you can ensure that you go into the right places. But you can get to the SecondFi website, SecondFi.io and the tools there that you can use are Checker.SecondFi and then the SecondFi app itself where you can download it.

And the SecondFi app itself. So if you have already that downloaded, follow the links in there to actually get the support and submit support tickets to to let them know that you’ve been hacked. But anyway, let’s go through the hack attempts here and what the initial investigation has found. So between the 21st and 23rd of June this year, SecondFi experienced that security incident with approximately 16.1 million ADA being withdrawn from various users’ wallets that equated to about 2.6 million USD and stolen from 374 wallets.

Now, this independent report investigation from Groom Lake, it’s an independent forensic investigation to try and work out where the money was going, looking into the code and everything else around it. But this is what some of the highlights from this. So the attacker is an external actor. Obviously, it’s someone that we may or may not know.

But the Groom Lake guys have determined that this may be and may have come out of the DPRK or North Korea and from the attacking hacker group Lazarus Group, which has close ties to the North Korean government. And the second attack here. So it wasn’t just one, there was two separate attacks. So the first one was initiated from the Lazarus Group.

But the second attack here, Groom Lake also identified activity by a second party attacker that appears to be based on current evidence to be separate from the primary operations and have affected a different set of wallets during the same window. No overlap of affected wallets has been identified to date. So a completely different attacker that once they saw probably what was happening with the wallets and what the Lazarus Group did, try and probed into the attack and then worked out they could steal funds themselves. Now, what caused the attack?

Now, I held back talking about anything about how the attack worked and how it happened until teams and everyone that’s working in this space could jump on and mitigate as much as possible and dampen its effects before talking about it. Now, this is a root cause. Root cause was a highly subtle flaw in how wallet software generates per transaction signatures in simple terms. A value that should have been derived from a secret information could, under certain conditions, be computed from public transaction data.

This could enable affected private key material to be derived from information visible on public blockchains. Now, I did have the information about this ages ago when the vulnerability just happened and a couple of people started looking into what was happening with these transactions. And Jonathan here, I believe he’s from No.Witness Labs. He posted up the the way that the signatures were derived on all the wallets and basically a breakdown of how it was done and where the vulnerability happened to be.

So essentially, when you’re writing a signature to confirm the transactions, you need a couple of parts. And one of the parts was completely omitted from this process, allowing anyone to actually just create it from that public data. Trying to find the part of the formula here that exposed that. Here we go.

So essentially, this part here was the key bit. So the part here, part K within this equation was omitted from the signing of the transactions. So you need R and R is made up of K and G and G is a public fixed point, which is put on chain, which the attackers could see. But that this R was generated without the secret, without the secret that should have been generated from the user’s wallet.

And without that, it meant that anyone that could see a public transaction with the G could use it in the R part of the formula to sign all the transactions. Hopefully that made sense. That’s why I said when any time you did a transaction on chain within a compromised wallet, it would have given them this variable here R because it didn’t have the secret. And because they could just use that same value over and over again to sign a transaction from your wallet.

That’s all they needed. They had all the information in public on chain itself to be able to liquidate your wallet. So that that’s what happened in this situation. Now, people did do a bit more digging and found out what library and where this actually came from.

And I believe this is correct of what and where this all came from. And it all came from a multi-chain wallet SDK that allowed Bitcoin, Ethereum and Cardano all to be wrapped into one single wallet. And I don’t think it’s this developer’s fault because this was an experimental library that was being created and didn’t get funding to be completed or audited or anything like that. And someone used this library to be brought into Emurgo’s code base.

But I’ll go into that a little bit in a little bit more detail. But this is where what I believe has happened in regards to how this vulnerability came into play. Now, Andrew Westberg went in a little bit deeper here around this this analysis. And I, I, I feel the pain that a lot of people have.

It’s easy just to go. It was North Korea. It was the DPRK. And just say that, you know, the big hackers of the world at the moment are doing this, and that is the root cause of this.

But let me just read out what Andrew just mentioned here. The bug originated in XDEFI/CTRL Wallet that later became SecondFi that later migrated Yoroi users over to it. The wallet is a cross-chain wallet that supported that with support for many blockchains. So that is an interesting comment there.

I didn’t see any links directly with CTRL Wallet. We did see in the news an announcement that CTRL Wallet was also shutting down. And it looks like this is potentially where this vulnerability, this exploit all came from. So whether it was directly from this being included into Yoroi, SecondFi, or it was the migration of CTRL Wallet, which had the same library in there as well, maybe they integrated that library on their side.

And then when updating to SecondFi, that’s where things happen. So I’m not entirely 100% sure of those particular details, but it seems like the exploit all came into when things were being included into the brand new wallet. Two million USD worth of funds definitely liquidated. But, you know, we’ll see what happens when the recovery process does start to happen.

Let’s go back to the original announcement from SecondFi themselves. So this cryptographic flaw was also visible in a copy of relevant code that had been published without authorization to a public GitHub repository. We are continuing to assess circumstances surrounding the publication and are cooperating with relevant authorities. So is that their code that was published online without authorization?

Because if that was the case, then that would make things really easy for anyone else to probe the SecondFi app to have access to it. If it was closed source, you wouldn’t be able to get in. Of course, you can still socially engineer your way in to a company, gain access that way and then find the flaws and vulnerabilities. But in this case, it looked like it was published online.

Hmm. Very interesting. OK, fixing and winding down SecondFi. The flaw has been patched.

We all know that at the moment. New wallets created with the correct software are not known to be affected by this issue. However, given the gravity of this event, previous announcement that we’ve made a difficult decision to wind down SecondFi and Yoroi Wallet. The asset recovery and migration, safe migration.

This is what you’re interested in here. Our current priority is to support affected users, assisting recovery efforts and enabling users to move their assets securely. Recovery tool. This is where we’re at the moment.

A secure recovery tool using zero knowledge proofs is being developed and that is still being worked on at the moment. Even Charles put his hat in the ring and deployed some code that uses ZK proofs to prove that you own a particular wallet before the or during the hack and then where it should go now. The portal is designed to allow users to initiate the process directly while limiting information required to do so. For example, putting up your keys.

You don’t want to do that. You want to sign something, use that ZK proof and then say that. Yeah, that is my wallet. I want my assets back.

OK, the tool is currently in testing and we’re engaging a specialist third party audits to review it before anticipated release in August. So August right now, time recording is the 25th. So we still have a bit of time to wait for this one here. So we we I don’t know if this is early August or late August, but either way, I’d want this audited multiple different times because we’re having assets returned to us.

And hopefully during that return, we don’t see another attack. We don’t see another hack. So it’s that that’s the main goal here. Safe migration.

In the meantime, we are preparing a wallet export functionality designed to allow users to migrate their assets to one of their choice. We anticipate this releasing early August. OK, so safe migration sometime in early August, hopefully in the next couple of weeks and then recovery tool by the end of August. So another hopefully this is all wrapped up within by the end of the month.

End of August. And that would mean this attack, this whole thing recovered by a two month period. Hopefully that’s that’s hopefully the best case scenario. Anyway, guys, like I said, make sure you don’t ever expose your private keys online.

Don’t listen to support help that may appear on X or in the YouTube comments, even they’re all scams. Don’t ever expose your private keys online. Don’t ever give anyone your private keys, et cetera, et cetera, because they are all trying to steal your assets as well. So be very careful and mindful of that.

All right, guys, that’s all I have for this particular update. Unfortunately, I can’t tell you that you will get your funds back tomorrow or anything like that, but hopefully we do see them back by the end of August. Fingers crossed. Make sure you keep up to date and follow along the SecondFi account to make sure you get up to date information from their team there.

Or just hit that subscribe like button down below and I’ll keep you guys up to date with what’s happening with the SecondFi updates as well. It’s it’s a lot to take in sometimes, but I’ll try and keep you guys up to date with all that YouTube memberships down below. Buy me coffee links. They’re a great way to support the channel.

Otherwise, just hit that thumbs up. Stay positive, guys. I’ll see you in the next video.