BTCPay Server : l’arrêt des serveurs demandé après le vidage de hot wallets, sans bilan ni faille nommée

BTCPay Server, le logiciel libre et auto-hébergé d’encaissement en bitcoin, a demandé dimanche 1er novembre à tous ceux qui font tourner une instance de l’arrêter avec la commande ./btcpay-down.sh, après des signalements d’attaquants qui vidaient les hot wallets de serveurs de commerçants. Lundi, le projet a dit avoir identifié un vecteur d’attaque visant la version 2.4.1 et les précédentes, et a pressé les exploitants de passer à la 2.4.7, selon Cointelegraph. Personne n’a publié de montant des pertes, de nombre de serveurs touchés ni d’explication sur la façon dont les attaquants sont entrés.

Ce que BTCPay Server a demandé aux exploitants

1. Arrêter le serveur. BTCPay a publié ce message sur X vers 22 h 25 UTC dimanche, selon Bitcoin.com News : « Si vous faites tourner une instance, merci de l’arrêter (./btcpay-down.sh) jusqu’à la fin de notre enquête. » Cette demande ne citait aucune version et visait donc tous les exploitants.
2. Passer à la 2.4.7, dernière version publiée au moment où nous écrivons. Cette seconde demande est arrivée lundi, d’après Cointelegraph, dans un message de BTCPay consacré au vecteur d’attaque.
3. Signaler tout vol. Selon Cointelegraph, les utilisateurs touchés sont invités à transmettre informations et journaux à l’équipe de sécurité du projet, à l’adresse [email protected] d’après TokenPost.

BTCPay n’a pas expliqué comment ces deux demandes s’articulent. Cointelegraph rapporte l’alerte d’arrêt puis l’appel à la mise à jour sans dire que l’une remplace l’autre, et nous n’avons trouvé aucun feu vert sur le blog de BTCPay ni sur ses pages GitHub. Le piège se loge dans la mise à jour elle-même : le script de mise à jour des installations Docker, btcpay-update.sh, se termine en relançant la pile. Un serveur arrêté puis mis à jour de cette façon tourne donc de nouveau avant que le projet ait déclaré son enquête terminée. Dans tout ce que nous avons pu lire, BTCPay n’a pas dit à quel moment un serveur arrêté peut repartir, ni si la mise à jour doit attendre ce moment.

Un serveur arrêté n’encaisse d’ailleurs plus aucun paiement, puisque btcpay-down.sh arrête et supprime les conteneurs de la pile. Pour une boutique, la décision met donc d’un côté des ventes perdues, de l’autre le contenu d’un hot wallet. La commande elle-même relève du déploiement Docker. Les exploitants qui ont une autre installation étaient visés par la même demande, mais doivent arrêter le service à leur manière.

Ce qu’a dit le fondateur sur l’attaque des hot wallets BTCPay

Environ deux heures après l’alerte, le fondateur Nicolas Dorier a publié les premiers éléments. Les signalements « semblent concerner des versions de BTCPay Server antérieures à la 2.4.2 », a-t-il écrit, d’après CoinDesk, et les serveurs publics du projet, sous 2.4.7, « n’ont pas été attaqués ». blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">Il a aussi indiqué que l’attaquant s’était connecté en administrateur sur les serveurs touchés, et que l’équipe ignorait encore comment il avait obtenu cet accès.

Les lecteurs verront deux formulations pour les versions. « Antérieures à la 2.4.2 » et « 2.4.1 ou plus ancienne » désignent les mêmes publications : l’écart ne tient qu’aux mots. Le changement qui compte va du « semblent concerner » de Dorier au vecteur d’attaque annoncé lundi, même si aucune description technique n’en a été publiée.

Aucune des deux déclarations ne couvre le milieu de la fourchette. « Nous n’avons reçu aucun signalement crédible de vidage de hot wallet pour les utilisateurs de la dernière version 2.4.7 », a écrit BTCPay. Rien de ce que nous avons lu n’en dit autant des versions 2.4.2 à 2.4.6, et CoinDesk a relevé que Dorier n’a pas affirmé que les versions récentes étaient sûres.

Une seule entreprise est nommée. Bitcoin.com News écrit que des sociétés dont Coincards ont mis leurs installations hors ligne après l’alerte. Le média ne rapporte aucune perte chez Coincards ni chez un autre commerçant.

Pourquoi un accès administrateur peut vider un hot wallet

BTCPay ne détient l’argent de personne. Sa documentation le décrit comme « une pile logicielle libre et auto-hébergée, pas une entreprise » : chaque commerçant l’installe sur une machine qu’il contrôle et reçoit les pièces directement dans son propre portefeuille. C’est de la garde autonome appliquée à la caisse d’une boutique, et cela explique la forme singulière de cette alerte. Il n’existe aucun interrupteur central, comme l’a souligné CoinDesk : BTCPay ne pouvait que demander à chaque propriétaire d’agir. Aucune société ne détient non plus de fichier clients à qui écrire, si bien qu’un commerçant qui ne suit pas les comptes du projet peut ne pas être au courant.

Le logiciel accepte deux types de portefeuille de boutique. Dans le premier, le serveur ne connaît que des clés publiques et surveille les paiements, tandis que les clés privées se trouvent ailleurs, par exemple sur un portefeuille matériel. Dans le second, un hot wallet, la phrase de récupération est stockée sur le serveur pour que les paiements soient signés automatiquement. La documentation de BTCPay classe cette option sous une mention DANGER : « Utiliser la fonction de hot wallet a des conséquences pour la sécurité ».

La signature automatique fait la commodité, et c’est aussi l’exposition. Celui qui contrôle le serveur peut dépenser ce que la phrase de récupération contrôle, en un seul balayage qui sort les pièces du portefeuille. Aucune des principales sources ne dit que les commerçants sans hot wallet sont touchés, et BTCPay n’a pas dit qu’ils sont à l’abri. Son alerte ne faisait pas cette distinction, même si un contributeur central, Uncle Rockstar Developer, a formulé les choses ainsi, selon Bitcoin.com News : « Ce n’est pas un exercice : arrêtez votre BTCPay Server si vous avez un hot wallet. »

Pourquoi la version 2.4.7 n’est pas présentée comme un correctif

BTCPay n’a annoncé aucun correctif pour ces vols. La version 2.4.7 est sortie le 29 octobre à 13 h 48 UTC, un peu plus de trois jours avant l’alerte : elle n’a donc pas été écrite en réaction. C’est la version pour laquelle le projet n’a reçu aucun signalement crédible de vidage, ce qui est une autre affirmation que de dire que la brèche est fermée. Les notes de version sur GitHub ne relient aucune modification aux signalements de novembre, et il en va de même pour les versions précédentes. Voici ce que disent les notes, version par version :

Les 85 failles de la 2.4.7 proviennent du programme OSS Scanner d’Anthropic, et les notes jugent la mise à jour « vivement recommandée », surtout pour les serveurs partagés par plusieurs commerçants.

Une nouvelle version n’arrive d’ailleurs chez personne toute seule. « Publier des correctifs ne met pas automatiquement à jour les serveurs exploités de façon indépendante », a écrit Bitcoin.com News, et la documentation de BTCPay décrit des notifications de nouvelle version, puis une mise à jour que l’administrateur lance depuis la page Maintenance ou depuis un shell root. Un serveur resté sur une version de juillet n’a reçu aucune des publications ci-dessus, sauf si quelqu’un les a installées.

La faille d’août visait les nœuds Lightning, et BTCPay avait mis les hot wallets hors de cause

C’est la deuxième urgence de BTCPay en moins de trois mois. Le 7 août, son avis de sécurité expliquait que toutes les versions antérieures à la 2.4.2 permettaient à un attaquant distant non authentifié de récupérer les fichiers d’identifiants LND .macaroon et de prendre le contrôle du nœud Lightning d’un commerçant. Des fonds ont été volés. Parmi les victimes nommées figuraient Foundation, le fabricant de portefeuilles matériels, et Citadel21, d’après CoinDesk, qui ajoutait que le hot wallet on-chain de Foundation n’avait pas été touché. BTCPay n’a donné aucun total, ni dans l’avis ni dans son message de suivi du 10 août.

Les consignes ressemblaient beaucoup à celles de dimanche : passer à la 2.4.2, et les utilisateurs de LND qui ne pouvaient pas le faire tout de suite devaient mettre leur serveur hors ligne. L’avis, mis à jour pour la dernière fois le 30 octobre, indique toujours : « Les portefeuilles on-chain de BTCPay Server, y compris les hot wallets, ne sont pas concernés. » Il consigne aussi une précaution de cette semaine-là que BTCPay a retirée une fois confirmé que seul LND était touché. Cet épisode d’août ne dit rien de ce que les exploitants doivent faire aujourd’hui.

Cette phrase ne décrit que la faille d’août. Les nouveaux signalements portent sur des hot wallets, et les versions en cause sont celles que l’avis d’août demandait déjà de quitter. On ignore si les deux attaques sont liées. Cointelegraph le dit sans détour, et BTCPay ne l’a abordé dans rien de ce que nous avons pu lire.

BTCPay n’a pas demandé de déplacer les fonds

Beaucoup d’exploitants voudront faire plus que couper leur serveur, et le statut de ces démarches doit donc être précisé. Dans les articles que nous avons lus et sur les pages du projet, BTCPay n’a pas demandé aux exploitants de sortir les pièces des portefeuilles détenus par le serveur pour cet incident, ni de changer leurs mots de passe ou leurs clés d’API. Les conseils de ce genre qu’on lit ailleurs ne viennent pas de BTCPay.

Deux remarques plus anciennes peuvent être prises pour de telles consignes. Le message de BTCPay du 10 août privilégie le stockage à froid comme pratique générale, mais il précède ces signalements et n’en traite pas. Bitcoin.com News écrit que Dorier a rappelé l’importance de limiter le solde d’un hot wallet à ce que l’exploitant peut se permettre de perdre, sans présenter cela comme une consigne pour cet incident. Notre guide des types de portefeuilles et de la garde explique l’arbitrage à ceux qui hésitent. Rien dans ces lignes ne recommande de déplacer ou de conserver un actif.

Ce que personne n’a encore dit

• Combien a été pris. Aucun total en bitcoins ni en dollars n’a été publié.
• Combien de commerçants ou de serveurs ont été touchés.
• Comment l’attaquant a obtenu l’accès administrateur, et quel est le vecteur d’attaque.
• Si les exploitants doivent mettre à jour maintenant ou rester hors ligne, et quand un serveur arrêté peut repartir.
• Si les versions 2.4.2 à 2.4.6 sont exposées, et si la 2.4.7 ferme la voie ou si elle n’a simplement pas été attaquée.
• Si les vols sont liés à la faille d’août.
• Qui est derrière. Aucune adresse on-chain ni aucun identifiant de transaction n’a été publié non plus.

Les documents publics restent minces pour l’instant. Lorsque nous avons vérifié, vers 05 h 50 UTC lundi, le blog de BTCPay n’avait aucun article sur l’incident (le dernier date du 5 octobre), la page des avis de sécurité GitHub était vide, aucun numéro CVE n’apparaissait dans ce que nous avons lu, et la 2.4.7 restait la version la plus récente. Cointelegraph a précisé que BTCPay n’avait pas répondu à sa demande de commentaire avant la publication.

CoinDesk a replacé l’alerte dans la même semaine que le piratage de Binance, mais aucune source ne relie les deux.

Les prochains documents à surveiller sont un article du blog de BTCPay ou un avis GitHub donnant la cause racine, une version 2.4.8, et toute déclaration indiquant que les serveurs arrêtés peuvent repartir. Nous n’avons rien trouvé qui retire la demande de rester hors ligne formulée dimanche.