XDRIP and XColdPro featured image: three glass panes each holding a key with a line leading outside, headline "Who else can sign?" and a timeline from the Mercado Bitcoin drain on 2 November to Keplr social-login wallets on 6 November and the Swarm Desktop release on 9 November
XColdPro

Who Else Can Sign? Three Wallets, Three Key Exposures in November

A social-login wallet, a desktop node wallet and an exchange's hot wallets were all exposed in ten days. Each failed where a key, or the power to use it, sat outside the owner's control.

6 min read

Every wallet, whatever it is called, comes down to one question: where does the signing key live, and who else can reach it? In the first ten days of November three very different setups gave three different answers, and all three ended with funds moving that their owners did not move. A social-login wallet, a desktop node wallet and an exchange's hot wallets have little in common on the surface. Underneath, each failure happened at the same place: the point where a key, or the power to use it, sat somewhere the owner did not fully control.

A key behind a Google or Apple sign-in

On 6 and 7 November, some Keplr users who had created their wallet with a Google or Apple account saw transactions they had not made. Keplr relies on Web3Auth for that sign-in. According to The Hacker News, Web3Auth said a security issue in its own infrastructure affected certain wallets it provides inside the Keplr app, and Keplr described the result as a "private key breach" for some of those users. Neither company has said how the flaw worked.

Web3Auth then used the same route to move funds out of at-risk wallets before the attacker reached them. Bitquery counted at least $6.01 million leaving more than 44,000 Keplr social-login wallets for addresses Web3Auth lists as its recovery wallets; it first reported those transfers as theft and later corrected its analysis, noting that it cannot check who controls the recovery wallets. No total for the actual theft has come from either company. Keplr said wallets created with a recovery phrase or a hardware wallet were not affected, paused the Google and Apple login, and told affected users to move unstaked funds to an account backed by a recovery phrase or a hardware wallet.

The rescue is the detail worth thinking about. A provider that can move funds out of thousands of wallets to protect them is, by definition, part of the signing path for those wallets. That can be a reasonable design for small balances and first-time users. It is not the same thing as self-custody, and the difference only becomes visible on a bad day.

A key and its password in the same folder

On 9 November attackers used Ethersphere's own release automation to publish malicious versions of bee-js 13.3.0 and Swarm Desktop 0.56.2, tools for the Swarm decentralized storage network. In The Hacker News' account, based on analyses by Socket and SafeDep, the code looked for two files in Swarm Desktop's data folder: the node's encrypted Ethereum keystore and the configuration file. The keystore was encrypted, but the password that unlocks it was stored in plain text in that configuration file. With both, an attacker can move the node wallet's tokens, chequebook funds and stake.

The malicious bee-js release was the latest version on npm for about 75 minutes; Swarm Desktop 0.56.2 was online for about eight and a half hours, and its auto-updater could offer it to Windows and Apple Silicon machines. The macOS build was signed and notarized, and the npm package carried valid provenance, because both were produced by the project's real workflows with stolen CI credentials. No theft of funds had been reported at the time of writing. The maintainers released a clean 0.56.3 and now require approval before signing jobs run.

Encryption at rest did not help here, because the secret that undoes it lived next to it, on a machine that was online and updating itself.

A signing path, not a contract bug

On 2 November, Brazilian exchange Mercado Bitcoin had its hot wallets drained across ten chains. The exchange put the loss at around $38 million and said it would cover it, with about $11 million frozen with the help of Tether, Circle and Chainalysis, as CoinDesk reported. In its analysis, Hypernative describes every outflow as a plain, valid signed transfer from the exchange's own wallets, with no malicious contract and no protocol exploit. Funds left independently keyed wallets on Bitcoin, Ethereum, Solana, Stellar, Tron and EVM chains within a tight window, which points at the exchange's signing infrastructure rather than at one leaked key. How the attacker obtained that access is not yet known.

Exchange customers did not hold these keys at all, and Mercado Bitcoin's pledge means they should not lose funds. The pattern still matters for anyone who signs: when an attacker controls the system that produces signatures, every signature is valid and every transfer looks legitimate.

Three questions for any wallet

None of these incidents is a reason to abandon convenient wallets or online services. Each is a reason to know which model you are using and to size balances to it. From this month we take three questions:

  1. Who else can move these funds? If a login provider, a service or an operator can sign, recover or sweep, the wallet is shared custody, whatever the label says. That is a fair trade for small amounts, not for long-term holdings.
  2. Is the key ever next to what unlocks it? An encrypted key stored beside its password, on a machine that installs updates and packages, is protected only as long as that machine is.
  3. Is signing separated from the internet? Valid signatures produced by a compromised online system cannot be told apart from legitimate ones. The strongest protection is a signing step that an online system cannot reach on its own.

Our view

As XDRIP Digital Management LLC, we build XColdPro, an air-gapped cold storage security platform that turns a computer the user already owns into an offline signing environment. We designed it so that keys are created and used on a machine that stays disconnected, and so that no login provider, update channel or online service sits in the signing path. That does not make every risk disappear: the owner still chooses the machine, keeps the backup and decides what to sign.

This month's incidents each moved funds through a path the owner did not control. Our answer is to keep that path as short as possible: one key, one offline machine, one person who decides.

Sources

Share this article

Related Posts