Les attaques « Fake Stake » sur les blockchains Proof-of-Stake

Une équipe d’étudiants rattachée au Decentralized Systems Lab a divulgué une série de vulnérabilités pouvant provoquer l’épuisement des ressources d’un nœud. Ces défaillances affecteraient 26 cryptomonnaies fonctionnant en PoS (proof-of-stake ou preuve d’enjeux). L’équipe a commencé à avertir les équipes de développement dès octobre 2018 de l’existence de ces dysfonctionnements. Elle vient de dévoiler publiquement ces failles.

L’envergure des attaques « Fake stake »

Les cryptomonnaies en preuve d’enjeux, notamment celles basées sur la version PoSv3 sont très similaires à Bitcoin, en ce qu’elles utilisent le modèle des UTXO et les règles de consensus de la plus longue chaîne. La différence principale réside dans le remplacement de la preuve de travail par la preuve d’enjeux. Le PoS à l’avantage de réduire l’impact environnemental de la validation des blocs et d’offrir – en théorie – une meilleure protection face aux attaques 51 %.

La « Fake Stake » fonctionne parceque les implémentations PoSv3 ne valident pas adéquatement les données avant de consacrer les ressources (stockage et mémoire RAM) d’un nœud. La faible intensité des vérifications permet à l’attaquant de remplir un nœud de données factices causant ainsi une surcharge puis un crash.

Plus précisément, c’est la validation des coinstake transactions qui pose problème. Ce terme désigne la série d’actions qui mène à la mise en jeux d’une somme dans un système PoS. L’algorithme de consensus, afin de valider la coinstake transaction, doit vérifier que l’UTXO soit conforme et non dépensé. Sauf que cette information ne se trouve ni dans le bloc ni dans les blocs précédents. La validation de ces transactions est ainsi assez complexe, et la plupart des systèmes PoS contournent ce problème en réalisant une validation approximative. C’est à ce moment qu’intervient la faille de la fake stake attack.

Deux versions d’une même vulnérabilité

L’attaque par la RAM du noeud

L’équipe du Decentralized Systems Lab a constaté la présence de la première version de cette défaillance dans 5 devises : Qtum, Particl, Navcoin, HTMLcoin et Emercoin. Ces 5 protocoles ne vérifient pas les transactions coinstake avant l’engagement des ressources RAM d’un nœud. Ces cryptomonnaies utilisent le système headers first de Bitcoin, dans lequel la propagation des blocs se fait en deux temps, celle du header puis celle du bloc.

Cela fonctionne très bien dans un système PoW. Toutefois, pour le PoS c’est une autre histoire. La transaction coinstake n’est pas contenue dans le header, qui ne peut donc être validé seul. Le nœud stocke donc le header dans sa mémoire vive. Ainsi, l’attaquant peut remplir la RAM du nœud victime et exploiter les failles qui résulteront des bugs.

L’attaque par le disque dur du noeud

La seconde variante fonctionne sur les mêmes bases, mais s’attaque elle au disque dur. Cela peut être d’autant plus problématique, en ce qu’un crash du disque dur peut nécessiter une intervention manuelle pour être relancé. Ces deux vulnérabilités peuvent être exploitées sans avoir de stake dans la devise en question, d’où l’appellation « Fake Stake ».

C’est donc l’association de la fonction « header first » de Bitcoin au système PoSv3 qui crée ces vulnérabilités. Notons que les deux variantes de l’attaque ne fonctionnent pas sur les versions antérieures : PoSv1 et PoSv2.

« Spent Stake attack » : une attaque « Fake Stake » plus subtile

Decentralized Systems Lab a trouvé une seconde façon d’abuser des procédés de vérification incomplets. Ce procédé comprend deux parties. Le système commence par vérifier que le montant de la transaction existe sur la chaîne, mais ne vérifie pas que ce montant ne soit pas dépensé. Puis, il vérifie que le hash corresponde à la cible de difficulté, qui en PoS représente plus un montant qu’une difficulté réelle.

Pour mener à bien cette attaque « spent stake », il faut contourner les deux parties de la vérification. Il convient d’utiliser un montant existant, mais déjà dépensé. Cependant pour contourner la seconde étape du contrôle il faut miner un bloc valide, et donc mettre une somme assez conséquente en jeux.

Mais l’ingéniosité de ces étudiants ne semblant pas connaitre de limites, ils ont développé une technique « d’amplification de mise ». Cette méthode leur permet d’abuser de la validation partielle des blocs pour générer un montant arbitraire de mise apparente et donc miner des blocs.

En effet, selon les chercheurs la mise apparente se réfère à l’ensemble des sorties de transaction de la mise candidate, même celles qui sont déjà dépensées. L’attaquant peut donc créer de multiples transactions en s’envoyant lui-même les pièces. Alors que seule la première de ces transactions devrait être comptabilisée dans la mise, toutes ces « auto-dépenses » sont comptabilisées du fait des procédés de vérification incomplets.

Il suffirait donc d’une mise de 0,01% des pièces en circulations, avec laquelle seraient faites 5000 transactions pour miner des blocs avec une mise apparente de 50% de l’offre totale de tokens disponible. Une fois sa mise amplifiée jusqu’à un montant important l’attaquant peut miner des blocs invalides et remplir les nœuds d’information factices. Ce qui est souvent le but des pirates s’attaquant a une blockchain puisque cela leur permet d’effectuer des doubles dépenses.

Coopération avec les équipes de développement

Au total, 26 cryptomonnaies en PoS ont été examinées pour déterminer l’étendue des vulnérabilités. Seulement 5 sur les 26 ont été affectés par l’attaque basée sur la première vulnérabilité. C’est en cherchant pourquoi seulement une partie fut affectée qu’ils découvrirent la seconde vulnérabilité. Cette dernière est selon les étudiants plus complexe, mais aussi plus intrusive.

Après avoir fait le bilan de leurs découvertes, les étudiants sont entrés en communication avec les équipes des quinze cryptomonnaies affectées les plus susceptibles d’être attaquées. La plupart ont reconnu la vulnérabilité et ont mis en place des palliatifs. Toutefois, une minorité a nié l’existence de vulnérabilité en affirmant que des implémentations récentes avaient déjà résolu ces problèmes. Decentralized Systems Lab note malgré tout que ces remèdes ne remplaceront pas une validation complète. Les attaques « Fake Stake » seront plus complexes à mettre en œuvre, mais les systèmes PoS y restent vulnérables.