Rétrospective approfondie sur la faille Truebit : comment un dépassement d'entier a permis à un hacker de créer pour 26,44 millions de dollars sans coût

1月8日, le plateforme de vérification de calcul Truebit a subi un incident de sécurité majeur. Le rapport d’analyse de l’équipe de sécurité de SlowMist a dévoilé la vérité derrière cet événement : les attaquants ont exploité une vulnérabilité de dépassement d’entier dans le contrat Purchase pour frapper des tokens TRU à coût quasi nul, puis ont dérobé 8 535 ETH, d’une valeur d’environ 26,44 millions de dollars. Plus inquiétant encore, les hackers ont effectué le blanchiment complet des fonds entre le 10 et le 11 janvier via Tornado Cash, rendant toute récupération quasiment impossible. Il ne s’agit pas seulement d’une perte financière colossale, mais aussi d’une sévère mise à l’épreuve de la conscience de sécurité de l’écosystème des contrats intelligents.

La nature de la vulnérabilité : la protection oubliée

Qu’est-ce qu’un dépassement d’entier

Le dépassement d’entier est une vulnérabilité courante mais dangereuse dans les contrats intelligents. En termes simples, lorsque le calcul d’un nombre dépasse la plage maximale que peut représenter son type de donnée, le système “replie” automatiquement à la valeur minimale. Par exemple, si la valeur maximale d’un entier non signé 8 bits est 255, tenter d’y ajouter 1 le ramène à 0.

Dans le contrat Purchase de Truebit, cette vulnérabilité a été exploitée pour le calcul des prix. L’attaquant a soigneusement construit ses paramètres de transaction pour provoquer un dépassement, permettant ainsi au système de frapper des tokens TRU à un prix très faible (proche de zéro). Cela revient à faire en sorte qu’une opération censée coûter plusieurs millions de dollars ait finalement coûté presque rien.

Pourquoi cette vulnérabilité est-elle apparue

Selon l’analyse de SlowMist, la cause principale est l’absence de mécanisme de protection contre le dépassement dans le contrat de Truebit. Ce problème est une vulnérabilité classique dans le langage Solidity.

Truebit utilise une version de Solidity antérieure à 0.8.0 pour compiler ses contrats, ce qui signifie que toutes les opérations arithmétiques nécessitent l’utilisation de SafeMath pour être protégées. Or, manifestement, à un moment donné dans le calcul du prix, cette protection a été omise.

La voie de l’attaque et la réaction du marché

Le processus de l’attaque

Selon les informations recueillies, l’exécution de cette attaque a été d’une efficacité impressionnante :

• Étape 1 : identification de la vulnérabilité, construction d’une transaction malveillante
• Étape 2 : frappe massive de TRU à coût très faible
• Étape 3 : extraction d’ETH du pool de fonds de Truebit via la frappe
• Étape 4 : transfert rapide des fonds vers une adresse de mixage
• Étape 5 : blanchiment via Tornado Cash (réalisé entre le 10 et le 11 janvier)

Tout le processus, de la découverte de la vulnérabilité à la blanchiment des fonds, a duré moins de 72 heures. La rapidité et le professionnalisme de l’attaque indiquent qu’il ne s’agit pas d’une tentative aléatoire, mais d’une opération ciblée et planifiée.

Signaux d’alerte sur le marché

Cet incident a provoqué une réaction négative claire sur le marché. Selon les dernières données, le prix de l’ETH est actuellement de 3 102,47 dollars, en faiblesse récente : baisse de 0,03 % en 24h, -2,14 % sur 7 jours. Bien que la chute ne soit pas spectaculaire, la problématique plus profonde concerne la confiance des investisseurs dans la sécurité des protocoles de vérification de calcul (Computation Verification Protocol) et de projets similaires.

Truebit est une infrastructure essentielle dans l’écosystème Layer 2 pour la vérification des calculs. Son incident de sécurité ne nuit pas seulement à la confiance dans le projet lui-même, mais soulève aussi des inquiétudes dans toute l’industrie sur “combien d’autres vulnérabilités similaires existent”.

Enseignements pour l’industrie : ce n’est pas un cas isolé

Pourquoi SafeMath est-il si crucial

Le rapport de SlowMist recommande explicitement : pour tous les contrats compilés avec une version de Solidity antérieure à 0.8.0, il est impératif d’utiliser SafeMath pour protéger toutes les opérations arithmétiques. Ce n’est pas une option, mais une ligne de défense fondamentale.

Le rôle de SafeMath est simple mais vital : il vérifie à chaque opération si un dépassement se produit, et si c’est le cas, il annule la transaction (revert). Ce processus, qui peut sembler superflu, évite des catastrophes comme celle de Truebit.

La faille de l’audit

Fait intéressant, en tant que projet bien financé et doté de compétences techniques solides, Truebit aurait dû faire l’objet d’un audit de sécurité. Pourtant, cette vulnérabilité a été omise. Cela reflète un problème plus large dans l’industrie :

• Les équipes d’audit peuvent trop compter sur des outils automatisés
• La méconnaissance des risques liés aux anciennes versions de Solidity
• La profondeur insuffisante des revues de code

Cela signifie qu’un audit ne garantit pas à 100 % la sécurité du contrat.

La menace persistante des mixers

Tornado Cash a encore une fois joué le rôle de “trou noir” pour les fonds. Après avoir transféré les ETH dans le mixer, il devient quasiment impossible de suivre ou de geler ces fonds. C’est pourquoi la perte de 8 535 ETH est considérée comme “quasiment irrécupérable”.

Cela nous rappelle que, même si l’on parvient à identifier l’adresse du portefeuille du hacker, si celui-ci transfère rapidement ses fonds dans un mixer, l’action en justice devient très difficile.

En résumé

L’incident Truebit est essentiellement une catastrophe causée par une protection de base oubliée. La perte de 8 535 ETH et 26,44 millions de dollars n’est que la surface ; le problème plus profond est :

• Le choix de la version est crucial : utiliser une ancienne version de Solidity nécessite une vigilance accrue et des protections supplémentaires
• SafeMath n’est pas une option : c’est une ligne de défense indispensable
• L’audit n’est pas une garantie absolue : il faut une revue de code plus approfondie et une évaluation des risques
• La réactivité est essentielle : la rapidité du transfert des fonds par le hacker montre qu’il faut des mécanismes d’intervention plus agiles

Pour l’ensemble de l’industrie, c’est une leçon coûteuse. Mais en adoptant des standards de sécurité plus stricts, en renforçant les audits, et en étant plus prudents dans le choix des versions, ce coût pourrait être en partie amorti.