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 nous avons remboursé chacun d'entre eux et quelles mesures nous avons prises.
Le samedi 19 septembre, à 11 h 39 UTC, un client a appelé l'un de nos ingénieurs pour lui signaler que son solde sur Blink avait disparu. Quinze minutes plus tard, nous avions désactivé l'ensemble du service de garde. Le soir même, le problème était résolu. Le jeudi suivant, chaque client concerné avait récupéré son solde exact, pris en charge par les actionnaires de Blink. Aucun client ne subit la moindre perte.
Aux 22 clients qui se sont fait voler des bitcoins, ainsi qu'aux 3 817 personnes dont les données de compte ont été consultées : nous vous présentons nos excuses.
Que s'est-il passé ? Un pirate a ouvert un compte Blink standard et gratuit le 17 septembre. Deux jours plus tard, il a exploité une faille dans la manière dont nos outils d'administration vérifiaient les autorisations pour attribuer à ce compte des droits d'administrateur. 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 relevé les limites de retrait de 14 d’entre eux et a retiré des bitcoins de 24 autres 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 avons mis en place pour aider nos clients à passer à l’auto-custode. L’attaquant a ainsi mis la main sur environ 6,61 BTC.
À qui appartenait cet argent ? Le pirate a ciblé 36 comptes de dépôt. L’un d’entre eux a été épargné par hasard : ses tentatives de modification de l’adresse e-mail ont échoué et il est passé à un autre compte. Sur les 35 comptes qu’il a piratés, il a retiré des fonds de 24 d’entre eux. Neuf disposaient d’une authentification à deux facteurs et n’ont subi aucune perte (voir ci-dessous), et il a pris le contrôle des deux derniers à peine quelques minutes avant que nous ne mettions le service hors service ; rien n’a donc été prélevé sur ces comptes. Vingt-deux des 24 comptes vidés appartenaient à des clients ; deux appartenaient à des sociétés du groupe Blink. Chacun a récupéré son solde exact tel qu’il était avant l’incident du 24 septembre, avec le remboursement des frais de retrait, et les comptes bloqués ont été rouverts à compter de ce jour-là. Blink prend en charge la perte.
Ce qui n’a pas été touché. L’argent provenait de notre trésorerie opérationnelle, le solde que nous conservons pour les paiements quotidiens. La majeure partie des fonds des clients est stockée dans un système de stockage à froid à signatures multiples, qui nécessite plusieurs clés détenues par des personnes différentes, et aucun de nos outils administratifs ne peut y accéder. Les comptes non dépositaires n’ont jamais été menacés : nous ne disposons pas de ces clés, l’attaquant n’avait donc rien à dérober.
Ce qu’il a vu. Au cours de l’attaque, il a également consulté les données de 3 817 autres comptes. Dans certains cas, celles-ci comprenaient un numéro de téléphone ou une adresse e-mail. Il n’a pas vu de noms, de pièces d’identité, d’adresses, de mots de passe ni de phrases de récupération. Nous avons écrit à chaque titulaire que nous avons pu contacter pour lui détailler ce qui avait été consulté.
Ce qui a permis de mettre un terme à l'attaque : l'authentification à deux facteurs. Aucun des 24 comptes vidés ne l'avait activée. Neuf des comptes attaqués, en revanche, l'avaient activée. Le pirate s'est connecté à ces neuf comptes, mais chacune de ses 18 tentatives d'utilisation a été rejetée. Aucune perte. Nous le soulignons car c’est l’un des principaux enseignements à tirer de cet incident : l’authentification à deux facteurs a fonctionné, et nous aurions dû l’exiger 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 exposés à Internet. 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 le temps que nous les repensons. Toutes les clés API des clients ont été révoquées. Le portefeuille opérationnel ne conserve désormais qu'une fraction de ce qu'il contenait auparavant. La liste complète figure ci-dessous.
Où se trouve l'argent ? Une partie se trouve toujours sur les adresses vers lesquelles l'attaquant a transféré les fonds. Le reste a été transféré vers d'autres portefeuilles lui appartenant, d'où environ 5 BTC ont été transférés via 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 du Parquet général de la République et le régulateur financier a été informé ; à Próspera ZEDE, une plainte pénale a été déposée auprès de la police et le régulateur financier a été informé. Nous ne nous attendons pas à récupérer l'argent ; la récompense ci-dessous est destinée à celui qui parviendra à changer la donne.
Une récompense 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 nous fournirez : jusqu’à environ 1,65 BTC si la totalité était récupérée. Les 25 % restants de tout ce qui sera récupéré iront à Bitcoin Beach, Bitcoin Ekasi, Afribit Kibera et aux économies circulaires Bitcoin du Sud global qu’ils choisiront conjointement. Si les informations fournies conduisent au gel de fonds, la récompense sera versée lorsque ces fonds seront restitués à un portefeuille que nous contrôlons. Cette offre n’a pas de date d’expiration. Écrivez à bounty@blinkbtc.com. Les conditions générales, qui prévalent, sont disponibles sur blink.sv/bounty-terms.
Que devez-vous faire ? Activez l'authentification à deux facteurs (Paramètres → Sécurité et confidentialité → Authentification à deux facteurs) et activez-la également sur votre adresse e-mail. Si vous vous connectez uniquement avec votre numéro de téléphone, ajoutez une adresse e-mail pour vous connecter : un numéro de téléphone peut être piraté à l'aide d'une carte SIM clonée (SIM swap). Si vous utilisez l’API, créez une nouvelle clé. Ignorez tout e-mail ou SMS concernant cet incident et contenant un lien : nous contactons 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 ni un code d’accès, et nous ne vous demanderons jamais de transférer vos fonds. Si nous vous envoyons un message concernant votre compte, suivez les instructions 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 pour tout le monde en même temps. À 11 h 39 UTC, la nuit tombait à Hong Kong, c'était l'heure du déjeuner en Europe et le soleil ne s'était pas encore levé au Salvador. Le client qui avait appelé avait remarqué que son solde était à zéro et que son adresse e-mail avait été modifiée. En moins de six minutes, l'équipe était en ligne, les premiers comptes avaient été bloqués manuellement depuis le panneau d'administration et la décision cruciale avait été prise : tout éteindre.
À 11 h 54, nous avons déconnecté l'ensemble du système de conservation. Cette décision a entraîné une interruption de service de près de huit heures pour chaque utilisateur de Blink. Les retraits ont été suspendus 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 entièrement rétabli ».
À 16 h 17, la première correction avait été intégrée et à 17 h 50, la troisième. Les fonds restants du portefeuille opérationnel 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 que l'attaquant avait compromis, qui sont restés bloqués jusqu'à ce que nous puissions les rétablir correctement. Les fonctions administratives permettant de modifier les coordonnées sont restées désactivées à titre de double mesure de sécurité ; le correctif a été testé dans l’environnement de test le soir même et, les jours suivants, nous avons nous-mêmes reproduit l’attaque sur une copie du code antérieure au correctif, afin de nous assurer de bien la comprendre, et nous avons confirmé que chaque couche la bloquait désormais.
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 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 de n’importe quel client, puis se connecter en tant que ce client et augmenter ses limites de retrait. Nous avons publié 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 sous-jacente — se fier à ce qu’un jeton déclare lui-même concernant ses autorisations — peut se produire 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, modifier un numéro de téléphone, augmenter une limite. L'accès s'effectue via OAuth2, la même norme qui vous permet de vous connecter à un site web avec votre compte d'un autre service. Il y avait trois problèmes, et aucun d'entre eux, pris isolément, ne retenait particulièrement l'attention.
La page de consentement s'appuyait sur le navigateur. Lorsqu'une application demandait des autorisations, notre page de consentement récupérait la liste des autorisations directement à partir du formulaire envoyé par le navigateur et la transmettait telle quelle à notre serveur OAuth. Elle ne comparait jamais cette liste avec ce que l’application avait réellement demandé. Ainsi, n’importe qui pouvait ajouter au formulaire un champ caché indiquant « accorde-moi également les autorisations d’administrateur », et le serveur — qui se fiait, à juste titre, à sa propre page de consentement — émettait un jeton parfaitement valide indiquant « administrateur ».
L'API d'administration acceptait n'importe quel jeton. Le contrôle d'accès auquel elle était confrontée acceptait tout jeton valide provenant de notre serveur OAuth : sans exiger aucune autorisation, sans vérifier que le jeton était bien destiné à l'API d'administration et sans vérifier l'identité du client. Elle copiait les autorisations que le jeton déclarait posséder dans les informations d'identification utilisées par le serveur d'administration.
Le serveur administratif se fiait au libellé des autorisations. Si le libellé indiquait « administrateur », vous étiez administrateur. Il n'y avait aucune vérification permettant de s'assurer que la personne derrière le jeton était bien un administrateur connu.
Combinées, ces trois failles permettaient de s'en sortir avec un simple compte gratuit et un navigateur. Aucun compte ni identifiant du personnel n’a été utilisé, et il n’y avait pas de logiciel malveillant. C’est notre propre système d’identité qui a émis ces jetons, et c’est précisément pour cette raison qu’aucune alerte n’a été déclenchée. L’attaquant a d’abord tenté la voie la plus évidente — ajouter des autorisations dans la demande d’autorisation principale — et notre configuration l’a correctement rejetée. Il a ensuite essayé la page de consentement, et c’est par là qu’il a réussi à passer.
Pour quiconque audite une pile similaire, le contexte a son importance. La faille s’est ouverte en octobre 2023 à la suite de trois pull requests successives : la première a permis à l’API d’administration d’accepter des jetons OAuth tout en conservant une vérification d’éditeur distincte pour la protéger ; la deuxième a supprimé cette vérification d’éditeur ; la troisième a donné à tous les utilisateurs l’accès à la page de consentement OAuth. Une mise à jour de sécurité en mai 2026 (PR n° 158) a ajouté des exigences en matière d’autorisations administratives sur le serveur d’administration, mais elle lisait ces autorisations à partir du jeton lui-même, et la page de consentement continuait de permettre à n’importe qui de les y définir. 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'administration doivent comporter un identifiant délivré exclusivement pour l'API d'administration, que les jetons des clients 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) ; et les fonctions d'administration qui modifient les coordonnées peuvent être entièrement désactivées via la configuration, pour tous (PR n° 861).
Le code a été écrit en 2023, au sein de l'entreprise où la plateforme Blink a été développée depuis 2019, et il est devenu notre propriété en octobre 2024, lorsque Blink a changé de propriétaire et est devenue une entreprise indépendante. Deux des ingénieurs qui avaient développé la plateforme nous ont rejoints, mais pas ceux qui avaient codé le flux d’autorisation administrative ; par conséquent, personne au sein de l’équipe Blink ne savait pourquoi une vérification préalable des autorisations avait été mise en place. Au cours de l’année 2025, la majeure partie de notre travail d’ingénierie a consisté à séparer nos systèmes de ceux de cette entreprise, qui s’étaient entremêlés 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 relative aux règles MiCA de l’Union européenne 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 conservant moins d’argent de nos clients plutôt qu’en demandant davantage de licences : nous avons développé et lancé un portefeuille non dépositaire, retiré notre service de garde de plus de quarante juridictions et transféré des dizaines de milliers d’utilisateurs vers des comptes sur lesquels ils conservent eux-mêmes leurs clés. Notre article publié en juin sur le lancement des comptes non dépositaires décrit ce travail. Pour une équipe d’une vingtaine de personnes, cela a occupé la majeure partie de l’année.
Le renforcement du code dont nous avions hérité a été relégué au second plan par rapport à ces deux projets. Nous avons trop attendu. La première chose que nous avons modifiée a été la manière dont les failles de sécurité sont classées et attribuées.
La trésorerie d'exploitation élevée s'inscrit dans le même contexte. Nous l'avions maintenue à environ le double de son niveau habituel afin de disposer d'une réserve pour la migration, dont la première vague s'était achevée une ou deux semaines avant l'attaque. Nous ne l'avions pas encore réduite. C'est pourquoi la perte a pu être aussi importante. Depuis lors, nous l'avons ramenée à une fraction de ce niveau, et le solde d'exploitation de Lightning continue de diminuer.
L'attaquant a piraté 35 comptes en procédant de la même manière : modifier l'adresse e-mail ou le numéro de téléphone à l'aide des outils d'administration, demander un code d'accès, puis se connecter. Il a retiré des fonds de 24 d'entre eux. Sur neuf, il s'est heurté à un obstacle. Ces neuf comptes avaient activé l’authentification à deux facteurs — une application d’authentification sur le téléphone du titulaire — et, sur un compte protégé par l’authentification à deux facteurs, une session ouverte uniquement avec un code d’accès ne permet pas de transférer de l’argent. Nos registres montrent que les 18 tentatives de l’attaquant sur ces neuf comptes ont échoué précisément à ce niveau de contrôle. Aucune perte n’a été constatée sur aucun de ces comptes.
L'authentification à deux facteurs (2FA) n'a pas empêché le piratage de nos outils d'administration. En revanche, elle a empêché le vol de fonds sur les comptes individuels. Aucun des 24 comptes ayant subi une perte financière n'avait activé cette fonctionnalité. Nous aurions dû l'exiger pour les retraits importants et pour les comptes présentant des soldes élevés.
Si vous ne devez faire qu'une seule chose après avoir lu ceci, que ce soit celle-ci : Paramètres → Sécurité et confidentialité → Authentification à deux facteurs. Activez-la ensuite également dans votre messagerie, car c'est là que vous recevrez vos codes d'accès à Blink.
Dimanche, au lendemain de l’attaque, nous savions ce qui avait été dérobé et à qui, au satoshi près, après avoir recoupé les informations avec le grand livre, la blockchain et le nœud de Lightning, et le conseil d’administration avait décidé comment rembourser cette somme. Les actionnaires de Blink se sont engagés à avancer la totalité du montant en moins de 24 heures sous forme de prêt sans intérêt, qu’ils ont versé mercredi, et chaque actionnaire s’est vu proposer de financer sa part aux mêmes conditions. Jeudi 24 septembre, nous avons rétabli chaque solde affecté et remboursé les commissions que nous avions prélevées sur les retraits frauduleux. Les clients concernés ont reçu un message direct de notre part avant que nous ne fassions d’autres déclarations publiques, tout comme les personnes dont les données avaient été consultées.
Cette décision a été mûrement réfléchie. Notre priorité était de dédommager les utilisateurs ; le reste viendrait ensuite. Vendredi, nous avons informé nos actionnaires des faits mêmes que vous lisez actuellement, et nous avons retardé cette publication jusqu’à ce que les autorités aient reçu nos rapports : 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 et une notification adressée à l’autorité de régulation financière de Próspera.
Il y a deux événements de cette semaine que nous tenons à signaler. 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 dimanche et mercredi, il a continué à se connecter à quatre des comptes bloqués dont les coordonnées comportaient 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 d’abord les coordonnées, ferme toutes les sessions et ne débloque le compte qu’ensuite.
Nous ne sommes pas la première entreprise à absorber une telle perte et à dédommager ses 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 majeure partie des fonds des clients était déjà en stockage à froid avec signature multiple, répartie sur plusieurs continents ; le service fonctionne avec une réserve complète ; l’authentification à deux facteurs était disponible et nous encouragions depuis longtemps les utilisateurs à l’activer ; et les retraits étaient limités en fonction du niveau du compte. Presque tout cela a tenu bon : l’attaquant n’a jamais accédé au stockage à froid, n’a jamais touché à un compte non dépositaire et a échoué pour chaque compte doté de l’authentification à deux facteurs. Ce qui a échoué, concrètement, ce sont les vérifications d’autorisation des outils d’administration dont nous avions hérité, ainsi qu’un système de surveillance qui surveillait les pannes du service et non un administrateur effectuant une action qu’aucun administrateur ne devrait effectuer. Ce qui a échoué, de manière générale, ce sont nos priorités : le changement de propriété, puis la migration hors garde ont mobilisé la majeure partie de l’équipe, et le travail de sécurisation du code hérité a été relégué au second plan.
Ce que nous avons fait les premiers jours :
La mise à niveau de l'ensemble de la plateforme se poursuit.
Et deux engagements qui débutent aujourd’hui :
1.La récompense en cas de récupération. 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 nous fournirez : jusqu’à environ 1,65 BTC si la totalité était récupérée. Sur la totalité des fonds récupérés, 25 % supplémentaires seront reversés à Bitcoin Beach, Bitcoin Ekasi, Afribit Kibera et aux économies circulaires Bitcoin du Sud global qu’ils choisiront conjointement et qui pourraient avoir besoin d’un soutien supplémentaire. Cette offre n’a pas de date d’expiration ; écrivez à bounty@blinkbtc.com. La récompense n’est versée qu’à partir des fonds ayant été restitués à un portefeuille que nous contrôlons. Les fonds volés peuvent être restitués sur la blockchain à l’adresse bc1q5vek5m04l6v277t6exhrurylqsmtvg2l30pt99 ou par Lightning à l’adresse Lightning bounty@blink.sv.
2.Un canal dédié au signalement des problèmes de sécurité, avec des récompenses. Écrivez à bounty@blinkbtc.com. Nous accusons réception de chaque signalement dans un délai maximal de 72 heures, et notre équipe de sécurité prend le relais jusqu’à ce que le problème soit résolu. Les recherches menées de bonne foi sur le logiciel Blink sont les bienvenues, et nous n’entreprendrons aucune action à l’encontre de quiconque signale une vulnérabilité 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 sur blink.sv/bounty-terms. Ce canal a été créé à la suite de cet incident : chaque signalement doit être pris en compte, recevoir une réponse et être suivi par un responsable jusqu’à sa résolution.
Ces 50 % sont répartis en deux : 25 % reviennent à la personne qui fournit les informations permettant de récupérer les fonds, et les 25 % restants de tout ce qui sera récupéré iront à Bitcoin Beach, Bitcoin Ekasi, Afribit Kibera et aux économies circulaires de leur choix. Nous pensons que ces fonds sont très probablement perdus à jamais. Il est très difficile de récupérer des bitcoins volés ; c’est pourquoi, pour nous, tout montant récupéré constitue une grande victoire, et plus nous encouragerons de personnes à nous aider à retrouver l’auteur de l’attaque, mieux ce sera. Une personne comme celle-là ne devrait pas s’en tirer aussi facilement, et nous voulons que dépenser cet argent lui soit aussi difficile et pénible que possible.
Nous ajoutons ces 25 % supplémentaires parce que nous voulons rappeler à l’attaquant qu’il a volé de l’argent que nous et nos actionnaires, attachés à notre mission, aurions mille fois préféré consacrer à soutenir l’adoption du Bitcoin à la base et à encourager ceux qui construisent avec le Bitcoin au sein de communautés non bancarisées à travers le monde. Il devrait avoir honte.
Nous avons suivi sans interruption le parcours des fonds depuis le 19 septembre. Au 1er octobre, environ 0,87 BTC n’avaient toujours pas été transférés vers les adresses destinataires. Le reste a été transféré vers d’autres portefeuilles de l’attaquant, qui contiennent également des bitcoins n’ayant pas quitté Blink. Depuis ces portefeuilles, environ 5,05 BTC ont été transférés via 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 propre demande de conservation des données, datée du 22 septembre, est restée sans réponse, et nous avons demandé aux autorités d’obtenir les registres de ce service. Environ 0,012 BTC ont été déposés sur Binance, et l’équipe de sécurité de Binance collabore actuellement pour les bloquer. Comme des bitcoins appartenant à l’attaquant sont mélangés à ceux-ci, ces chiffres ne totalisent pas les 6,61 BTC. Les adresses sur la chaîne sont disponibles en annexe.
Notre code est open source, et des services que nous n'avons pas développés exploitent des déploiements dérivés de celui-ci. Le modèle vulnérable — un flux de consentement qui s'appuie sur la liste des autorisations du navigateur et un contrôle d'accès qui accepte tout jeton valide sans vérifier l'audience — est antérieur aux dépôts actuels de Blink et figure dans l'historique public archivé. Nous avons averti en privé les opérateurs des déploiements dérivés dont nous avons connaissance ; l’un d’entre eux a appliqué le correctif le jour même. Notre avis de sécurité concernant ce code est disponible sur GitHub à l’adresse github.com/blinkbitcoin/blink/security/advisories, avec un identifiant CVE en attente. Si vous exploitez une solution basée sur le code de Blink et que vous n’avez pas reçu 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 nous vous aiderons à effectuer cette vérification. 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 la machine. Si vous exploitez 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 fonctionné. Chacun d’entre eux nous avait confié son argent, ce qui est la seule raison d’être d’un dépositaire.
À nos clients, pour leur patience ; aux enquêteurs et aux plateformes d’échange qui nous ont aidés en l’espace de quelques heures ; aux actionnaires qui ont soutenu l’entreprise sans hésiter ; et à l’équipe qui a sacrifié tout son samedi et n’a pas fermé l’œil de la nuit : merci. Nous regagnerons la confiance comme nous l’avons gagnée à El Zonte : en étant présents et en veillant à ce que les paiements soient effectués, jour après jour.
Mon argent a-t-il été exposé à un risque ? Si votre compte est ouvert et que vous n’avez pas reçu de message de notre part, cela signifie que nous n’avons aucune trace indiquant que le pirate ait consulté les données de votre compte, et qu’aucune somme n’a été prélevée. Jusqu’à sa fermeture le 19 septembre, cette faille pouvait être exploitée contre n’importe quel compte avec garde, même si, sur un compte doté de l’authentification à deux facteurs (2FA), elle n’aurait pas permis de transférer des fonds. La plupart des fonds des clients sont stockés en cold storage, auquel les outils d'administration n'ont pas accès. Si vous disposez d'un compte non dépositaire, vos clés n'ont jamais été stockées sur nos serveurs et le pirate n'avait rien à dérober.
L'attaquant a-t-il mis la main sur mes données ? Il a consulté les données de 3 817 comptes. Nous avons écrit à chaque titulaire que nous avons pu contacter pour l'informer de ce qui avait été constaté. Si votre compte est actif et que vous n'avez pas reçu ce message, c'est qu'il ne figurait pas parmi ceux-là. Vous pouvez toujours nous demander quelles informations ont été consultées sur votre compte, le cas échéant : support@blink.sv.
Pourquoi le système de surveillance de Blink n'a-t-il pas détecté l'attaque ? Nos alertes étaient conçues pour détecter les interruptions de service. Elles ne prévoyaient aucune règle pour le cas où un administrateur effectuerait des actions qu'aucun administrateur ne devrait faire, 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 opérationnel ? Nous avions environ doublé notre solde opérationnel afin de disposer d'une réserve pour la migration vers des comptes sans garde, et nous ne l'avions pas réduit après la fin de la première vague. Il ne représente désormais qu'une fraction de ce niveau, et nous ne publierons pas le chiffre.
« L'authentification à deux facteurs (2FA) m'aurait-elle protégé ? Dans le cas présent, oui. Tous les comptes qui disposaient de cette fonctionnalité ont conservé leur argent ; aucun des comptes qui ont subi des pertes ne l'avait activée. Elle n'empêchera pas toutes les attaques, mais elle a permis d'en bloquer une. Activez-la. »
Dois-je passer à un compte non dépositaire ? Si vous préférez conserver vos propres clés, oui : c’est pour cela qu’ils existent, et personne chez Blink, ni aucune personne parvenant à accéder à Blink, ne peut déplacer les fonds que vous conservez. Ce n’est pas obligatoire, toutes les fonctionnalités ne sont pas encore disponibles et leur accessibilité dépend de votre région. Si vous conservez un compte dépositaire, activez l’authentification à deux facteurs (2FA).
Qui a financé tout cela ? Les actionnaires de Blink, grâce à un prêt sans intérêt accordé en moins de 24 heures et versé le 23 septembre. Ce ne sont ni les clients, ni les réserves des clients. Blink continue de fonctionner avec une réserve intégrale : chaque solde est couvert à 100 %.
J'ai découvert une faille de sécurité dans Blink. Que dois-je faire ? Écrivez à bounty@blinkbtc.com. Nous vous répondrons dans un délai maximum de 72 heures ; votre rapport sera pris en charge par un responsable jusqu'à sa résolution, et les découvertes critiques donnent lieu à une récompense.
Nous ajouterons ici, en indiquant la date, les dernières informations concernant la récupération, la récompense et toute correction apportée à cette publication.
Les adresses suivantes ont reçu des retraits sur la chaîne. Nous demandons aux plateformes d'échange et aux chercheurs de filtrer les dépôts provenant de ces adresses et d'écrire à bounty@blinkbtc.com. (Les fonds sortis via Lightning ont été transférés vers des portefeuilles Lightning contrôlés par le pirate et font l'objet d'un suivi distinct.)
Total sur la chaîne : 4,62685758 BTC reçus à ces adresses lors de 14 retraits, dont sept vers la première adresse. Notre système de paiement regroupe les retraits ; ainsi, les 14 retraits ont été effectués en 12 transactions sur la chaîne. Les 1,98399667 BTC restants sur un total de 6,61085425 BTC ont été transférés via Lightning.
Commencez à recevoir et à envoyer des bitcoins dès maintenant
