Analyse de risques d'une blockchain - Partie 2
Dans la première partie de cet article, nous avons présenté un système blockchain. Intéressons-nous aux différents risques qui pèsent sur elle. Les risques sont répartis en 3 catégories qui sont les bases d’un système blockchain. La première vient du fait qu’il s’agisse d’un logiciel. La seconde est du au système décentralisé qui doit peser sur la blockchain et le dernier concerne l’environnement autours du logiciel.
Risques logiciels
Vulnérabilité du code
Une blockchain repose avant tout sur un programme présent sur chaque ordinateur qui décrit les fonctions de la blockchain. Le code de ce logiciel peut contenir diverses vulnérabilités (top 10 OWASP, top 25 SANS) qui pourraient être exploitées. Les possibilités de vulnérabilités ainsi que les impacts sont quasi infinies et dépendent de la technologie utilisée pour coder la blockchain et son utilisation. Voici une proposition de 3 vulnérabilités qui feront l’apparition au cours de la vie d’une blockchain.
La première vulnérabilité pourrait être un bufferoverflow. Les informations reçues n’étant pas forcément délimité par un modèle strict, il serait possible de faire crasher le système ou de modifier son comportement. Il serait possible aussi de trouver une injection de code qui permettrait l’interprétation d’un paquet malicieux pour qu’il puisse compromettre sa cible. L’attaquant pourrait viser à exploiter cette vulnérabilité pour contrôler l’ordinateur cible ou extraire des informations sensibles. Il sera donc important d’avoir un système renforcé au niveau de la sécurité qui isolera le fonctionnement de la blockchain. La dernière hypothèse serait la présence d’une vulnérabilité dans les fonctions cryptographiques du logiciel. Il y a besoin de créer, stocker et gérer des clefs de chiffrements privés. Ce sont des fonctions mathématiques très complexe à mettre en place et à garantir fiable. Il faudra donc s’assurer que le logiciel utilisé dans la blockchain génère des clefs aléatoires tout en évitant les attaques par canaux secondaire. Il faudra aussi s’assurer que les fonctions de chiffrements en particulier la signature ne soit pas détour nables.
L’exploitation de l’une de ces vulnérabilités aurait un impact majeur sur la disponibilité et l’intégrité d’une blockchain. Bien que la probabilité d’apparition d’une de ces vulnérabilités soit élevée, il est possible d’y remédier facilement. La formation des développeurs, et des tests de sécurité du code ou un pentest sont des mesures de remédiations faciles à mettre en place pour réduire la probabilité d’existence d’une vulnérabilité exploitable.
Mise à jour du logiciel
Aujourd’hui les logiciels sont mis à jour régulièrement pour ajouter de nouvelles fonctionnalités ou corriger des vulnérabilités. Une blockchain ne fera pas d’exception. Tant que le cœur du système n’est pas modifié, une mise à jour sera valable. La mise à disposition d’une mise à jour suit le schéma suivant. Si un attaquant souhaite utiliser ce système il aura trois possibilités différentes d’exploiter ce système.
S’il souhaite attaquer un seul utilisateur, le plus simple sera de mettre en place une attaque d’homme du milieu (Man in the middle) pour rediriger la cible vers un serveur contrôlé par l’attaquant. Cette attaque aura l’avantage d’être discrète pour le reste du réseau qui ne sera pas au courant que la cible a été attaqué. L’attaquant pourra alors voler les clefs privées de la cible, ou uniquement l’empêcher d’accéder à la blockchain tout dépendra du logiciel que l’attaquant aura mis en place. Pour se prévenir d’une attaque de ce type, il sera essentiel d’utiliser des protocoles sécurisés lors des échanges avec une signature du serveur de mise à jour.
Si l’attaquant souhaite atteindre plus de membres de la blockchain, il visera à compromettre le serveur de mise à jour ou de faire un détournement massif du trafic vers son serveur malicieux (en détournant les requêtes DNS par exemple). Cette attaque aura très peu de chance de ne pas être remarqué par la communauté autours de la blockchain. Une attaque de ce type sera d’autant plus difficile si le serveur à été durci et que la console d’administration du nom de domaine est bien protégée.
Risques liés à la décentralisation de la blockchain
Le système de la blockchain a dans un premier temps était mis en avant pour contrer la centralisation des banques dans un système monétaire : le bitcoin. Cette décentralisation est possible grâce à un système de mineur et un logiciel réparti entre tous les acteurs d’une blockchain. Cependant cette répartition est complexe à mettre en oeuvre et n’est pas sans risque sur un logiciel.
Déni de service
Pour que le fonctionnement P2P fonctionne correctement, chaque utilisateur a besoin de connaitre les interlocuteurs avec qui il peut interagir. Pour se faire chaque utilisateur détiens une liste avec les adresses publiques (IP) de chaque utilisateur qu’il peut communiquer à qui le demande.
Une fois l’adresse de la cible identifiée, il serait très simple de pratiquer une attaque par déni de service la visant. L’accès à la blockchain serait fortement compromis empêchant de mettre à jour l’état de la chaine ou de réaliser des transactions. Si la cible est un mineur, elle perdrait un avantage compétitif vis-à-vis des autres mineurs pour valider des transactions. Elle ne recevrait pas les demandes de nouvelles transactions à valider et ses efforts porteraient sur une chaine obsolète par rapport au reste du réseau.
Si un attaquant souhaite impacter tout l’écosystème de la blockchain avec une attaque par déni de service simple, il lui faudrait une puissance de calcul relativement plus importante que la puissance du réseau. Il pourrait aussi envisager de demander en masse la réalisation de transaction afin de saturer le réseau et empêcher d’autres transactions. Il faut relativiser cette deuxième option car la mise en place de mesures de protection en analysant les demandes de transactions sont déjà en places dans les systèmes actuels. Cependant une attaque par déni de service sur les mineurs ayant le plus de capacité de calcul ralentirai fortement la validation des transactions impactant l’efficacité de la blockchain.
Faux positif d’une transaction
L’objectif premier d’une blockchain est de réaliser des transactions dans un environnement de non confiance. Les transactions peuvent avoir plusieurs objectifs. Dans le cas des crypto-monnaies on échange un token contre un produit ou un service. Pour éviter les collisions lors de la validation simultanée d’un bloc, une blockchain dont le processus de consensus est une « proof of work », il est recommandé d’attendre de recevoir une chaine avec 4 ou 5 blocs valident après le bloc contenant la transaction voulue.
Si un attaquant souhaite arnaquer un vendeur qui accepte les cryptomonnaies, il pourrait tenter de transmettre une blockchain frauduleuse auprès du vendeur. Il faudrait que la blockchain contienne un bloc avec la transaction et suffisamment de blocs valides pour que le vendeur est confiance en elle. Afin d’augmenter le succès de cette attaque, il faudrait la coupler avec une attaque par déni de service pour que le vendeur ne mette pas à jour sa chaine.
Pour protéger le vendeur l’application qu’il utilise devrait vérifier la chaine auprès de deux sources authentifiées distinctes au minimum. Le vendeur pourrait de lui-même prendre l’initiative de vérifier la validité de la chaine sur un autre canal que l’application qu’il utilise car il serait plus difficile pour l’attaquant de compromettre ainsi plusieurs fournisseurs de la chaine.
Il nous reste à étudier les risques liés à l’environnement. Je vous invite à rejoindre la troisième et dernière partie de cette suite d’articles pour découvrir les découvrir et avoir un aperçu consolidé des risques de la blockchain.
Nota bene: Je souhaite remercier les consultants qui ont travaillé avec moi sur ce sujet afin d’arriver à ce résultat.