Let's Learn from the Odin.fun Hack - Preventing Attack Vectors

Developers
1

Ladies and Gentlemen,

Some bad news Odin.fun the very successful memecoin project that uses Bitcoin as the main medium of payment, which uses under the hood ICP’s excellent BTC infrastructure was hacked.

This post is not to criticize in any way Bob Bodily, and his team, it is mainly to explore ATTACK VECTORS against an ICP Backend, or smart contract so that we who also build on the IC make sure our software is secure.

One of the main cool features of Odin.fun is that people can use many logins to join Odin, it does not use the Internet Identity, it hides the IC backend to encourage user adoption.

So I ask all the Software Security folks, or professional developers in this forum not only to give an opinion on what could have gone wrong, but to focus on HOW WE WHO DEVELOP on the IC can prevent this kind of attack in the future. The IC advertises itself as super secure, and we must make sure that it stays this way especially when we deal with customer funds or assets.

A security audit costs a fortune, so instead of demanding one from every project, I ask instead that we ourselves give specific advice and best practices for developers to prevent this kind of hack where the user’s identity is taken over by a third party, and his assets are seized.

Here is my Gut-feeling advice based on what has happened, which may be wrong, but still I offer as general advice to secure an IC Canister:

  • The most secure authentication to an IC Smart Contract or Canister is the Internet Identity login, every other way requires a compromise. DFINITY has battle tested this login system.
  • Removing direct contact with the NNS Wallet functionality, to create a better UX is wonderful, but it opens a can of worms of possible new security issues that may hide inside the implementation of this novel approach.

@ielashi and folks who know this stuff, please give us developers, and founders some advice on how to prevent this from happening.

@bob11 I wish you the best man, this is in no way a criticism of what you and your team have accomplished, and I am glad your community is supporting you, experts are helping you, and I am sure you and Odin will overcome this.

Now dear IC Developing Community, lets discuss how we can prevent this from happening again. Throw your best ideas, let’s use real Human Intelligence.

Joseph Hurtado
Founder Satoshi Notes

P.S. For those interested on what happened here is some background information from Bob himself: https://x.com/BobBodily/status/1911930973064974598

4 Likes
2

I can’t help but to point out that this hack likely wouldn’t have taken place if we stick to the old (and correct!) way of dealing with ICP account IDs! The whole thing about ICRC-1 account id being user principal was a horrible mistake.

Principal by its original design was only used to represent identities, which are only visible to canisters or developers, not end users. Because principals are now publicly exposed by ICRC token ledgers and apps such as in Odin.fun, it facilitates this hack because the attacker can easily identify who to target. Had we stuck to using the old ICP account IDs, the hacker would need to either hack into users’ computers or Ordin’s canisters (i.e. subnet nodes), before they can obtain such information.

Sure, obscurity is not security. But mixing up sensitive information (i.e. identities) with public information (i.e. account ids) definitely facilitated this hack, and likely many more to come.

To fix this, we must first admit that ICRC-1 was a mistake, which was called out many times in threads like this one and this one. Until we are more honest about mistakes like this, hacks like this will keep happening!

2 Likes
3

https://x.com/kunsect7/status/1911754919595659313 Do you agree with what this article says?

5

Yes, the Canister was actually hacked, and tokens were stolen, follow the link I provided at the end of my post above.

6

Awesome :slight_smile: I’m sure it was an inside job but I live in hope.

1 Like
7

Bob’s not an inside job guy, he was just likely overstretched and operated on a thin budget. If the IC had actually funded successful projects instead of letting them operate on a shoe-string budget, they could have had proper audits and prevented this disaster.

Dfinity can’t have their cake and eat it. No ecosystem support = no ecosystem. Kinda sad that potentially promising projects like Odin, Bitfinity, Dmail and others are so let down in favour of insider rugs through the SNS. How can Dfinity support Boom Dao and not Odin. Joke.

1 Like
9

I don’t think Bob is a a scammer, but he may have cut corners on security. Here is the vulnerability that got patched: verify address · AstroxNetwork/ic-siwb@184c2ed · GitHub

It was a third-party library developed by Astro-X, they relied on. I don’t think Bob is smart enough to find this exploit. If he wanted to rug it would have been caused by his own code.

1 Like
10

He is literally a scammer and can sue me for defamation if he feels he has a case.

3 Likes
11

He was literally introduced to me as “backdoor bob”. That aside…

For someone who should be incredibly clued up on how blockchain works, it is remarkable how many times his business accounts get hacked. Note it is never his personal holdings, just his latest projects.

Just saying if someone is that clumsy, surely there would be other things that are attacked.

IC is unhackable if you do it right, why cant bob use a yubikey?

Maybe he is that guy that is struck by lightning in perpetuity, maybe he is just really good at making up stories and moving on to hyping his new best cool thing…

6 Likes
12

“Backdoor Bob” … wow, what a name. Dirty guy. Yes, there is a pattern. Whether reckless disregard or a determined exploit, perhaps it’s all the same in the end given the track record.

4 Likes
13

“Wearing a seat belt can be so bothersome. Instead, let’s talk about how we can all drive better.”

Users:

  1. Never ever ever ever put assets on a canister that isn’t open-sourced. Not your code, not your canister, not your asset.
  2. Don’t ever use a canister that hasn’t paid for the audit. If you do, you’ll be the one that ends up paying.

Devs:

  1. Unless your pockets are at least as deep as DFINITY’s, reconsider using RUST as it is hard to read and you’ll get significantly fewer eyeballs on it over the long run.
  2. Delegations are great for UX! But, Delegations are awful for security and generally don’t work for public services that have max eyes on them and are open for all to use without gatekeeping. Try to avoid building with delegations in mind. This hack was a delegation hack. If the users had needed to sign the transaction with the actual BTC key it would not have happened. There are not really good frameworks for this at the moment. Being able to mark certain functions as not valid for delegation would be an interesting start. Would it be annoying to have to reroute through II to when you want to actually move funds? Yes. Would it be more secure? Yes. Is there some kind of way make this not suck? Possibly.

giphy

5 Likes
14

It was facing a hard reality. The account IDs had false security. Both boundary nodes and execution nodes could see the principal of those transactions and there was no way to know that was kept secret. The choice was to leave a dirty little secret in that could one day be used to take advantage of someone or to open it up and accept the reality that if you want to do tokens without zk you are going to know the public key. If some knows the public key, you are better off with everyone knowing the public key.

This hack occurred because the component was not audited and did not have adequate tests. It had nothing to do with ICRC-1 or knowing someone’s public keys. Everyone knows Satoshi’s public key. Everyone knows Vitalik’s public key. If we can’t clear the hurdle of having secure public keys, what are we even here for?

4 Likes
15

I think the answer is audit everything. Non-Audited Code Is Bad Code

4 Likes
16

  1. Audits are ridiculously expensive, so this argument is mostly useless.

  2. If DFINITY will pay for them, sure, we would gladly do them.

  3. Rust is very performant, does things Motoko can not do, so guess what many, including our team uses Rust. Why? Motoko failed us, we had to rewrite our code.

  4. Open source? Why, who benefits, the next copy - paster? No thank you, unless we have solid funding we will not open source.

For small companies like mine, this is the reality, so the real useful thing is to encourage best practices, share dev knowledge, and yes do real post-mortems where we learn from the crash, or in this case the hack.

Can ICRC1 be fixed? Why not fix it then?

The boundary nodes are not that easy to hack, but now you just announced to the world that they would be a major target, how hard a target? How truthful is DFINITY when then say the IC is unhackable then?

Let’s keep the conversation useful and positive, but at the same time REALISTIC, one that leads to good outcomes, not just the BS demand to “do a security audit.” Which by the way, have also failed, here is some data regarding the limited effectiveness of the Security Audits:

Team Finance (2022): Hacked for $14.5 million through an audited function, with audits by Hacken, Coinspect, and CertiK.

Mango Markets (2022): Lost $112 million shortly after an audit by Neodyme, due to a price manipulation exploit.

WazirX (2024): Suffered a $234.9 million loss, likely after audits, given industry trends showing most hacked smart contracts were audited.

I am still waiting for the software developers to give real good practices and advice, and I thank @quinto who is the only one who has shared truly useful advice, thanks man!

Take care,

Joseph Hurtado
Founder Satoshi Notes… a Bitcoin app that uses the IC, so I truly care about this topic!

1 Like
17

Do you mind me asking why you’re building on the IC then (what do you or your users get out of your product being on the IC if they can’t verify the code)?

4 Likes
18

Also audits are only as good as the auditor. It’s another way of saying get more skilled/trusted (not necessarily the same thing) devs involved in the project.

Software built on the IC is hackable (you just need a dev to intentionally or accidentally introduce a backdoor). IC infrastructure is what is considered unhackable. I guess there’s a subtle difference.

2 Likes
19

We are building Satoshi Notes, a free note taking app that runs on your desktop, and allows you to publish online your notes for free, or for payment in Bitcoin.

We follow the safest path: Internet Identity and ckBTC explicitly, and we should release next month.

There is zero advantage to being open source for us at this moment.

2 Likes
20

Getting lost on the discussion of boundary nodes. What about them? Are they unreliable and leak secrets? What secrets? User’s private key? How?

21

FYI : It seems that you are just building something Mora already does.

22

Why would Bob rug his own platform when he was making so many fees? Lol