BLOG |
Annonces Blink
Comment un pirate a exploité une faille dans nos outils d'administration pour dérober 6,61 BTC sur 24 comptes, comment chacun d'entre eux a été rétabli, et quelles mesures nous avons prises.
Le samedi 19 septembre, à 11 h 39 UTC, un client a appelé l'un de nos ingénieurs sur son téléphone pour lui signaler que son solde Blink avait disparu. Quinze minutes plus tard, nous avions désactivé l'ensemble du service de conservation. Le soir même, le déficit avait été comblé. Le jeudi suivant, tous les clients concernés avaient récupéré l'intégralité de leur solde, financé par les actionnaires de Blink. Aucun client n'a subi de perte.
Aux 22 clients qui se sont fait dérober leurs bitcoins, ainsi qu'aux 3 817 personnes dont les informations de compte ont été consultées : nous vous présentons nos excuses.
Que s'est-il passé ? Le 17 septembre, un pirate a ouvert un compte Blink gratuit classique. Deux jours plus tard, il a exploité une faille dans le mécanisme de vérification des autorisations de nos outils d'administration pour attribuer des droits d'administrateur à ce compte. Grâce à ces droits, il a modifié l’adresse e-mail ou le numéro de téléphone de 35 comptes, s’est connecté à ces derniers comme s’il en était le titulaire, a augmenté les limites de retrait sur 14 d’entre eux et a retiré des bitcoins de 24 d’entre eux entre 09 h 51 et 11 h 54 UTC, en partie sur la blockchain et en partie via Lightning , en utilisant le processus que nous avions mis en place pour aider nos clients à passer à l’auto-custode. Le pirate a ainsi obtenu environ 6,61 BTC.
À qui appartenait cet argent ? Ils ont ciblé 36 comptes de dépôt. L’un d’entre eux a échappé au piratage par hasard : leurs tentatives pour modifier son adresse e-mail ont échoué, et ils sont passés à autre chose. Sur les 35 comptes qu’ils ont piratés, ils ont effectué des retraits sur 24. Neuf d’entre eux disposaient d’une authentification à deux facteurs et n’ont subi aucune perte (voir ci-dessous), et le pirate a pris le contrôle des deux derniers comptes quelques minutes seulement avant que nous ne fermions le service ; aucun montant n’a donc été prélevé sur ces derniers. Sur les 24 comptes vidés, 22 appartenaient à des clients ; deux appartenaient à des sociétés du groupe Blink. Chacun a été rétabli à son solde exact d’avant l’incident le 24 septembre, les frais de retrait ayant été remboursés, et les comptes bloqués ont été rouverts à partir de ce jour-là. Blink prend en charge la perte.
Ce qui n'a pas été touché. L'argent provenait de notre « hot wallet » — le solde d'exploitation que nous conservons pour les paiements quotidiens. La plupart des fonds des clients sont stockés dans un « cold storage » à signatures multiples, qui nécessite plusieurs clés détenues par des personnes différentes, et aucun de nos outils d'administration ne peut y accéder. Les comptes non dépositaires n'ont jamais été concernés : nous ne détenons pas ces clés, l'attaquant n'avait donc rien à dérober.
Ce qu'ils ont pu voir. Au cours de l'attaque, ils ont également eu accès aux informations de 3 817 autres comptes. Pour certains, ces informations comprenaient un numéro de téléphone ou une adresse e-mail. Ils n'ont pas eu accès aux noms, aux pièces d'identité, aux adresses, aux mots de passe ni aux phrases de récupération. Nous avons écrit à tous les titulaires de compte que nous avons pu contacter pour leur indiquer les informations auxquelles ils ont eu accès.
Qu'est-ce qui les a arrêtés ? L'authentification à deux facteurs. Aucun des 24 comptes vidés ne l'avait activée. Neuf des comptes qu'ils ont ciblés l'avaient activée. Le pirate s'est connecté à ces neuf comptes, mais chacune de ses 18 tentatives d'utilisation de ces comptes a été refusée. Aucune perte. Nous soulignons ce point car c'est l'un des principaux enseignements à tirer de cet incident : l'authentification à deux facteurs a fonctionné, et nous aurions dû l'imposer pour les retraits importants et pour les comptes présentant des soldes élevés.
Ce que nous avons modifié. La faille a été corrigée le jour même, et une troisième couche de protection a été mise en production le 21 septembre. Les outils d'administration ne sont plus accessibles depuis l'Internet public. Les fonctions d'administration permettant de modifier l'adresse e-mail ou le numéro de téléphone d'un client ont été désactivées pour tous les utilisateurs, le temps que nous les repensions. Toutes les clés API des clients ont été révoquées. Le portefeuille « hot wallet » ne contient désormais qu'une fraction de ce qu'il contenait auparavant. Vous trouverez la liste complète ci-dessous.
Où se trouve l'argent ? Une partie se trouve toujours aux adresses vers lesquelles il a été transféré. Le reste a été versé dans leurs autres portefeuilles, dont environ 5 BTC ont transité par un service d'échange inter-chaînes et une petite somme a abouti sur Binance. Au Salvador, une plainte pénale a été déposée auprès de la Fiscalía General de la República, et l'autorité de régulation financière a été informée ; à Próspera ZEDE, une plainte pénale a été déposée auprès de la police, et l'autorité de régulation financière a été informée. Nous ne nous attendons pas à récupérer cet argent ; la récompense ci-dessous est destinée à toute personne capable de changer la donne.
Une prime de 50 %. Nous verserons 25 % de la valeur de toute partie des 6,61 BTC volés le 19 septembre qui serait récupérée grâce aux informations que vous fournirez — jusqu’à environ 1,65 BTC si la totalité était retrouvée. Les 25 % restants de toute somme récupérée seront reversés à Bitcoin Beach, Bitcoin Ekasi, Afribit Kibera et à leur sélection commune d’économies circulaires basées sur le Bitcoin dans les pays du Sud. Si les informations fournies conduisent au gel de fonds, la prime sera versée une fois que ces fonds auront été restitués à un portefeuille que nous contrôlons. Cette offre est valable sans date limite. Écrivez à bounty@blinkbtc.com. Les conditions générales, qui régissent cette offre, sont disponibles à l’adresse blink.sv/bounty-terms.
Ce que vous devez faire. Activez l'authentification à deux facteurs (Paramètres → Sécurité et confidentialité → Authentification à deux facteurs), et activez-la également sur votre compte de messagerie. Ajoutez une connexion par e-mail si vous ne disposez que d'un téléphone, car un numéro de téléphone peut faire l'objet d'un « SIM swap ». Si vous utilisez l'API, générez une nouvelle clé. Ignorez tout e-mail ou SMS concernant cet incident qui contiendrait un lien : nous avons contacté les utilisateurs concernés par le biais de messages dans l'application Blink. Nous ne vous demanderons jamais votre code PIN, votre mot de passe, votre phrase de récupération ou un code de connexion, ni de transférer des fonds. Si nous vous avons envoyé un message concernant votre compte, suivez les étapes indiquées dans ce message. Si vous préférez conserver vos propres clés, les comptes non dépositaires sont disponibles dans l’application depuis juin (Paramètres → Passer à un compte non dépositaire).
Blink est géré par une vingtaine de personnes réparties sur une douzaine de fuseaux horaires ; il n’y a donc pas de « samedi matin » commun à tout le monde. À 11 h 39 UTC, c'était le début de soirée à Hong Kong, l'heure du déjeuner en Europe et l'aube au Salvador. Le client qui a appelé avait remarqué que son solde était à zéro et que son adresse e-mail avait été modifiée. En l'espace de six minutes, l'équipe était en ligne, les premiers comptes avaient été verrouillés manuellement depuis le panneau d'administration, et la décision cruciale avait été prise : tout mettre hors service.
À 11 h 54, nous avons mis hors ligne l'ensemble de l'infrastructure de conservation. Cette décision a privé chaque utilisateur de Blink de près de huit heures de service. Les retraits ont cessé dès l'arrêt du service. À 12 h 41, nous avons publié un premier communiqué : « Services suspendus, enquête en cours ». À 16 h 06, nous avons publié un deuxième communiqué : « Chaque compte concerné sera intégralement dédommagé ».
À 16 h 17, le premier correctif a été intégré, puis le troisième à 17 h 50. Les fonds restants dans les portefeuilles « hot » ont été transférés vers de nouvelles adresses afin que tout paiement déjà signé pour les retraits de l'attaquant soit rejeté. À 19 h 34, nous avons réactivé le service pour tous les utilisateurs, à l’exception des 36 comptes sur lesquels l’attaquant avait agi, qui sont restés bloqués jusqu’à ce que nous puissions les restaurer correctement. Les fonctions d’administration permettant de modifier les coordonnées sont restées désactivées à titre de mesure de sécurité supplémentaire ; le correctif a été vérifié en environnement de test ce soir-là, et dans les jours qui ont suivi, nous avons nous-mêmes reproduit l’attaque dans son intégralité sur une copie du code antérieur au correctif, afin de nous assurer que nous en avions bien compris le fonctionnement — puis nous avons confirmé que chaque couche du système était désormais en mesure de la bloquer.
Toutes les heures sont indiquées en UTC ; le Salvador a six heures de retard.
D’octobre 2023 au 19 septembre 2026, toute personne disposant d’un compte Blink gratuit et d’un navigateur Web pouvait s’octroyer les privilèges de notre équipe d’assistance : modifier l’adresse e-mail ou le numéro de téléphone associé au compte d’un client, puis se connecter en tant que ce client et augmenter ses limites de retrait. Nous publions la procédure exacte, car notre code est open source, d’autres services exploitent des déploiements basés sur celui-ci, et l’erreur fondamentale — se fier à la description fournie par un jeton lui-même concernant ce qu’il est autorisé à faire — peut se reproduire dans n’importe quel système construit de la même manière.
Notre équipe utilise une interface d'administration pour aider les clients à : débloquer un compte, corriger un numéro de téléphone, augmenter une limite. L'accès à cette interface s'effectue via OAuth2, la même norme qui vous permet de vous connecter à un site web à partir d'un autre. Trois problèmes distincts se sont présentés, et chacun d'entre eux est en soi tout à fait banal.
La page de consentement faisait confiance au navigateur. Lorsqu’une application demandait des autorisations, notre page de consentement récupérait directement la liste des autorisations à partir du formulaire envoyé par le navigateur et la transmettait telle quelle à notre serveur OAuth. Elle ne vérifiait jamais si cette liste correspondait bien à ce que l’application avait réellement demandé. Ainsi, n’importe qui aurait pu ajouter un champ caché au formulaire indiquant « accordez-moi également les droits d’administrateur », et le serveur — faisant confiance, à juste titre, à sa propre page de consentement — aurait généré un jeton parfaitement valide indiquant « administrateur ».
L'API d'administration acceptait n'importe quel jeton. Le « gatekeeper » situé en amont acceptait tout jeton valide provenant de notre serveur OAuth : aucune autorisation requise, aucune vérification que le jeton était bien destiné à l'API d'administration, aucune vérification de l'identité du client. Il copiait les autorisations déclarées par le jeton dans les informations d'identification utilisées par le serveur d'administration.
Le serveur d'administration considérait la chaîne d'autorisations comme fiable. Si la chaîne indiquait « admin », vous étiez administrateur. Aucune vérification n'était effectuée pour s'assurer que la personne derrière le jeton était bien un administrateur connu.
Ces deux éléments combinés faisaient qu’un simple compte gratuit et un navigateur suffisaient. Aucun compte ni identifiant d’employé n’a été utilisé, et aucun logiciel malveillant n’était en cause. C’est notre propre système d’identité qui a émis ces jetons, ce qui explique précisément pourquoi aucune alerte n’a été déclenchée. L’attaquant a d’abord tenté la voie la plus évidente — ajouter des autorisations à la demande d’autorisation principale — et notre configuration l’a correctement rejetée. Il s’est ensuite tourné vers la page de consentement, qui lui a ouvert la voie.
Pour quiconque procède à un audit d’une pile similaire, l’historique est important. La faille a été ouverte en octobre 2023 par trois pull requests successives : la première a permis à l’API d’administration d’accepter des jetons OAuth alors qu’une validation distincte côté éditeur continuait de la protéger ; la deuxième a supprimé cette validation côté éditeur ; la troisième a donné à chaque utilisateur l’accès à l’écran de consentement OAuth. Une modification de renforcement de la sécurité effectuée en mai 2026 (PR n° 158) a ajouté des exigences en matière d’autorisations d’administrateur sur le serveur d’administration, mais elle lisait ces autorisations à partir du jeton lui-même, et la page de consentement permettait toujours à n’importe qui de les y inscrire. Cette faille a pu être exploitée pendant environ trois ans.
Les corrections sont publiques : la page de consentement refuse désormais toute autorisation que l'application n'a pas demandée (PR n° 853) ; les jetons d'administrateur doivent comporter une audience émise exclusivement pour l'API d'administration, ce que les jetons client ne peuvent pas obtenir (même PR ; le PR n° 855 nous a permis d’activer cette vérification séparément en production, ce que nous avons fait le 21 septembre) ; enfin, les fonctions d’administration permettant de modifier les coordonnées peuvent être purement et simplement désactivées par configuration, pour tous les utilisateurs (PR n° 861).
Le code a été écrit en 2023, au sein de l’entreprise où la plateforme Blink a été développée à partir de 2019, et nous en sommes devenus propriétaires en octobre 2024, lorsque Blink a connu un changement de propriétaire et est devenue une société indépendante. Deux des ingénieurs qui avaient développé la plateforme nous ont rejoints, mais ceux qui avaient codé le flux d’autorisation administrateur sont restés dans l’ancienne entreprise ; personne au sein de l’équipe Blink ne savait donc pourquoi une vérification d’autorisation antérieure avait été mise en place. Tout au long de l’année 2025, l’essentiel de notre travail d’ingénierie a consisté à séparer nos systèmes de ceux de cette entreprise, qui s’étaient développés conjointement au fil des ans : notre propre infrastructure, nos propres comptes, notre propre nœud.
En 2026, la réglementation a évolué dans de nombreux pays où nous étions présents. Google a commencé à exiger des licences locales pour les applications de portefeuille sur quinze marchés, la période de transition pour la réglementation MiCA de l’UE a pris fin le 1er juillet, et de nombreuses autres juridictions ont adopté de nouvelles lois ou mis en vigueur des lois adoptées les années précédentes. Nous avons réagi en réduisant les fonds que nous détenions pour le compte de nos clients plutôt qu'en demandant davantage de licences : nous avons développé et lancé un portefeuille sans conservation, retiré notre service de conservation de plus de quarante juridictions et transféré des dizaines de milliers d'utilisateurs vers des comptes où ils détiennent leurs propres clés. Notre article publié en juin à l'occasion du lancement de notre portefeuille sans conservation décrit ce travail. Pour une équipe d'une vingtaine de personnes, cela a pris la majeure partie de l'année.
La sécurisation du code dont nous avions hérité avait été mise de côté au profit de ces deux projets. Elle a été négligée pendant trop longtemps. La première chose que nous avons changée, c’est la manière dont les failles de sécurité sont classées par priorité et attribuées à un responsable.
Le « hot wallet » surélevé s'inscrit dans ce même contexte. Nous l'utilisions à un niveau environ deux fois supérieur à la normale afin de disposer d'une marge de sécurité pour la migration, dont la première vague s'était achevée une semaine ou deux avant l'attaque. Nous ne l'avions pas encore ramené à son niveau habituel. C'est pourquoi la perte a pu atteindre un montant aussi élevé. Depuis, ce niveau a été ramené à une fraction de ce qu'il était, et le solde d'exploitation de l'Lightning est en train d'être encore réduit.
L'attaquant a pris le contrôle de 35 comptes de la même manière : modifier l'adresse e-mail ou le numéro de téléphone via les outils d'administration, demander un code de connexion, puis se connecter. Sur 24 d'entre eux, il a ensuite retiré des fonds. Sur neuf d'entre eux, il s'est heurté à un obstacle. Ces neuf comptes disposaient d'une authentification à deux facteurs activée — une application d'authentification sur le téléphone du propriétaire — et, sur un compte protégé par l'authentification à deux facteurs, une session ouverte uniquement avec un code de connexion ne permet pas d'effectuer de virement. Nos journaux montrent que les 18 tentatives de l’attaquant sur ces neuf comptes ont toutes échoué précisément à cette étape. Aucune perte n’a été constatée sur aucun d’entre eux.
L'authentification à deux facteurs (2FA) n'a pas empêché le piratage de nos outils d'administration. En revanche, elle a permis d'empêcher les vols sur les comptes individuels. Aucun des 24 comptes ayant subi des pertes financières n'avait activé cette fonctionnalité. Nous aurions dû la rendre obligatoire pour les retraits importants et pour les comptes présentant des soldes élevés.
Si vous ne devez retenir qu'une seule chose de cet article, que ce soit celle-ci : Paramètres → Sécurité et confidentialité → Authentification à deux facteurs. Activez-la également pour votre compte de messagerie, car vos codes de connexion Blink peuvent y être envoyés.
Dès le dimanche, au lendemain de l'attaque, nous savions ce qui avait été dérobé à qui, au satoshi près, après avoir effectué un rapprochement avec le grand livre, la blockchain et le nœud Lightning , et le Conseil d'administration avait décidé comment couvrir ces pertes. Les actionnaires de Blink se sont engagés à fournir la totalité du montant dans les 24 heures sous forme de prêt sans intérêt, l'ont versé le mercredi, et chaque actionnaire s'est vu proposer de financer sa part aux mêmes conditions. Le jeudi 24 septembre, nous avons rétabli tous les soldes affectés et remboursé les frais que nous avions facturés sur les retraits frauduleux. Nous avons contacté directement les clients concernés avant de faire toute autre déclaration publique, de même que les personnes dont les données avaient été consultées.
Cet ordre était délibéré. Les utilisateurs d’abord ; tout le reste ensuite. Nous avons informé nos actionnaires vendredi des mêmes faits que ceux que vous lisez actuellement, et nous avons attendu que les autorités aient reçu nos signalements avant de publier cet article : une plainte pénale déposée auprès du Parquet général de la République du Salvador, des notifications adressées à l’autorité de régulation financière et à l’agence de cybersécurité du Salvador, une plainte pénale déposée auprès du service de police de la ZEDE de Próspera, ainsi qu’une notification adressée à l’autorité de régulation financière de Próspera.
Deux événements se sont produits cette semaine-là que nous tenons à consigner. Le dimanche, le pirate nous a écrit pour exiger un paiement, en menaçant de publier les données des utilisateurs. Nous n’avons pas payé et nous ne le ferons pas ; ce message constitue désormais la preuve de sa tentative d’extorsion. Et entre le dimanche et le mercredi, il a continué à se connecter à quatre des comptes verrouillés dont les coordonnées indiquaient encore l’adresse e-mail du pirate, car nous ne les avions pas encore rétablies. Chaque paiement qu’il a tenté a été refusé et rien n’a bougé. Cela n’aurait pas dû être possible. Notre procédure de réactivation rétablit désormais les coordonnées en premier lieu, met fin à toutes les sessions, puis déverrouille le compte.
Nous ne sommes pas la première entreprise à prendre en charge une perte de ce type et à indemniser intégralement les utilisateurs. Des plateformes d'échange et des portefeuilles l'ont déjà fait avant nous. La perte subie par un dépositaire incombe à ce dernier.
Le 19 septembre, Blink ne partait pas de zéro. La plupart des fonds des clients se trouvaient déjà dans des solutions de stockage à froid multi-signatures réparties sur plusieurs continents ; le service fonctionne en réserve intégrale ; l’authentification à deux facteurs était disponible et nous encouragions activement les utilisateurs à l’adopter ; enfin, les retraits étaient limités au niveau de chaque compte. La plupart de ces mesures ont tenu bon : le pirate n’a jamais accédé au stockage à froid, n’a jamais touché à un compte non dépositaire et a échoué sur tous les comptes dotés de l’authentification à deux facteurs. Ce qui a échoué plus précisément, ce sont les contrôles d’autorisation dans nos outils d’administration hérités, ainsi que la surveillance qui se concentrait sur les pannes plutôt que sur le fait qu’un administrateur puisse effectuer une action qu’aucun administrateur ne devrait effectuer. Ce qui a échoué de manière plus générale, ce sont nos priorités : la transition de propriété, puis la sortie de la garde ont mobilisé la majeure partie de l’équipe, et le travail de sécurité sur le code dont nous avions hérité a été relégué au second plan.
Voici ce que nous avons fait pour y remédier, dès les premiers jours :
Un renforcement supplémentaire est en cours sur l'ensemble de la plateforme.
Et deux engagements qui prennent effet dès aujourd’hui :
1.La prime de récupération. Nous verserons 25 % de la valeur de toute partie des 6,61 BTC volés le 19 septembre qui sera récupérée grâce aux informations que vous nous fournirez — jusqu’à environ 1,65 BTC si la totalité était récupérée. Sur tout montant récupéré, 25 % supplémentaires iront à Bitcoin Beach, Bitcoin Ekasi, Afribit Kibera et à une sélection conjointe d’économies circulaires basées sur le Bitcoin dans les pays du Sud qui auraient besoin d’un soutien supplémentaire. Cette offre n’a pas de date d’expiration ; écrivez à bounty@blinkbtc.com. La prime n’est versée qu’à partir des fonds qui ont été restitués dans un portefeuille que nous contrôlons. Les fonds volés peuvent nous être restitués sur la blockchain à l’adresse bc1q5vek5m04l6v277t6exhrurylqsmtvg2l30pt99 ou via Lightning à l’adresse Lightning : bounty@blink.sv.
2.Un canal de signalement des failles de sécurité, avec des récompenses. Écrivez à bounty@blinkbtc.com. Les signalements font l'objet d'un accusé de réception dans les 72 heures et sont pris en charge par notre équipe de sécurité jusqu'à leur résolution. Les recherches menées de bonne foi sur les logiciels de Blink sont les bienvenues, et nous n'entreprendrons aucune action à l'encontre de toute personne signalant une faille de manière responsable. Nous versons des récompenses discrétionnaires pouvant aller jusqu’à 0,1 BTC pour les découvertes critiques. La politique complète est disponible à l’adresse blink.sv/bounty-terms. Ce canal a été mis en place à la suite de cet incident : chaque signalement doit être transmis à un interlocuteur, être pris en compte et rester sous la responsabilité de notre équipe jusqu’à sa résolution.
Ces 50 % sont répartis en deux : 25 % reviennent à la personne dont les informations permettront de récupérer les fonds, et les 25 % restants de tout montant récupéré sont versés à Bitcoin Beach, Bitcoin Ekasi, Afribit Kibera et aux initiatives d’économie circulaire qu’ils choisiront. Nous pensons que ces fonds sont très probablement perdus à jamais. Les bitcoins volés sont extrêmement difficiles à récupérer ; pour nous, tout montant récupéré représente donc une grande victoire, et plus nous pourrons encourager de personnes à nous aider à retrouver l’auteur de l’attaque, mieux ce sera. Ce genre de personnes ne doit pas s’en tirer à bon compte, et nous voulons leur rendre la dépense de cet argent aussi difficile et pénible que possible.
Nous avons ajouté ces 25 % supplémentaires car nous tenons à rappeler à l’attaquant qu’il a volé de l’argent que nous, ainsi que nos actionnaires partageant notre mission, aurions bien préféré consacrer à soutenir l’adoption du Bitcoin au niveau local et à donner les moyens d’agir aux développeurs Bitcoin dans les communautés privées d’accès aux services bancaires à travers le monde. Honte à l’attaquant.
Nous avons suivi la trace de ces fonds sans interruption depuis le 19 septembre. Au 1er octobre, environ 0,87 BTC se trouvait toujours, sans avoir été transféré, sur les adresses de réception. Le reste a été transféré vers d’autres portefeuilles leur appartenant, qui contiennent également des bitcoins ne provenant pas de Blink. À partir de ces portefeuilles, environ 5,05 BTC ont transité par un service d’échange inter-chaînes (NEAR Intents), 1 BTC le 21 septembre et environ 4,05 BTC les 28 et 29 septembre ; notre demande de gel des fonds du 22 septembre étant restée sans réponse, nous avons demandé aux autorités d’obtenir les registres de ce service ; environ 0,012 BTC a été déposé sur Binance, et l’équipe de sécurité de Binance est mobilisée et procède actuellement à des blocages. Comme les bitcoins de l’attaquant lui-même sont mélangés à ces fonds, ces chiffres ne correspondent pas au total de 6,61 BTC. Les adresses sur la chaîne sont indiquées en annexe.
Notre base de code est open source et des services que nous n’avons pas développés exploitent des déploiements dérivés de celle-ci. Le modèle vulnérable — un flux de consentement qui se fie à la liste des autorisations du navigateur, et un contrôleur de périphérie qui accepte n’importe quel jeton actif sans vérification de l’audience — est antérieur aux dépôts actuels de Blink et figure dans l’historique public archivé. Nous avons informé en privé les opérateurs des déploiements dérivés dont nous avons connaissance ; l’un d’entre eux a appliqué un correctif le jour même. Notre avis de sécurité concernant la base de code sera publié sur GitHub à l’adresse github.com/blinkbitcoin/blink/security/advisories, avec une demande d’identifiant CVE. Si vous exploitez une solution basée sur la base de code Blink et que vous n’avez pas reçu de nouvelles de notre part, écrivez à bounty@blinkbtc.com ; une fois que nous aurons confirmé que vous exploitez un déploiement, nous vous communiquerons la procédure de vérification complète et vous aiderons à la mettre en œuvre. Les correctifs correspondent aux trois PR (pull requests) dont les liens figurent ci-dessus. Les attaquants analysent désormais le code public à la vitesse de l’ordinateur. Si vous utilisez ce code, vérifiez-le dès aujourd’hui.
Blink a vu le jour comme un portefeuille Bitcoin destiné à un usage quotidien dans une petite ville balnéaire où les gens avaient besoin d'un moyen de paiement fiable. Le 19 septembre, pour 22 de nos clients, cela n'a pas été le cas. Chacun d'entre eux nous avait confié son argent, ce qui est justement la raison d'être d'un dépositaire.
À nos clients, pour leur patience ; aux chercheurs et aux bourses qui nous ont aidés en quelques heures ; aux actionnaires qui ont soutenu l'entreprise sans hésiter ; et à l'équipe qui a tout laissé tomber un samedi et n'a pas fermé l'œil de la nuit — merci. Nous regagnerons cette confiance comme nous l'avons gagnée à El Zonte : en étant présents et en assurant le bon déroulement des paiements, jour après jour.
Mon argent était-il en danger ? Si votre compte est ouvert et que nous ne vous avons pas écrit, cela signifie que nous n’avons aucune trace indiquant que le pirate ait consulté les informations de votre compte, et qu’aucune somme n’en a été prélevée. Jusqu’à sa fermeture le 19 septembre, cette faille aurait pu être exploitée sur n’importe quel compte avec garde, même si, sur un compte doté d’une authentification à deux facteurs (2FA), elle n’aurait permis à personne de transférer de l’argent. La plupart des fonds des clients sont conservés dans un stockage « à froid » inaccessible aux outils d’administration. Si vous disposez d’un compte sans garde, vos clés n’ont jamais été stockées sur nos serveurs et le pirate n’avait donc rien à dérober.
L'attaquant a-t-il mis la main sur mes données ? Il a consulté les informations relatives à 3 817 comptes. Nous avons écrit à tous les titulaires de compte que nous avons pu contacter pour leur indiquer quelles informations avaient été consultées. Si votre compte est actif et que vous n'avez pas reçu ce message, cela signifie qu'il ne figurait pas parmi ceux concernés. Vous pouvez à tout moment nous demander quelles informations, le cas échéant, ont été consultées concernant votre compte : support@blink.sv.
Pourquoi votre système de surveillance n'a-t-il pas détecté l'attaque ? Nos alertes ont été conçues pour détecter les pannes. Elles ne prévoyaient pas de règle pour le cas où un administrateur effectuerait des actions qu'aucun administrateur ne devrait effectuer, et l'attaquant utilisait nos propres outils avec des jetons émis par notre propre système.
Pourquoi y avait-il autant d'argent dans le portefeuille « chaud » ? Nous avions à peu près doublé notre solde d'exploitation afin de disposer d'une réserve pour la migration vers des comptes non dépositaires, et nous n'avions pas ramené ce montant à son niveau initial après la fin de la première vague. Il ne représente désormais qu'une fraction de ce niveau, et nous ne publions pas ce chiffre.
L'authentification à deux facteurs (2FA) m'aurait-elle sauvé ? Dans ce cas précis, oui. Tous les comptes qui en étaient équipés ont conservé leur argent ; tous ceux qui ont subi une perte d'argent n'en disposaient pas. Cela n'empêchera pas toutes les attaques, mais cela a permis d'en bloquer une. Activez-la.
Dois-je passer à un compte sans garde ? Si vous préférez conserver vos propres clés, oui — c’est justement à cela qu’elles servent, et personne chez Blink, ni aucune personne qui parviendrait à pirater Blink, ne peut déplacer les fonds que vous détenez vous-même. Ce n’est pas obligatoire, toutes les fonctionnalités ne sont pas encore disponibles, et leur disponibilité dépend de votre région. Si vous conservez votre compte avec garde, activez l’authentification à deux facteurs (2FA).
Qui a financé cela ? Les actionnaires de Blink, sous la forme d'un prêt sans intérêt accordé en moins de 24 heures et versé le 23 septembre. Ni les clients, ni les réserves des clients. Blink continue de pratiquer la réserve intégrale : chaque solde est couvert à 100 %.
J'ai découvert un problème de sécurité dans Blink. Que dois-je faire ? Écrivez à bounty@blinkbtc.com. Vous recevrez une réponse dans les 72 heures, votre rapport sera pris en charge par un responsable jusqu'à sa résolution, et les découvertes critiques sont récompensées.
Les mises à jour concernant l'état d'avancement de la récupération, la prime et toute correction apportée à cet article seront ajoutées ici.
Les adresses suivantes ont reçu des retraits sur la chaîne. Les plateformes d'échange et les chercheurs sont priés de vérifier les dépôts provenant de ces adresses et de contacter bounty@blinkbtc.com. (Les fonds issus de l'attaque «Lightning-rail » ont été transférés vers des portefeuilles Lightning contrôlés par les attaquants et font l'objet d'un suivi distinct.)
Total sur la chaîne : 4,62685758 BTC reçus à ces adresses au cours de 14 retraits, dont sept vers la première adresse. Notre système de paiement regroupe les retraits par lots ; ces 14 retraits ont donc été effectués en 12 transactions sur la chaîne. Les 1,98399667 BTC restants sur un total de 6,61085425 BTC se trouvent sur Lightning.
Commencez à recevoir et à envoyer des bitcoins dès maintenant
