Our susceptibility to a BadgerDAO-style hack

[lastmjs]

BadgerDAO has just had a front-end exploit for around $100 million.

I’m curious what our susceptibility to such an attack is. From what I’ve been able to gather, it was an XSS attack. The attacker used a compromised Cloudfare APi key to inject a script on the front-end that messes with the web3 API (talking with MetaMask or other wallets) and was able to ask for an approval to their own address. Looks like many people were fooled and approved the transaction.

But, at least these people were presented with a prompt asking if they wanted to approve the transaction. On the IC, no such prompt would be given. If the front-end we’re hacked, and the user were already logged in with Internet Identity or any identity using @dfinity/agent, it would be game over.

An XSS attack would have full power to act as the logged-in user. This is because the private key is stored in local storage, completely accessible to JavaScript running within that domain. I know this is very convenient, but it is also quite risky.

Are we okay with this security trade-off? I expect not many are aware of it.

Ethereum front-end app private keys are generally never stored in local storage, they’re stored separately from the domain of the web application. This adds an extra layer of protection against an XSS attack.

We don’t currently have that on the IC. Well, maybe Plug does this, since they are a browser extension. I’m not sure.

[mparikh]

Sources( to reduce cross posts)

This topic is talking about local storage :

Frontend security

AgentJS is storing information in localStorage, which makes it possible for the page to reload and still be authenticated. I am not aware of its inner workings, but it doesn’t seem very safe to do that. Chome Extensions XSS attacks; Supply chain attacks; all of these can inject javascript, get access to localStorage and then call all the canister methods they want. Correct me if I am wrong. If you are like “Ohh I don’t use chrome extensions like that”. Let me tell you, pretty much ALL of my ext…

@timo

Now, in some further detail, II actually tries to improve over wallets like MetaMask. Where those wallets store key material permanently on disk (at least encrypted), II doesn’t. II only creates session keys that are valid for 30 min. The permanent keys are inside the biometric sensor or Yubikey. That is an improvement because it shortens the attack window for certain attacks.

[lastmjs]

These are very good points, thank you. I like that they are only session keys. I hope we can somehow scope what the session keys do. For example, something like Stoic Wallet, when you log in with their identity solution I believe that session key has full access to the wallet. Perhaps this is an application-specific issue.

[inBlockit]

If the BadgerDao was hosted on the IC - the attacker would need to get access to the controller of that given canister and deploy update through consensus. Furthermore, if the canister was controlled by the DAO then any update to the frontend would need to be voted upon, which would make the attack impossible.

I think this is the foundation of IC that it is well protected against tampering with data on the chain, in case of BadgerDao - injecting code to the frontend.