Faille du portefeuille matériel Coldcard : plus de 88 M$ de bitcoins dérobés
Résumé du marché par IA
Une faille divulguée dans la génération de clés d'un portefeuille matériel Coldcard aurait permis à des attaquants de voler plus de 88 M$ en BTC, l'exploitation étant décrite comme en cours et les fonds s'agrégeant on-chain. Sans qu'il s'agisse d'un problème du Bitcoin au niveau du protocole, l'incident peut peser sur le sentiment à court terme en accentuant les risques de conservation et opérationnels, pouvant inciter à une accélération des migrations vers l'auto-conservation, à un contrôle accru des chaînes d'approvisionnement des portefeuilles matériels et à une surveillance renforcée des adresses liées par les plateformes d'échange et les équipes de conformité.
Niveau d'impact
● Élevé
Actifs concernés
BTC/USDT+0.90%
Infos de l'IA · BTC/USDTInfos de l'IA
▼ Baissier
Trader maintenant
⚠️ Les infos générées par l'IA sont basées sur des contenus d'actualité et fournies à titre informatif uniquement. Elles ne constituent pas des conseils en investissement et ne reflètent pas les positions de BingX. Investir comporte des risques. Tradez de manière responsable.
Les pertes liées à l'exploitation d'une vulnérabilité affectant les portefeuilles matériels Coldcard ont désormais dépassé 88 millions de dollars, alors que l'attaque se poursuit. Le 31 juillet, environ 500 appareils Coldcard auraient été compromis, entraînant le vol de 594 bitcoins, soit près de 38 millions de dollars.
Coinkite, fabricant de Coldcard, a confirmé une faille de sécurité dans le processus de génération des clés, touchant plusieurs générations de produits : Coldcard Mk2, Mk3, Mk4, Q et Mk5. Les utilisateurs sont invités à transférer leurs fonds vers une autre adresse dès que possible.
I. Analyse de la vulnérabilité
L'examen de l'historique des commits du firmware Coldcard met en évidence une modification, dans le commit 37e4af5451c260c1e7d429fe8972c4cb5e68ee59, de plusieurs sections liées à la configuration MK4, notamment dans mpconfigboard.h :
"// We have our own version of this code. #define MICROPY_HW_ENABLE_RNG (0)".
Côté MicroPython STM32, cette macro pilote le chemin de compilation pour la liaison du générateur matériel de nombres aléatoires (RNG) par défaut et l'implémentation générique du "random". La valeur 0 empêche l'utilisation du RNG matériel par défaut comme backend pour rng_get(). Les commentaires indiquent que l'équipe doit fournir sa propre implémentation ; or, le fichier rng.h personnalisé ne déclare que deux objets MicroPython :
MP_DECLARE_CONST_FUN_OBJ_0(pyb_rng_get_obj);
MP_DECLARE_CONST_FUN_OBJ_1(pyb_rng_get_bytes_obj);
Leur implémentation montre l'intention d'utiliser le RNG matériel, mais uniquement lorsque pyb_rng_get* (ou random_buffer() en interne) est appelé.
Lors de la création d'un portefeuille, le code invoqué passe par shared/seed.py :
async def make_new_wallet(nwords):
await ux_dramatic_pause('Generating...', 3)
seed = generate_seed()
words = await approve_word_list(seed, nwords)
if words:
await commit_new_words(words)
Cette séquence redirige vers shared/random.py. Dans des versions antérieures, random.py s'appuyait explicitement sur ngu.random et conservait notamment : "# bytes = ngu.random.bytes". L'initialisation du portefeuille utilise random.bytes, et non pyb.rng(); l'objet pyb_rng_get_obj personnalisé ne remplace donc pas automatiquement random.bytes.
Avec MICROPY_HW_ENABLE_RNG réglé sur 0, la génération de portefeuille n'utilise pas le RNG matériel et appelle à la place la fonction de repli pyb_rng_yasmarang issue de micropython/ports/stm32/rng.c. Ce pyb_rng_yasmarang est un générateur pseudo-aléatoire, jugé très insuffisant pour produire une graine (seed) de portefeuille matériel, car un attaquant peut remonter la clé par force brute.
Coinkite a depuis explicitement exclu stm32/rng.c dans le Makefile afin d'éviter la compilation du PRNG de repli de MicroPython : "Do not compile MicroPython's fallback PRNG", avec notamment l'indication : "SKIP stm32/rng.c".
II. Suivi des fonds dérobés
Selon l'analyse, des fonds de plusieurs portefeuilles victimes ont déjà été transférés puis agrégés sur plusieurs adresses, sans étape de blanchiment supplémentaire à ce stade. Sur la base de renseignements de menace et d'analyses on-chain, Beosin Trace identifie notamment les adresses d'agrégation suivantes :
- bc1qq85v2c926eg6pgxhwp6q7lf6cnsz80qs3fcu9r (562 BTC)
- bc1qx76cae2706qd5q576feh7xq8rfcsjpf2htfhe3 (398.47 BTC)
D'autres adresses présenteraient un schéma de flux similaire et n'auraient pas encore procédé à de nouveaux transferts :
- bc1q8jy96fe5lf8vfugydnte3cguk92gpev7kwtp3q (89.62 BTC)
- bc1q0rvn88w08j75k4h48lf9fvhan7unjp7vjf5q6m (64.9 BTC)
- bc1qtfrwa4j6rmj9rsgspv6a0yjumkg39js2numu75 (45.9 BTC)
- bc1qmd5m5ktv7m5ffujxv4248fxv36myvdx79n8jp6 (30.18 BTC)
Les attaques visant Coldcard restant actives, l'équipe Beosin indique poursuivre la surveillance des adresses d'agrégation et l'analyse des mouvements associés.
III. Conclusion
Cet incident de sécurité majeur provient d'une erreur d'implémentation : l'utilisation d'un générateur pseudo-aléatoire lors de l'étape critique de génération de la seed. L'équipe de développement est appelée à renforcer les tests, l'audit et la revue de code. Les utilisateurs de Coldcard sont invités à déplacer rapidement leurs actifs et à suivre de près les prochaines annonces de sécurité de Coinkite.
Beosin se présente comme une entreprise spécialisée dans la sécurité blockchain et la conformité réglementaire, proposant notamment des audits de contrats intelligents avant lancement, une surveillance et un blocage des risques en temps réel, la récupération d'actifs, des solutions AML pour actifs virtuels et des services d'investigation et de traçage. Beosin indique fournir des produits et services de conformité et de sécurité "one-stop" à des régulateurs et forces de l'ordre dans plus de 20 pays et régions, ainsi qu'à plus de 200 prestataires de services sur actifs virtuels et à plus de 4"500 projets Web3.