Les Blockchains sont avant tout des architectures techniques possédant leurs propres infrastructures, protocoles, et applications. Elles se projettent de fait sur l’ensemble du modèle OSI, dont chacune des couches est exposée aux éventuelles attaques.
Si les blockchains savent résister aux cyber attaques traditionnelles, le monde du hacking a naturellement su élaborer de toutes pièces des attaques spécifiques aux Blockchains.
Vulnérabilités réseau
Les Blockchain reposent sur des infrastructures distribuées (P2P) garantissant en théorie une réplication et une validation de l’information. En pratique, un réseau distribué n’offre pas une réplication parfaite (cf. théorème CAP) et chaque nœud d’une blockchain n’est connecté qu’à un nombre limité de ses pairs : 9 nœuds pour le réseau Bitcoin et 13 pour Ethereum par exemple. Ainsi, il est possible d’opérer des attaques niveau réseau sur des blockchains :
Attaque par déni de service (DOS)
L’attaquant perturbe le réseau en inondant les nœuds du réseau avec des nombreuses transactions de faible valeur. Cette saturation d’information peut faire tomber un nœud et le sortir du réseau, au profit d’autres nœuds contrôlés par l’attaquant. La Blockchain Bitcoin a été victime d’une telle attaque en Septembre 2018. Cf. CVE-2018-17144
Attaque Sybil
L’attaquant prend le contrôle de plusieurs nœuds du réseau, entourant la victime de nœuds malveillants et l’isolant du reste du réseau. Les nœuds corrompus minent et valident ce qu’ils veulent et orientent la blockchain dans le sens de l’attaquant, permettant par exemple des attaques de type double dépense.
Attaque éclipse
L’attaquant modifie les informations de connections sortantes du nœud de la victime, forçant ses requêtes à être adressées à des adresses IP qu’il contrôle. Ce « node spoofing » permet d’isoler la cible et de ne lui envoyer que les informations de son choix : double dépense, fausses transactions.
Vulnérabilités de protocole
La valeur ajoutée des blockchains repose principalement sur leurs protocoles. Ces derniers sont bien souvent disponibles en open source, et les contributions sont nombreuses pour répondre à la frénésie de l’innovation. Encore peu éprouvés, ces protocoles s’exposent parfois à des vulnérabilités de type « zero day ».
Faille d’implémentation
Le 15 aout 2010, la blockchain du Bitcoin a été victime d’une faille dans l’implémentation de son protocole : une vulnérabilité de type « value overflow » a permis de créer 184 milliards de Bitcoins à partir de rien (la limite totale de Bitcoins étant de 21 millions…). Le code ne vérifiait pas que des montants trop importants pouvaient dépasser la limite, devenir négatifs et ainsi être validés. L’incident a été corrigé et la transaction annulée. Cf. CVE-2010-5139
Forge de monnaie à partir de rien
Dans l’exemple précédent, il a été facile de repérer l’incident, de corriger le code, et d’annuler la transaction en revenant sur le bloc fautif. En revanche, quand ce type de malveillance arrive sur des cryptomonnaies à fort anonymat (Monero, Zcash), il est très difficile de prouver que de la monnaie a été créée (minée ou reçue) légitimement et non à partir de rien (« from thin air ») puisque par définition, ces protocoles offrent peu de traçabilité publique.
Collision de Hash
Comme vu précédemment, les Blockchain s’appuient fortement sur les fonctions de hash pour garantir l’intégrité et l’inaltérabilité des données de transactions.
Nous avons vu que les fonctions de hash généraient une signature unique… Mais en réalité pas totalement. Des collisions peuvent survenir, c’est-à-dire que 2 données différentes pourraient avoir le même hash.
En pratique, les algorithmes de hash garantissent que ces collisions sont très peu probables (inférieures à une chance sur 1066). En théorie, cela reste possible, et on pourrait imaginer le scénario suivant :
- L’attaquant altère une donnée de blockchain dans le passé (modification d’une transaction)
- L’attaquant trouve une collision de hash qui permet au bloc de conserver son hash initial malgré sa modification.
- Le bloc conserve sa signature et ne brise pas en cascade la chaine de hash des blocs suivants.
- L’altération est implicitement validée par l’ensemble du réseau puisque ce bloc a déjà été validé dans le passé.
Il convient donc d’utiliser des fonctions de hash reconnues et éprouvées (ex : SHA256) et surtout de ne pas tenter de réinventer sa propre fonction, comme a voulu le faire la blockchain IOTA, leur fonction de Hash s’étant avérée beaucoup trop sensible aux collisions.
Exploitation de consensus
Une des vulnérabilités les plus connues de la blockchain repose sur le consensus le plus utilisé : la preuve de travail (Proof Of Work). Dans ce protocole, le mineur qui créera le prochain bloc est déterminé au hasard, au prorata de la puissance de calcul qu’il met à contribution pour le réseau. Un mineur qui possède 1% de la puissance de calcul totale du réseau a donc 1% de chance de miner le prochain bloc.
Ainsi, un attaquant qui possèderait 51%, c’est-à-dire plus de la moitié de la puissance de calcul pourrait valider les transactions de son choix et opérer une attaque de « double dépense » :
Plusieurs Blockchains ont déjà été victimes d’attaques de ce type :
- Avril 2018 : Verge (24O K$ détournés)
- Mai 2018 : BTC Gold (18 M$ détournés)
- Juin 2018 : ZenCash (600 K$ détournés)
Une des solutions consiste à adopter un autre consensus moins sensible aux attaques de ce type (ex : Proof of Stake) ou un consensus privé (ex : Ripple).
Applications
Même si les fondations des protocoles de blockchain sont sécurisées et verrouillées, ces dernières mettent à disposition des interfaces d’instanciations et d’interactions qui multiplient les surfaces d’attaques. C’est tout particulièrement le cas avec les Blockchains proposant des interfaces de programmation : les fameux Smart Contracts.
Cette couche applicative crée une dimension supplémentaire de vulnérabilités qui ont depuis longtemps été exploitées. On ne compte plus les attaques sur les plateformes, les marchés, et plus globalement les services tierces s’appuyant sur des Blockchains :
DAO
DAO était une Organisation Autonome Décentralisée lancée sur la Blockchain Ethereum en 2016, proposant un modèle d’entreprise décentralisé, sans structure de gestion ni conseil d’administration. Le concept était novateur et son financement participatif a levé l’équivalent de 120 millions de $. Mais l’aventure a tourné court lorsque le service s’est fait hacker et voler un tiers de ses fonds quelques semaines plus tard. (60 millions de $)
La vulnérabilité exploitée était applicative : une faille dans le code permettait un appel récursif à une fonction de retrait de fonds, qui opérait le transfert du montant avant de mettre à jour la balance des comptes.
Il est intéressant de noter que ce Hack a été corrigé puis résolu par la manière forte : Afin de récupérer les fonds volés, la communauté Ethereum a choisi de revenir dans le temps et de reprendre la Blockchain avant l’exploitation de la vulnérabilité, via un « hard fork » qui a donné naissance à « Ethereum Classic ».
Mt. Gox
La plateforme d’échange Mt. Gox a subi en 2014 une attaque menant à sa faillite. La vulnérabilité était fondée sur la « malléabilité de transactions » de la Blockchain Bitcoin, permettant à un attaquant de changer l’identifiant d’une transaction avant sa confirmation. L’attaquant, qui avait pu récupérer une clé privée du wallet central a pu forger une signature valide et prétendre être le bénéficiaire de transactions avant même leur validation dans un bloc. On estime que 450 millions de $ ont ainsi été détournés.
Parity
Parity est un portefeuille dédié à la blockchain Ethereum. Cette surcouche propose des services comme la gestion « MultiSgnature » des portefeuilles Ethereum, permettant d’assigner plusieurs clés d’accès à un même portefeuille.
En juillet 2017, le portefeuille Parity a été hacké. La vulnérabilité applicative venait du code du Smart Contract qui était hérité (importation d’une bibliothèque externe) dans l’implémentation de Parity. La fonction « constructeur » du portefeuille pouvait être appelée à nouveau après son instanciation et permettait à l’attaquant de devenir le propriétaire du portefeuille. Une fois propriétaire, rien de plus simple que d’en vider le contenu.
Notons qu’un groupe de White Hackers (hackers éthiques), a rapidement identifié puis exploité cette même faille pour hacker les portefeuilles encore vulnérables et mettre sous verrou les fonds restants. On estime que 32 millions de $ ont ainsi été détournés.
Ces exploits restent malheureusement assez fréquents et leur impact souvent couteux. Gardons à l’esprit que ces vulnérabilités peuvent survenir chez les meilleurs, tant les environnements de développement des Blockchain sont encore complexes et les technos encore peu matures.
Quelques bonnes pratiques pour éviter ce type de vulnérabilités applicatives :
- Utiliser les standards ERC des Smart Contracts, qui sont audités, éprouvés, et éviteront une majorité du rework et de générer de nouvelles failles.
- Utiliser les dernières versions du compilateur de Solidity qui alertent sur les failles connues.
- Vérifier le code source des Smart Contracts utilisés ou hérités (avec Etherscan par exemple)
- Utiliser des compilateurs à Preuve Formelle qui garantissent la sortie attendue du Smart Contract (ex : langage OCaml, ou le Michelson de TEZOS).
Humain
Sur une Blockchain, les utilisateurs doivent conserver précieusement les clés privées qui leur permettent d’accéder à leur portefeuille.
Ces clés sont doublement précieuses :
- L’attaquant prétend donner un certain montant à sa cible, et récupère la contrepartie en échange.« Charlie donne 5 BTC à Alice» (et récupère des Euros en échange par exemple).
- Il effectue en parallèle une autre transaction dans laquelle il renvoie le même montant à un complice. « Charlie donne 5 BTC à Bob ».
- L’attaquant manipule la blockchain et grâce à ses 51%, l’oriente à sa guise de manière à invalider la 1ère transaction « Charlie donne 5 BTC à Alice » au profit de la seconde « Charlie donne 5 BTC à Bob ».
- Alice réalise – trop tard – que la transaction « Charlie donne 5 BTC à Alice » n’est plus valide. Elle a perdu sa contrepartie.
Ownership
La majorité des vols de cryptomonnaies sont imputables à des vols de clés privées. L’utilisateur étant totalement responsable de ses clés (True ownership), il en est le seul gestionnaire, et offre par conséquent un angle d’attaque idéal : Cette somme d’utilisateurs individuels représente une surface d’attaque étendue pour les attaquants, et la majorité des utilisateurs n’ont pas les compétences nécessaires en matière de cybersécurité pour sécuriser correctement l’accès à leurs clés.
La conservation des clés n’est pas triviale et si les portefeuilles électroniques sont une bonne solution, il s’agit de bien les choisir afin de minimiser les risques.
Portefeuilles corrompus
De nombreux portefeuilles sont disponibles sous forme d’applications pour smartphones. Il a été révélé que certains d’entre eux, directement développés par des attaquants, envoient les clés ou siphonnent les comptes des victimes.
Ex : les applications « Trezor Mobile Wallet » et « Coin Wallet » qui transmettent les logins et mots de passes de la victime sur le site de l’attaquant. Et plus récemment, GetMonero, le wallet de Monero a été piraté en novembre 2019 : la version malveillante interceptait les codes du portefeuille et les envoyait à l’attaquant.
Il vaut mieux privilégier les portefeuilles physiques (hardware wallets) contenant un Secure Element qui stockent la clé et valident les transactions par confirmation physique (ex : Ledger)
Portefeuilles légers
Certains portefeuilles applicatifs, non malveillants par essence, n’utilisent pas les protocoles les plus sécurisés et s’exposent ainsi à des exploitations de failles de protocole – Blockchain ou plus classiquement HTTP.
Par exemple, les portefeuilles légers comme Mycelium ou Electrum, afin de d’optimiser le poids de l’application et le temps de validation, n’utilisent pas le protocole Bitcoin complet mais s’appuient sur un protocole léger de vérification des transactions : le « simple payment verification » (SPV). Ce dernier ne télécharge pas l’ensemble de la blockchain mais uniquement les entêtes de blocks et demande la validation à des nœuds aléatoires.
De fait, la confiance dans nœuds n’est pas certifiée : une attaque de type « Man in the Middle » (MitM) peut bloquer ou valider certaines transactions, voire modifier les montants en manipulant les méthodes HTTP.
Les protections sont plus complexes à mettre en place dans ce cas de figure. S’il semble difficile de se connecter à son propre nœud blockchain, on peut toujours se connecter en VPN, ou a minima éviter l’envoi de transactions via les Wi-Fi publics pour éviter les attaques MitM.
Vulnérabilités structurelles
Certaines Blockchains présentent par ailleurs des vulnérabilités structurelles, dont on a souvent dit qu’elles mèneraient à leur perte à long terme :
Recentralisation
Si l’on regarde la répartition de la puissance de calcul (hashrate) de la blockchain Bitcoin, on constate qu’une grande majorité est aujourd’hui localisée en Chine.
La Blockchain n’a pas été conçue ni prévue pour une telle recentralisation, qu’elle soit géographique ou économique. Outre les attaques à 51% qui pourraient être opérées via de tels regroupements, toute manipulation de la blockchain serait à craindre dans l’absolu.
Les mineurs chinois ont un accès facilité à de l’énergie à bas prix, et le consensus (Proof of Work) devient hackable pour qui a les moyens de produire du hashrate. Idéalement, un consensus non contrôlable devrait reposer sur quelque chose qui ne peut pas s’acheter.
Gouvernance
La Blockchain est décentralisée par définition. Cela sous-entend une absence structurelle de gouvernance, qui a déjà causé son lot de dégâts dans le milieu des cryptomonnaies. Sans gouvernance, difficile de prendre des décisions ou d’imposer à la communauté des contraintes, qui pourraient pourtant s’avérer nécessaires vis-à-vis de la sécurité et/ou de la régulation.
Les Forks de blockchain sont donc légion, que ce soit pour imposer une nouvelle fonctionnalité (Bitcoin Cash, Bitcoin Gold, Segwit, etc.) ou pour corriger une vulnérabilité et annuler les effets d’une attaque (Ethereum Classic).
De nouvelles blockchains adressent ce problème, en proposant une gouvernance inscrite par construction dans l’algorithme. C’est le cas de la Blockchain française TEZOS, qui est auto-régulée par ses utilisateurs : les évolutions sont votées par la communauté, les développeurs soumettent des propositions pour faire évoluer le protocole, chaque proposition est testée, votée, puis implémentée de manière décentralisée.
Cet auto-amendement permet à la blockchain TEZOS d’éviter les forks et la division de la communauté.
En conclusion
La plupart de ces critiques sont légitimes mais concernent souvent les blockchains les plus anciennes – et aussi les plus populaires par conséquent. Ethereum aura bientôt 5 ans et le Bitcoin en a passé le cap des 10 ans… autant dire une éternité dans le monde de l’innovation galopante des systèmes d’informations.
Aujourd’hui, de nouvelles blockchains adressent aisément ces failles structurelles par de nouveaux consensus, de nouveaux protocoles, de nouveaux types de gouvernance. Sans parler des blockchains privées qui couvrent encore la majorité des applications blockchain industrielles et qui, par définition, adoptent les protocoles et consensus qui leur conviennent le mieux afin de garantir toutes ces contraintes de sécurité, régulation et gouvernance, quitte à s’éloigner des fondamentaux activistes de la Blockchain tel que Satoshi Nakamoto les avait originellement pensés.
