EN
en direct

GoBalance tronque la clé privée de Tor et livre les adresses .onion du dark web

Le 8 octobre 2026, Searchlight Cyber a révélé que GoBalance, le répartiteur de charge du dark web, signe ses descripteurs avec une clé privée tronquée de moitié, ce qui permet de reconstruire la clé maîtresse d’un site .onion à partir d’un seul descripteur public. Tout site ayant servi une adresse via une version vulnérable doit la remplacer, car un correctif ne rattrape pas une clé déjà divulguée.

Une clé maîtresse en laiton brisée en deux, les deux moitiés posées sur une ardoise sombre, un reflet ambre sur la cassure.

8 octobre 2026. La société Searchlight Cyber révèle une faille dans GoBalance, le répartiteur de charge que de nombreux sites du dark web utilisent pour rester joignables pendant une attaque par déni de service. Une troncature. Le logiciel passe au signataire seulement la moitié de la clé privée Tor. Une seule signature. Un descripteur publié suffit alors pour reconstruire la clé maîtresse d’un site .onion et en prendre le contrôle. Pourquoi c’est important : la faille ne touche ni Tor ni l’Onionbalance original — elle est née dans la réécriture en Go, et elle s’est déjà traduite par le détournement des deux adresses du forum Dread, l’un des plus grands du dark web.

Une clé de 64 octets coupée en deux

Pour comprendre la faille, il faut rappeler ce qu’est une adresse .onion : une clé publique. Quiconque détient la clé privée correspondante contrôle l’adresse. Pour rester joignable, un site publie un enregistrement signé — le descripteur — que n’importe quel nœud du réseau Tor peut récupérer. GoBalance est chargé de signer cet enregistrement. C’est précisément dans l’étape de signature que tout se joue.

Une clé privée Tor fait 64 octets. GoBalance n’en a transmis que les 32 premiers au signataire Ed25519, et a abandonné le reste. Or la moitié abandonnée est celle qui rend la valeur secrète de chaque signature non reproductible : elle alimente le nonce qui varie d’une signature à l’autre. Sans elle, ce nonce devient un nombre fixe que n’importe qui peut calculer. Résultat : un unique descripteur publié contient assez d’information pour reconstruire la clé privée du site, sans aucun accès à ses serveurs.

Le détail qui aggrave tout : la clé exposée est la clé maîtresse de long terme du site, pas une clé éphémère. Une clé reconstruite peut donc signer des descripteurs valides pour cette adresse longtemps après, et détourner le trafic vers une copie contrôlée par l’attaquant. La prise de contrôle de l’adresse ne donne en revanche pas accès aux serveurs, à la base de données ni aux données stockées des utilisateurs — la menace porte sur la confidentialité des visiteurs redirigés vers un site hostile.

Le nonce, ou pourquoi une moitié de clé suffit à tout casser

La mécanique mérite une explication, parce qu’elle est enseignante. Ed25519 ne chiffre pas : il signe en dérivant, pour chaque message, un nombre à usage unique appelé nonce, calculé de façon déterministe à partir de la clé privée complète — les 32 octets de graine plus 32 octets de préfixe. Si ce nonce se répète ou devient prévisible, la signature révèle la clé privée. C’est le principe des attaques de réutilisation de nonce qui ont cassé des clés ECDSA sur PlayStation 3 ou sur des portefeuilles Bitcoin mal implémentés.

En ne transmettant que la graine, GoBalance a transformé un nonce qui aurait dû être imprévisible en un nombre fixe. À partir d’une seule signature, un attaquant résout alors l’équation et récupère le scalaire secret. Ce n’est pas une faiblesse d’Ed25519 — la primitive est saine — mais de l’appelant qui l’a alimentée avec la moitié de la clé. La leçon vaut pour toute intégration : une bibliothèque cryptographique ne protège que si on lui fournit les bonnes entrées, et un nonce prévisible est l’équivalent d’une porte laissée ouverte, même quand le reste de la maison est blindé.

Le cas Dread : deux adresses volées en trois jours

La faille est remontée à la surface par un incident réel. Entre le 5 et le 7 octobre 2026, les deux adresses .onion de Dread — un forum administré par HugBunter et Paris — ont été prises en contrôle et redirigées vers un site concurrent, Conclave.

La séquence est instructive parce qu’elle montre comment un défaut de conception se déguise d’abord en erreur humaine. Le 5 octobre, Paris explique avoir « stupidement téléversé la clé privée principale de Dread dans une mise à jour de gobalance ». L’explication tient pour la première adresse. Deux jours plus tard, la seconde adresse — une sauvegarde réservée aux membres premium — est détournée à son tour. Une sauvegarde s’explique beaucoup plus difficilement par une simple bévue : HugBunter déclare alors que l’attaquant a exploité une faille de GoBalance contre plusieurs services du dark web. Searchlight Cyber partage cette lecture et considère le second détournement comme le signe le plus solide de l’exploitation de la faille, tout en traitant la première adresse comme une fuite de clé distincte.

Le 7 octobre, dans un message signé, les opérateurs annoncent que le forum a « migré, de façon permanente, à la suite de l’exposition de la clé privée .onion due à une vulnérabilité dans un logiciel tiers », et que « d’autres services cachés peuvent être affectés ». Ils précisent que les serveurs de Dread n’ont pas été compromis. Le forum a depuis changé d’adresse et demandé à ses utilisateurs de modifier leurs mots de passe.

Qui est exposé, qui ne l’est pas

La portée réelle est encore floue. GoBalance est une réécriture en Go de l’Onionbalance de Tor, et il est livré avec EndGame, une boîte à outils très répandue pour maintenir les sites du dark web en ligne pendant les attaques par déni de service. La faille vit dans la réécriture : Searchlight Cyber précise que l’Onionbalance original et Tor lui-même ne sont pas affectés.

Le périmètre se resserre encore sur un point de configuration. Seuls les sites dont la clé maîtresse est stockée dans le format de clé propre à Tor sont exposés. L’outil d’installation de GoBalance écrit les clés dans un format plus sûr qui n’est pas à risque : tout site utilisant GoBalance n’est donc pas nécessairement vulnérable.

Quant au nombre total de victimes, personne ne le connaît. HugBunter affirme que plusieurs marchés du dark web ont vu leur adresse détournée, y compris certains déjà fermés, sans donner de noms ni de chiffres. Au moins un autre site l’a confirmé publiquement : Omega, un marché, a indiqué le 8 octobre avoir retiré son ancienne adresse « en raison d’un problème causé par le bug de GoBalance » et en avoir ouvert une nouvelle.

Pas de correctif : il faut migrer, pas patcher

Il n’existe aucun correctif officiel à ce jour. Le 9 octobre 2026, The Hacker News ne trouvait ni identifiant CVE dans la base NVD américaine, ni avis public du Tor Project ni du mainteneur de GoBalance. Dread annonce préparer une version corrigée et aider les sites touchés à migrer. Un chercheur indépendant a publié de son côté un correctif et une preuve de concept qui reconstruit une clé maîtresse à partir d’un seul descripteur public ; la démonstration n’a utilisé que des clés créées pour l’exercice.

La leçon opérationnelle est contre-intuitive : un correctif ne répare rien ici. Une fois qu’un descripteur a été publié, la clé qu’il divulgue ne peut plus être rappelée. Un site qui a fait tourner une version vulnérable doit donc créer une nouvelle adresse .onion et migrer vers elle, comme l’ont fait Dread et Omega. Pour les utilisateurs d’un site potentiellement affecté, la consigne de Dread tient en trois gestes : changer son mot de passe sur ce site et sur les autres sites concernés, traiter l’ancienne adresse comme non fiable, et ne faire confiance à une nouvelle adresse qu’après une annonce signée.

Verdict

Si vous exploitez un service caché derrière une instance GoBalance, considérez votre adresse actuelle comme compromise : générez une nouvelle adresse .onion, migrez vos utilisateurs et faites signer votre annonce de migration. Un simple patch, quand il sortira, ne protégera pas une clé déjà divulguée. Si vous fréquentez des forums ou des marchés du dark web, changez vos mots de passe, méfiez-vous de toute redirection vers un « nouveau » domaine et n’acceptez que des adresses confirmées par une signature des opérateurs. Si vous n’utilisez pas le dark web, retenez surtout la mécanique : une réécriture d’un protocole éprouvé — ici Onionbalance vers GoBalance — peut casser une garantie cryptographique aussi fondamentale que le nonce d’une signature, sans que personne ne s’en aperçoive pendant des mois.

Références

Le brief cyber, chaque mardi

Les failles qui comptent, les correctifs à appliquer, en dix minutes de lecture.

Pas de spam. Désinscription en un clic.
à lire ensuite

Sur le même sujet

OpenSSL 4.1.0 livre enfin DTLS 1.3, avec quatre bugs connus dans le code livré

Le 23 octobre 2026, OpenSSL publie la version 4.1.0, qui apporte le support de DTLS 1.3 (RFC 9147) en même temps que quatre bugs connus dans ce code, dont deux font mentir les codes de retour d’une connexion. Si vous adoptez DTLS 1.3 côté serveur, ne prenez pas SSL_ERROR_WANT_READ ni SSL_ERROR_SYSCALL au pied de la lettre.

Le SSH de Tailscale transforme une machine compromise en accès root sur tout le maillage

Le 25 octobre 2026, la chercheuse Erica Windisch publie « Tailworm », un rapport qui montre que le SSH de Tailscale, combiné au transfert de port, donne un accès root sur chaque serveur joignable dès qu’un seul appareil du maillage est compromis. Sans correctif ni CVE à ce jour, la parade immédiate tient en trois réglages : règles d’accès par paires, transfert de port désactivé et Tailnet Lock.

← Retour au fil

Tapez au moins deux caractères.

↑ ↓ naviguer ↵ ouvrir esc fermer