ScaleBit sélection approfondie : analyse des vulnérabilités de sécurité et liste des surfaces d'attaque dans l'écosystème blockchain
TechFlow SélectionTechFlow Sélection
ScaleBit sélection approfondie : analyse des vulnérabilités de sécurité et liste des surfaces d'attaque dans l'écosystème blockchain
Ce rapport analyse en détail les diverses vulnérabilités de sécurité et surfaces d'attaque actuellement existantes.
Dédié à des analyses Web3 approfondiesLa technologie blockchain, bien qu'elle présente un énorme potentiel en matière de décentralisation, de sécurité et de mécanismes de confiance, abrite encore divers risques de sécurité au sein de son écosystème. Des vulnérabilités variées dans les communications inter-chaînes L1/L2 (par exemple, l'absence de prise en compte du rollback de blocs, une gestion inadéquate des échecs de transactions, des défauts dans la vérification par client léger), aux risques liés à l'ordre des modules, à l'utilisation des nombres aléatoires ou au rollback de transactions sur les chaînes d'applications Cosmos, en passant par les dangers posés par la construction de scripts, le traitement UTXO ou le rollback dans l'écosystème d'extension de Bitcoin, autant de défis majeurs pour les applications blockchain. Par ailleurs, des erreurs courantes dans les contrats intelligents ou les langages de programmation généraux — comme le dépassement d'entiers, les boucles infinies, les conditions de course ou les plantages anormaux — menacent gravement la disponibilité et la sécurité du système.
En outre, la fragilité de l'architecture réseau P2P (telles que les attaques Sybil ou Eclipse) et les attaques DoS peuvent nuire à l'efficacité et à la fiabilité du système blockchain. Les failles cryptographiques (algorithmes de hachage non sécurisés, algorithmes de signature faibles, génération non sécurisée de nombres aléatoires, etc.) compromettent davantage la confidentialité et l'intégrité des données. Une mauvaise gestion au niveau du registre — concernant notamment la mempool des transactions, les blocs orphelins ou l'arbre de Merkle — peut entraîner une incohérence des données sur la chaîne ou des risques financiers. Enfin, un modèle économique ou un mécanisme de gouvernance mal conçu peut provoquer un déséquilibre des incitations ou même une fragmentation du réseau, permettant aux attaquants d'exploiter ces faiblesses pour affaiblir la stabilité du système.
Face à ces risques, seule une compréhension approfondie et des mesures préventives rigoureuses permettront d’assurer la sécurité et la durabilité de l’écosystème blockchain en constante évolution. À la fin de l'année 2024, BitsLab, marque mère de ScaleBit, a publié le rapport « Observation Panoramique et Rapport de Sécurité sur les Nouvelles Blockchains Émergentes 2024 ». Ce rapport analyse en détail les diverses vulnérabilités et surfaces d'attaque actuelles, avec un contenu riche et pratique. Cet article extrait certaines parties du rapport afin de se concentrer sur les types clés de vulnérabilités critiques dans l'écosystème blockchain, aidant ainsi les lecteurs à anticiper les risques et à promouvoir conjointement le développement sûr et sain du secteur.
Lire le rapport complet : https://bitslab.xyz/reports-page
1) Liste des types de vulnérabilités
1.1 Vulnérabilités dans les communications inter-chaînes L2/L1
Les communications inter-chaînes constituent un levier essentiel pour améliorer l'interopérabilité au sein de l'écosystème blockchain, mais leur mise en œuvre comporte de nombreux risques. Voici les principaux points d'attention :
L2 ne tient pas compte du rollback de blocs sur L1
Lors de l'envoi d'une transaction sur L1 ou de la récupération de données depuis L1, si le risque de rollback n'est pas pris en compte, cela pourrait entraîner une perte d'actifs.
L2 ne vérifie pas si la transaction envoyée vers L1 a réussi
En raison de problèmes réseau ou de frais de gaz insuffisants, la transaction envoyée peut échouer. Si cette possibilité n’est pas prise en compte, cela pourrait conduire à une perte d’actifs pour le projet ou ses utilisateurs.
Falsification d’événements sur la chaîne
Lorsqu'un pont inter-chaînes écoute les événements sur la chaîne, il ne valide pas toujours que ceux-ci proviennent d'une adresse de contrat spécifique, ce qui permet à d'autres contrats de falsifier des événements.
Un même bloc contenant plusieurs événements
Une transaction peut contenir plusieurs événements. Sans prise en compte de ce cas, cela pourrait entraîner une perte d’actifs pour le projet ou ses utilisateurs.
Vulnérabilités de vérification par client léger
1. Absence de protection contre les attaques de minage privé sur les chaînes PoW
2. Non-utilisation des algorithmes recommandés officiellement
Attaque de l'homme du milieu (MITM)
Le mécanisme de transmission des messages est crucial dans les communications inter-chaînes L2/L1. Il faut garantir l’intégrité et la confidentialité des messages pendant leur transit. La transmission entre différentes chaînes peut être sujette à des altérations ou à des écoutes clandestines ; des moyens cryptographiques doivent donc être utilisés pour protéger les informations. En outre, l’irrévocabilité des messages lors de leur transfert entre chaînes doit être assurée afin d’empêcher toute modification malveillante.
Problèmes de latence et de finalité
Les communications inter-chaînes font souvent face à des retards et à des questions de finalité. En raison des différences de mécanismes de consensus et de temps de confirmation entre les chaînes, le délai de confirmation des transactions inter-chaînes peut varier, entraînant un retard dans la mise à jour des états et augmentant ainsi les risques de sécurité potentiels. Lors de la conception des protocoles inter-chaînes, il est essentiel de définir clairement la notion de finalité, d’assurer la cohérence des états des transactions et de prévenir les attaques de double dépense ou les incohérences d’état dues à des retards de confirmation.
1.2 Vulnérabilités des chaînes d'applications Cosmos
Cosmos, en tant qu’écosystème centré sur l’interopérabilité blockchain, permet à différentes blockchains de se connecter via le protocole IBC (Inter-Blockchain Communication). Toutefois, les chaînes d’applications Cosmos peuvent présenter certaines vulnérabilités lors de leur implémentation. Voici les principaux points critiques :
Vulnérabilité de blocage par BeginBlocker et EndBlocker
BeginBlocker et EndBlocker sont des méthodes facultatives que les développeurs de modules peuvent implémenter dans leurs modules. Elles sont respectivement exécutées au début et à la fin de chaque bloc. Utiliser un crash pour gérer les erreurs dans ces méthodes peut entraîner l’arrêt complet de la chaîne en cas d’erreur.
Utilisation incorrecte de l'heure locale
Étant donné que les nœuds ont des heures locales différentes, ne pas tenir compte de cette variation lors de la génération du consensus peut provoquer des problèmes de consensus.
Ressources utiles :
Source
https://forum.cosmos.network/t/cosmos-sdk-security-advisory-jackfruit/5319
Utilisation incorrecte des nombres aléatoires
Comme les différents nœuds génèrent des nombres aléatoires différents, ne pas tenir compte de cette différence lors de la création du consensus peut provoquer des problèmes de consensus.
Mauvaise utilisation de l'itération des maps
L’itération d’une map en langage Go est non déterministe. Si ce point n’est pas pris en compte lors de la génération du consensus, cela peut entraîner des problèmes de consensus. Exemple de code ci-dessous :
Problèmes dus à un ordre incorrect des modules
Les chaînes d’applications Cosmos sont composées de plusieurs modules, certains traitements d’événements devant s’exécuter dans un ordre précis. Un ordre mal configuré peut engendrer des failles de sécurité.
Échec d'une transaction sans rollback des données
Dans une chaîne d’application Cosmos, si une transaction échoue mais que l’état des données n’est pas restauré à sa valeur antérieure en raison d’un défaut de conception, cela peut entraîner une incohérence des données sur la chaîne. Cette situation nuit non seulement à la confiance des utilisateurs, mais peut également causer des pertes financières. Il est donc impératif de concevoir les contrats intelligents de manière à gérer correctement les échecs de transaction, garantissant la cohérence et la fiabilité de l’état, voire en implémentant un mécanisme de rollback automatique.
Vérification d'état incorrecte
La logique de vérification d’état dans les chaînes d’applications Cosmos doit être très rigoureuse. Une vérification imprécise pourrait valider des transactions illégales, compromettant ainsi la sécurité de la chaîne. Les développeurs doivent soigneusement concevoir la logique de transition d’état et effectuer des tests complets pour éviter les failles dues à une vérification erronée.
Sécurité des messages inter-chaînes
Le mécanisme IBC de Cosmos permet aux différentes chaînes d’application d’échanger des messages, mais introduit aussi des risques potentiels. Par exemple, si un message inter-chaînes est altéré pendant sa transmission, cela pourrait provoquer une mise à jour d’état erronée ou permettre à un attaquant d’exploiter ce message à des fins malveillantes. Des mécanismes de chiffrement et de signature doivent être mis en place pour garantir l’intégrité et l’authenticité des messages, empêchant toute altération pendant le transfert.
Problèmes de mise à jour et de gestion des versions des contrats
Les contrats des chaînes d’applications Cosmos peuvent nécessiter des mises à jour, mais une mise à jour mal réalisée peut entraîner une incompatibilité d’état ou des failles de sécurité. Les développeurs doivent définir une stratégie claire de mise à jour incluant la gestion des versions et les plans de migration, afin de ne pas perturber le fonctionnement normal de la chaîne.
Modèle économique et mécanismes d'incitation
La conception du modèle économique dans l’écosystème Cosmos influence directement la sécurité et la stabilité de la chaîne. Si les mécanismes d’incitation sont mal conçus, cela peut déséquilibrer le comportement des participants, favoriser des actions malveillantes ou des attaques économiques. Une évaluation complète du modèle économique est nécessaire pour garantir que les incitations maintiennent efficacement la sécurité et la santé du réseau.
Vulnérabilités du mécanisme de gouvernance
La gouvernance des chaînes d’applications Cosmos permet aux détenteurs de jetons de participer aux décisions, mais si elle est mal conçue, elle peut aboutir à des attaques de gouvernance ou à une centralisation excessive. Il est essentiel de garantir l’équité et la transparence du mécanisme de gouvernance afin d’empêcher une minorité de manipuler les décisions de la chaîne.
1.3 Vulnérabilités dans l'écosystème d'extension de Bitcoin
Vulnérabilités dans la construction de scripts Bitcoin
Les scripts Bitcoin sont souvent générés dynamiquement et déployés directement sur Bitcoin, et peuvent inclure des données fournies par l’utilisateur. Si la construction du script n’est pas sécurisée, cela peut entraîner une perte d’actifs.
Vulnérabilités dues à la non-prise en compte des actifs dérivés
Les actifs dérivés courants sur Bitcoin sont les inscriptions et les runes. Si une couche L2 traite les actifs utilisateur en ne considérant que le BTC natif, sans prendre en compte les actifs dérivés, cela peut entraîner une perte d’actifs pour l’utilisateur.
Vulnérabilités de calcul incorrect du montant UTXO
1. Erreur dans le calcul des frais de transaction
2. Erreur dans le calcul du montant de la monnaie rendue
Par exemple, dans le code suivant, la sortie de monnaie rendue n’est ajoutée que si celle-ci est supérieure ou égale à 546 satoshis. Cette valeur correspond à la limite Dust pour les transactions P2PKH traditionnelles. Toutefois, cette limite varie selon le type d’adresse. En particulier, pour les adresses Taproot, la limite Dust est de 330 satoshis.
Cette valeur codée en dur ne prend pas en compte la limite plus basse de Taproot, ce qui peut entraîner une perte d’actifs mineurs dans les transactions impliquant des adresses Taproot. Pour plus d’informations sur les limites Dust selon les types d’adresses, se référer au code source de Bitcoin Core et aux discussions sur le forum BitcoinTalk.
https://bitcointalk.org/index.php?topic=5453107.msg62262343#msg62262343
Non-vérification si l'UTXO contient "op_return"
Un UTXO contenant “op_return” n’est pas dépensable.
Vulnérabilités de vérification SPV
1. Absence de vérification du timestamp dans l’en-tête du bloc
2. Absence de vérification de la preuve de travail dans l’en-tête du bloc
Ne pas tenir compte du cas de rollback
Bitcoin étant basé sur PoW, des restructurations de chaîne se produisent fréquemment. Lors de l’envoi d’une transaction Bitcoin ou de la récupération de données, ne pas tenir compte de cette possibilité peut entraîner une perte d’actifs.
Ne pas vérifier si la transaction Bitcoin a été envoyée avec succès
Après l’envoi d’une transaction Bitcoin, celle-ci n’est pas forcément incluse par les mineurs. Il faut donc vérifier si la transaction a bien été intégrée à la chaîne. De plus, un tiers peut construire une transaction avec des frais plus élevés, faisant rester longtemps la transaction envoyée par L2 dans la mempool sans être incluse.
Vulnérabilité de confusion entre verrouillage temporel absolu et relatif
En construisant un script Bitcoin, si ces deux types de verrous temporels sont confondus, cela peut gravement entraîner une perte d’actifs.
Paramétrage incorrect du délai dans les contrats HTLC (Hash Time-Lock Contracts)
Trois cas fréquents :
1. Délai trop long
2. Délai trop court
3. Désynchronisation temporelle entre L1 et L2
1.4 Types courants de vulnérabilités dans les langages de programmation
1.4.1 Dépassement d'entier
Le dépassement d’entier survient lorsque la valeur excède la plage représentable du type, entraînant un retour arrière ou des erreurs logiques, affectant la précision des données. Rust détecte automatiquement les dépassements en mode débogage, tandis que Go nécessite des vérifications manuelles aux limites.
1.4.2 Boucle infinie
Une boucle infinie fait entrer le programme dans une itération sans fin sous certaines conditions, consommant les ressources système et bloquant l’exécution. Pour éviter cela, il faut définir des conditions de sortie appropriées et utiliser des mécanismes de temporisation en Rust ou le package context en Go pour contrôler les boucles longues.
1.4.3 Appels récursifs infinis
Un appel récursif infini se produit quand une fonction récursive manque d’une condition d’arrêt, entraînant un débordement de pile et un plantage. Il faut s’assurer que la récursion dispose d’une condition de base claire et limiter la profondeur de récursion selon les besoins.
Rust affiche une erreur de débordement de pile en mode debug, similaire à ceci :
1.4.4 Conditions de course
Une condition de course se produit lorsque plusieurs threads accèdent à une ressource partagée sans synchronisation, causant une incohérence des données. Rust évite cela grâce à son mécanisme de propriété et ses bibliothèques thread-safe, tandis que Go utilise les canaux et le package sync pour gérer la concurrence.
Exemple Rust non sécurisé ci-dessous, illustrant deux threads accédant et modifiant simultanément une variable partagée, entraînant un comportement indéfini. Ce code crée une course aux données car aucun mécanisme de synchronisation n’est utilisé :
Bien que Safe Rust empêche les courses aux données, les courses logiques peuvent encore survenir. Une condition de course logique fait référence à un comportement imprévu selon l’ordre d’exécution du code. Par exemple :
1. Opérations sensibles au temps : l’ordre d’exécution entre deux threads peut influencer le résultat logique. Par exemple :
a. Un thread vérifie une condition, pendant qu’un autre thread la modifie entre-temps. En Rust, Arc
2. Double-checked locking : si plusieurs threads tentent d’initialiser une ressource partagée en pensant qu’elle n’est pas initialisée, cela peut provoquer des erreurs logiques. Bien qu’il n’y ait pas de course aux données, des erreurs logiques peuvent survenir.
3. Ordre incorrect de verrouillage : si plusieurs verrous sont utilisés, les threads peuvent les acquérir dans un ordre incohérent, provoquant un interblocage. Le système de type de Rust ne peut pas empêcher ce type de condition de course.
Voici une démonstration d’une vulnérabilité de condition de course en Safe Rust. Dans cet exemple :
● Deux threads incrémentent chacun la variable partagée data de 1. Chaque thread verrouille data avant d’augmenter sa valeur.
● Comme l’opération est divisée en étapes, même si les données sont protégées par un Mutex, l’ordre d’exécution des threads 1 et 2 affectera l’ordre d’affichage. Théoriquement, la valeur finale devrait être 2, mais l’ordre exact des impressions peut varier.
1.4.5 Plantage par exception
Les plantages par exception sont généralement causés par des erreurs non traitées, entraînant l’arrêt inattendu du programme. Go utilise defer/panic/recover pour intercepter les exceptions, tandis que Rust utilise les types Result et Option pour offrir une gestion d’erreurs plus robuste.
Voici un exemple où l’absence de capture de panic conduit au plantage du programme :
1.4.6 Vulnérabilité de division par zéro
La division par zéro peut provoquer une exception ou un plantage. Il est recommandé de vérifier le diviseur avant toute opération de division afin de garantir la stabilité du programme.
1.4.7 Conversion de type
Les erreurs de conversion de type résultent généralement de conversions non sûres ou incompatibles, pouvant provoquer des comportements imprévisibles. Go et Rust signalent les incompatibilités de type, Rust étant plus strict et nécessitant l’utilisation explicite de l’opérateur “as”.
Dans l’exemple suivant, l’utilisateur ajoute une quantité "amount" de jetons à la liquidité, puis le système enregistre ce montant. Si amount = (u128::MAX << 64) | 1, alors seul 1 jeton est effectivement payé, mais le solde de liquidité enregistré vaut 340282366920938463444927863358058659841.
1.4.8 Accès hors limites d'un tableau
L’accès à un index invalide dans un tableau peut provoquer une erreur d’accès mémoire ou un plantage du programme.
L’exemple suivant illustre un accès hors limites entraînant un plantage :
1.5 Vulnérabilités du réseau P2P
Le réseau P2P (pair-à-pair) est utilisé dans les systèmes blockchain pour permettre une communication directe entre nœuds distribués. Bien qu’il constitue la base des systèmes décentralisés, il reste exposé à diverses vulnérabilités et menaces d’attaques.
D’un point de vue sécurité, on distingue deux types de réseaux P2P : les réseaux sans autorisation (plus courants sur L1) et les réseaux autorisés (plutôt utilisés sur L2).
Dans les réseaux P2P sans autorisation, de nombreuses attaques reposent sur des attaques Sybil. Dans les réseaux autorisés, on ne peut pas supposer que tous les nœuds sont fiables ; d’un point de vue sécurité, on doit supposer qu’au moins un nœud est malveillant.
Voici les types courants de vulnérabilités P2P :
1. Vulnérabilité d’attaque Hétéroïde (Eclipse-like) :
Aussi appelée pollution du pool d’adresses, cette attaque consiste à induire des nœuds de chaînes similaires à s’infiltrer et à se polluer mutuellement. Elle est possible car les systèmes de chaînes similaires ne reconnaissent pas les nœuds non homologues au niveau du protocole de communication.
Certaines chaînes similaires à Ethereum ont déjà connu ce type de faille. Ces chaînes (utilisant spécifiquement le protocole de découverte P2P discv4 d’Ethereum, y compris Ethereum, Ethereum Classic) utilisent un protocole de poignée de main compatible, incapable de distinguer les nœuds appartenant à la même chaîne, entraînant une pollution croisée des pools d’adresses, une baisse des performances de communication et finalement un blocage des nœuds.
Processus d’attaque illustré ci-dessous :
2. Absence de modèle de confiance
Il est conseillé d’attribuer un score de réputation à chaque nœud, ajusté selon son historique. Par exemple, un nœud envoyant fréquemment des données invalides voit sa réputation diminuer. Les nœuds hautement fiables sont davantage privilégiés, tandis que les autres sont limités.
3. Absence de limitation du nombre de nœuds
Il convient de limiter la vitesse de création de nouveaux nœuds ou le nombre de connexions par IP afin d’éviter la création massive de nœuds factices en peu de temps.
4. Problèmes dans l'algorithme de découverte de nœuds
L’algorithme de découverte et de sélection des nœuds localise les nouveaux nœuds et établit des connexions. S’il est mal conçu (par exemple, si l’algorithme de distance est déséquilibré), cela peut entraîner un déséquilibre topologique, surchargeant certains nœuds. L’algorithme doit être équilibré et imprévisible pour renforcer la sécurité de la distribution des nœuds et la résistance aux attaques.
L'image ci-dessous montre un cas extrême de déséquilibre topologique :
5. Mécanisme de sélection de nœuds vulnérable
Si le mécanisme de sélection est vulnérable, un nœud pourrait se retrouver connecté uniquement à des nœuds malveillants, subissant une attaque Eclipse. Voici quelques mécanismes sécurisés courants :
Sélection aléatoire de nœuds : randomiser les cibles de connexion empêche l’attaquant de contrôler la structure du réseau.
Stratégie de connexion locale : prioriser les connexions avec des nœuds proches physiquement ou topologiquement rend difficile la pénétration de tout le réseau.
6. Absence d'authentification
Dans les réseaux P2P autorisés, l’identité des nœuds doit être authentifiée.
7. Absence de mise à jour régulière de la table de routage
Si un nœud renvoie des données illégales, il faut envisager de supprimer son entrée dans la table de routage.
Les nœuds doivent périodiquement remplacer les nœuds inactifs dans la table de routage par de nouveaux, évitant ainsi l’isolement du réseau dû à une table obsolète.
8. Vulnérabilité d'interception MITM
Les données P2P doivent rester intactes pendant la transmission. Si l’algorithme de chiffrement est incorrect ou vulnérable, les données peuvent être altérées.
1.6 Vulnérabilités DoS
Les vulnérabilités DoS (Denial of Service) entraînent l’épuisement des ressources du système, empêchant l’accès normal des utilisateurs légitimes. Voici les types clés :
1. Attaque par épuisement de la mémoire
Exploite une forte demande mémoire pour saturer le système. Il est recommandé de fixer des limites aux ressources.
Une attaque courante est la « bombe ZIP ». Son principe : créer un fichier très grand rempli uniquement de zéros (ou d’une même valeur), puis le compresser. Grâce au taux de compression élevé, le fichier ZIP résultant est très petit. Lorsque la cible le décompresse, elle consomme énormément de mémoire, rapidement saturée, provoquant un plantage par OOM.
Les mêmes problèmes existent avec d’autres algorithmes de compression. Ci-dessous, comparaison des taux de compression pour un fichier de 1 Go rempli de zéros :
2. Attaque par saturation du disque : écriture de données inutiles pour combler l’espace de stockage, prévenue par une gestion des quotas disque.
Deux cas fréquents :
1. Bombe ZIP. Identique à l’« attaque par épuisement de la mémoire », mais la cible décompresse le fichier sur le disque plutôt que en mémoire.
2. Écriture gratuite ou quasi-gratuite de grandes quantités de données, épuisant progressivement l’espace disque.
3. Attaque par épuisement des handles noyau : trop de demandes épuisent les handles. Contrôlez l’allocation et surveillez les anomalies.
Principe général : l’attaquant exploite une faille pour épuiser ou presque les handles noyau du nœud cible, l’empêchant de répondre aux requêtes normales.
Une attaque courante est la « pression Socket ». Si le nœud cible ne limite pas le nombre ou la concurrence des connexions, l’attaquant peut envoyer et maintenir de nombreuses connexions, épuisant les ressources Socket du système.
4. Fuite mémoire persistante : la mémoire n’est pas libérée normalement, entraînant une famine de ressources. Une surveillance régulière est nécessaire pour éviter l’aggravation.
La fuite mémoire n’est généralement pas considérée comme une vulnérabilité de sécurité. Mais si un attaquant peut déclencher intentionnellement et répéter cette fuite, le nœud cible finira par planter par manque de mémoire.
1.7 Vulnérabilités cryptographiques
Les vulnérabilités cryptographiques compromettent la confidentialité et l’intégrité des données, exposant le système à des menaces. Voici les principaux types :
Utilisation d'algorithmes de hachage prouvés non sécurisés
Les fonctions de hachage assurent l’intégrité des données en créant un identifiant unique. Des algorithmes comme MD5 et SHA-1 présentent des risques de collision et peuvent être exploités. Il est donc conseillé d’utiliser des algorithmes modernes comme SHA-256 ou SHA-3, en maintenant les mises à jour pour éviter les risques liés aux anciens algorithmes.
Utilisation d'algorithmes de hachage personnalisés non sécurisés
Certains projets utilisent des algorithmes de hachage maison, généralement moins sûrs que les algorithmes publics connus.
Pendant nos audits, nous avons rencontré l’algorithme personnalisé suivant :
La fonction `hashCode` n’est pas une fonction de hachage cryptographique et est très sujette aux collisions. Elle effectue simplement des opérations bit à bit et des additions. De plus, ses entrées et sorties suivent un motif clair et prévisible, facile à inverser. En raison de ce mécanisme faible, un attaquant peut facilement générer des clés produisant la même valeur `CONST_KEY_HASH`, compromettant ainsi la sécurité du processus d’autorisation API.
Voici un code de preuve de concept (PoC) illustrant cette vulnérabilité :
Collision de hachage due à une utilisation non sécurisée
Un cas courant : HASH(A+B+C)=HASH(D+E), parce que A+B+C=D+E, bien que A, B, C, D, E soient différents.
Utilisation d'algorithmes de signature numérique non sécurisés
Les algorithmes de signature numérique valident l’authenticité et l’origine des données, empêchant leur altération. Des algorithmes anciens comme DSA ou RSA peuvent devenir obsolètes face au calcul quantique. ECDSA ou EdDSA offrent une meilleure sécurité, cruciale dans les systèmes distribués et les contrats intelligents.
Utilisation d'algorithmes de chiffrement non sécurisés
La solidité de l’algorithme de chiffrement impacte directement la confidentialité des données. Des algorithmes faibles comme DES peuvent être facilement cassés. Privilégiez AES-256 ou des algorithmes symétriques à haut niveau, et mettez en œuvre un chiffrement bout-en-bout (comme TLS) pour protéger la transmission des données. Assurez également une bonne gestion des clés pour éviter les fuites.
Utilisation d'algorithmes de génération de nombres aléatoires non sécurisés
Les générateurs de nombres aléatoires sont fondamentaux en cryptographie, notamment pour générer des clés, des IV ou des paramètres dans le chiffrement asymétrique. Leur imprévisibilité est cruciale. Problèmes courants :
1. Algorithme non sécurisé permettant de prédire ou manipuler les nombres générés ;
2. Sur les blockchains publiques, les algorithmes de génération aléatoire sont presque tous vulnérables à la prédiction, car toutes les informations sont publiques ;
3. Faible qualité aléatoire augmentant la probabilité d’exploiter certaines failles (ex. : minage).
Utilisation de graines aléatoires non sécurisées
Si la graine aléatoire fuit ou peut être craquée par force brute, les nombres générés deviennent prévisibles.
Attaques par canal secondaire en cryptographie
Ces attaques analysent des caractéristiques physiques du système (consommation d’énergie, temps d’exécution, cache, etc.) pour extraire des informations sensibles. Elles contournent la sécurité algorithmique, surtout dangereuses sur les dispositifs matériels. Les défenses incluent l’optimisation des implémentations pour un temps et une consommation constants, ainsi que des techniques de masquage et de brouillage.
Extensibilité des signatures (Signature Malleability)
L’extensibilité signifie qu’à partir d’une signature valide, on peut en dériver une autre différente mais tout aussi valide, sans modifier le contenu signé. Cela pose un risque majeur de malléabilité des transactions : un utilisateur malveillant peut utiliser différentes variantes de signature pour rejouer une transaction. Comme le hash change, cela brouille la perception de l’état de la transaction, permettant une double dépense.
1.8 Vulnérabilités de sécurité du registre
Vulnérabilités de la mempool de transactions
1. Transactions pouvant être rejouées
2. Les frais de transaction ne sont pas déduits pour les transactions échouées
Vulnérabilité de collision de hachage de bloc
Si la méthode de construction du bloc est défectueuse, des collisions peuvent survenir.
Vulnérabilité logique dans le traitement des blocs orphelins
Les blocs orphelins peuvent être soit supprimés, soit mis en cache. Dans ce dernier cas, des limites (hauteur, horodatage, etc.) doivent être ajoutées.
Vulnérabilité de collision de hachage dans l'arbre de Merkle
Si la construction des feuilles de l’arbre de Merkle est incorrecte, des collisions peuvent survenir.
Problèmes de traitement du montant des transactions
Erreurs dues à des débordements, des incohérences de type, des erreurs de précision, des valeurs négatives ou des valeurs imprévues causées par des changements externes.
Problèmes de traitement des frais de transaction
Idem, erreurs dues à des débordements, incohérences de type, erreurs de précision, valeurs négatives ou valeurs imprévues.
Sensibilité excessive du temps de validation des blocs et transactions
Étant donné les écarts horaires entre nœuds, la validation temporelle ne doit pas être trop stricte, sinon elle peut provoquer des fourches.
Problèmes logiques dans l'autorisation des transactions
Deux aspects principaux :
1. Contournement par usurpation d’identité
2. Erreur de vérification des permissions
1.9 Vulnérabilités du modèle économique
Le modèle économique joue un rôle crucial dans les systèmes blockchain et distribués, influençant les incitations, la gouvernance et la durabilité globale. Voici les points clés :
Modèle économique des chaînes d'applications Cosmos (exemple UniChain)
Les chaînes d’applications Cosmos adoptent un modèle économique centré sur l’interopérabilité et l’extensibilité. Prenez UniChain : son modèle tient compte non seulement de la circulation et de l’utilisation des jetons, mais aussi des besoins d’applications variées. Grâce au SDK Cosmos, UniChain peut créer des blockchains spécialisées et activer la communication inter-chaînes, favorisant le partage des ressources et le flux de valeur. Ce modèle doit soigner l’émission de jetons, l’inflation, la structure des frais et la gouvernance pour assurer stabilité et prospérité.
L'incitation est-elle raisonnable ?
Le mécanisme d’incitation est au cœur du modèle économique, influençant directement la participation des utilisateurs et des nœuds. Un bon mécanisme doit garantir une rémunération équitable à tous (mineurs, validateurs, développeurs, utilisateurs). Sa durabilité doit être évaluée pour prévenir les comportements malveillants ou la centralisation. Il doit aussi s’adapter aux évolutions du marché et des besoins des utilisateurs. Des questions telles que l’existence de mécanismes de récompense/punition, l’équilibre entre incitations à court et long terme, doivent être approfondies.
Durabilité de l'économie du réseau
Le modèle doit assurer la pérennité à long terme, notamment en gérant les incitations économiques, la création et la répartition de la valeur. On doit identifier d’éventuels déséquilibres ou gaspillages, et s’assurer que tous les participants tirent une valeur juste du réseau. Les facteurs externes (volatilité du marché, changements de comportement des utilisateurs) doivent aussi être analysés.
Mécanisme de retour du marché
Mettre en place un mécanisme de feedback efficace permettant au modèle économique de s’ajuster selon la demande utilisateur et la dynamique du marché. Grâce à une analyse régulière des données et aux retours utilisateurs, les problèmes potentiels peuvent être corrigés rapidement, assurant flexibilité et adaptabilité.
Impact de la structure de gouvernance
Le modèle économique doit être aligné avec la gouvernance, permettant aux utilisateurs de participer aux décisions économiques, renforçant ainsi l’engagement communautaire. Une gouvernance bien conçue favorise l’auto-réparation et l’optimisation continue du modèle, améliorant la santé globale du réseau.
Après avoir examiné en détail les différents types de vulnérabilités dans l’écosystème blockchain, il convient maintenant d’explorer les surfaces d’attaque concrètes par lesquelles ces failles peuvent être exploitées. Une surface d’attaque désigne les points d’entrée et chemins qu’un attaquant potentiel peut exploiter. Identifier et analyser ces surfaces permet d’évaluer plus efficacement les risques et d’élaborer des stratégies de protection adaptées. Maîtriser pleinement la relation entre vulnérabilités et surfaces d’attaque est donc essentiel pour construire une défense solide en matière de sécurité blockchain. Nous allons maintenant lister en détail les surfaces d’attaque courantes dans l’écosystème actuel, afin d’aider les lecteurs à mieux comprendre comment ces menaces peuvent être réalisées concrètement.
2. Liste des surfaces d'attaque
Voici la liste des surfaces d’attaque courantes :
4.1 Machine virtuelle
Surface d’attaque : la machine virtuelle exécute les contrats intelligents et traite le bytecode, supportant souvent une logique complexe, exposée à des risques comme les attaques de réentrance, les dépassements d’entiers ou de mémoire. De plus, un contrat à forte intensité calculatoire peut provoquer une attaque DoS, épuisant les ressources. Enfin, si le bytecode contient des failles non auditées, cela peut permettre l’exécution arbitraire de code ou une élévation de privilèges.
4.2 Module de découverte P2P et synchronisation des données
Surface d’attaque : une mauvaise conception de la découverte et de la synchronisation P2P peut rendre le réseau vulnérable à l’attaque Sybil, où de faux nœuds sont créés pour contrôler le réseau, dégradant ses performances voire le rendant inopérant. La pollution de la table de routage affecte la qualité des connexions entre nœuds, rendant certains inaccessibles. En outre, des paquets contenant des données falsifiées ou malveillantes peuvent induire en erreur les nœuds, perturbant la synchronisation et le consensus.
4.3 Module d'analyse de blocs
Surface d’attaque : l’analyse des blocs implique un traitement massif de données. Si le code d’analyse présente des débordements ou des erreurs de traitement, il peut être exploité par des blocs malveillants, entraînant un plantage ou un refus de service (DoS). De plus, une vérification incorrecte du format de bloc peut permettre la propagation de blocs altérés non détectés, compromettant la cohérence globale du réseau.
4.4 Module d'analyse de transactions
Surface d’attaque : l’analyse des transactions inclut la vérification de leur structure et de leur signature. Une mauvaise gestion des formats falsifiés, des données malveillantes ou des signatures anormales peut permettre à de fausses transactions de passer, consommant des ressources système. De plus, des erreurs de bornes dans l’analyse peuvent être exploitées pour des attaques par injection mémoire.
4.5 Mempool de transactions
Surface d’attaque : la mempool est un espace temporaire avant l’intégration des transactions. Elle peut être exploitée pour insérer massivement des transactions invalides ou malveillantes, provoquant une attaque par occupation mémoire, empêchant les nœuds de répondre aux requêtes normales. Des attaques par transactions répétées ou fréquentes peuvent aussi épuiser les ressources et provoquer un DoS.
4.6 Module de protocole de consensus
Surface d’attaque : un mécanisme de consensus mal conçu ou manipulable peut subir des attaques de double dépense, de minage égoïste ou d’attaque 51 %. Un attaquant contrôlant plus de 50 % de la puissance de calcul peut créer une bifurcation malveillante, compromettant la légitimité des transactions. Certains mécanismes peuvent aussi échouer en cas de latence élevée ou de partitionnement du réseau, faute de mécanismes de tolérance aux pannes clairs.
4.7 Interface RPC
Surface d’attaque : l’interface RPC permet aux externes d’interagir avec les nœuds blockchain. Une mauvaise configuration des permissions peut entraîner des accès non autorisés et des fuites de données. Si les interfaces RPC privilégiées ne sont pas protégées, un attaquant peut forger des requêtes à haute permission, manipulant les données sur la chaîne. En outre, ces interfaces sont vulnérables aux attaques par inondation de requêtes, surchargeant les nœuds.
4.8 Module de traitement des journaux
Surface d’attaque : le module de journaux enregistre les détails du fonctionnement système. Si un attaquant peut injecter des journa
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@scalebit_
