Wietzwind: Here is a detailed breakdown of the XRPL.JS Hack 👀
A little bit of background after what has been discovered today: a breach in the xrpl.js Javascript SDK, and measures taken by @XRPLLabs and all @XamanWallet users safe.
Let me first put your mind at ease, if you're a @XamanWallet user: as mentioned earlier today, you're totally fine. You're unaffected. Xaman doesn't rely on xrpl.js, but instead uses xrpl-client and xrpl-accountlib. There are several extra layers we have added to our security model.
1. We use our own custom libs for this, xrpl-accountlib and xrpl-client: this means we separated the connectivity from the signing.
2. We don't auto-update dependencies
3. (Very important!) On top of the above, Xaman source code has an egress firewall in the code, for both iOS and Android, that prevents any used third party lib. from connecting out to non-whitelisted destination domains - this means that even if Xaman would have used xrpl.js (it doesn't) it would still protect users
4. At the trade off of the bus factor, package updates can only be released by me on a dedicated separate computer.
Most importantly: the sheer contept of Xaman protects users interacting with the ecosystem/third party tools/dApps (xApps), etc. EVEN if those third party tools/dApps (xApps), ... would be using a compromised version of xrpl.js (or another dependency), users would still not be at risk as long as @XamanWallet is safe. Your phone is your most personal and trusted device. People keep it close, people keep it clean. When Xaman signs, keys are kept inside Xaman, and cannot be exposed to the tools you are interacting with. Xaman is presenting you with the "single source of truth" when it comes to signing transactions.
Now let me explain what actually happened today:
Software relying on the compromised versions of xrpl.js exposed secret keys generated/entered by end users to third party compromise.
The xrpl.js package isn't the first, and won't be the last package in the crypto ecosystem to be the victim of such an attack: with billions at stake, libraries used by crypto wallets are prime targets.
Any software vendor claiming that "this kind of attack can never happen to them / their software" is lying. This can happen to the best of us. But we sure can do a bunch of things to try to prevent it.
So what is happening here? Almost all software users other software (that uses other software that uses other software, etc.). There's an entire "tree" of dependencies: libraries maintained by third parties, so other builders can continue building without having to reinvent the wheel.
If malicious code makes it into one of these packages many other packages use, nasty things can happen. The xrpl.js package is one of the packages many (most) Web/Browser/dApp/Wallet implementations rely on, as it makes it fairly easy to interact with the XRP Ledger, XRPL accounts, etc. - and most importantly: sign transactions.
A malicious actor managed to sneak code into the xrpl.js package that sent generated / imported keypairs to a third party server. There they could gather a long list of generated keypairs, wait till there was actual balance on the accounts, and empty them. It's likely this has already happened, or will still happen in the future.
If you have recently generated an account / keypair / secret with xrpl.js or a wallet/tool that relies on it, consider your account unsafe and please send your funds to a new account (hint: @XamanWallet at your service!)
So: what can package publishers do to prevent a package compromise like this?
1. Limit the amount of people who can publish to a production release that will become a public package
2. Scan code to be published before actually publishing
3. Keep a strict limit on the amount of contributors who can actually publish packages
4. (Personal opinion): don't use an automated pipeline for the actual publishing & use pattern scanning on your to be published source code
Of course the more restrictive one is with the above, the higher the "bus factor" - but I prefer the bus factor over the attack vectors: worst case attack vector = huge problem, worst case bus factor = no package updates.
What can builders to to prevent the above?
1. Don't auto update dependencies
2. Security scan dependencies
3. Use strict CORS/Connect/... limits to limit where packages can connect to (if borwser)
4. (If native code) Use egress filters to prevent connections to untrusted sourjces.
But in reality, for most developers: don't manage keys: it's hard. It's dangerous. Build on top of third party signing solutions who do the heavy lifting when it comes to key management, security & trust.
Source: https://x.com/WietseWind/status/1914818761179160742?s=19
