Résumé Technique : L'insécurité par l'obscurité : Vulnérabilités voilées dans les contrats à code source fermé

1. Énoncé du problème

Sur les blockchains publiques comme Ethereum, le bytecode des contrats intelligents est accessible publiquement, pourtant de nombreux développeurs choisissent de garder leur code source fermé ou d'employer l'obfuscation de bytecode pour protéger leur logique métier propriétaire et dissuader les attaques (ex: le frontrunning). Bien que l'obfuscation vise la « sécurité par l'obscurité », cet article soutient qu'elle conduit souvent à une « insécurité par l'obscurité ». L'obfuscation, particulièrement l'obfuscation du flux de contrôle utilisant des sauts indirects, entrave la capacité des outils de sécurité existants à analyser les contrats, masquant potentiellement des vulnérabilités critiques de gestion d'actifs.

L'article identifie une lacune spécifique : les outils existants peinent à passer à l'échelle pour les contrats volumineux, fermés et obscurcis, en particulier ceux gérant des actifs importants comme les bots de Valeur Extractible Maximale (MEV). Ces bots emploient souvent une logique complexe impliquant des échanges, des prêts flash (flash loans) et des interactions DeFi. Lorsqu'ils sont obscurcis, ils deviennent des « boîtes noires » où les vulnérabilités — spécifiquement celles permettant à des adversaires de voler des actifs — restent indétectables jusqu'à leur exploitation.

2. Méthodologie : L'outil skanf

Pour répondre à ces défis, les auteurs présentent skanf, un nouvel outil d'analyse de bytecode EVM conçu pour les contrats fermés et obscurcis. skanf fonctionne en trois étapes principales :

A. Désobfuscation du flux de contrôle

Le premier défi est que les contrats obscurcis utilisent des sauts indirects (où la destination est une valeur d'exécution) pour masquer les chemins d'exécution. Les outils existants classent souvent ces blocs comme inaccessibles ou échouent à les analyser.

• Approche : skanf exploite une propriété spécifique de l'Ethereum Virtual Machine (EVM) : les destinations de saut valides doivent être explicitement marquées par l'opcode JUMPDEST.
• Technique : L'outil scanne statiquement le bytecode pour collecter toutes les adresses JUMPDEST légales. Il instrumente ensuite le bytecode en insérant une table de branchement (une séquence de vérifications conditionnelles) à une adresse de compteur de programme (PC) élevée (ex: 0xe000).
• Transformation : Les sauts indirects sont réécrits pour sauter vers cette table de branchement. La table compare la destination de saut au moment de l'exécution avec toutes les adresses JUMPDEST valides connues. Si une correspondance est trouvée, l'exécution se poursuit vers la cible ; sinon, elle passe à la vérification suivante. Cela convertit les sauts indirects opaques en sauts directs explicites et analysables statiquement, restaurant le Graphe de Flux de Contrôle (CFG) sans altérer la logique du contrat.

B. Exécution symbolique par graines de transactions

Le second défi est le problème d'« explosion de chemins » dans l'exécution symbolique, exacerbé par la complexité des bots MEV.

• Approche : Au lieu de s'appuyer uniquement sur des entrées aléatoires ou des spécifications manuelles, skanf utilise des transactions historiques comme des graines concrètes de haute qualité.
• Technique :
  1. Extraction de graines : L'outil récupère les transactions historiques réussies pour un contrat cible à partir d'un nœud d'archive. Il extrait les entrées (appelant, origine, calldata, valeur) qui ont déclenché des appels externes, en filtrant spécifiquement ceux impliquant des transferts ERC-20.
  2. Exécution guidée par graines : Ces entrées concrètes initialisent le moteur d'exécution symbolique. Le moteur explore les chemins guidés par ces graines, réduisant considérablement l'espace de recherche et la complexité de résolution de contraintes par rapport à une exécution symbolique pure.
  3. Analyse de propagation (Taint Analysis) : Pendant l'exploration des chemins, skanf effectue une propagation de marqueurs (taint) au niveau des octets. Il suit la manière dont les entrées adverses (calldata marqué) circulent vers les paramètres critiques des instructions CALL (adresse cible, sélecteur de fonction, arguments).

C. Détection de vulnérabilités et génération d'exploits

• Oracle de vulnérabilité : Une instruction CALL est signalée comme une vulnérabilité potentielle de gestion d'actifs si :
  1. Elle est atteignable depuis un point d'entrée public.
  2. Ses paramètres sont soit contrôlables par l'adversaire (marqués), soit risqués (fixes mais dangereux, ex: une adresse de jeton ERC-20 fixe ou un sélecteur de fonction transfer).
  3. Plus précisément, si la fonction est transfer ou approve, l'outil vérifie si le destinataire et le montant peuvent être manipulés par l'adversaire.
• Synthèse d'exploit : Pour les vulnérabilités identifiées, skanf construit une transaction pour exploiter la faille. Il résout les contraintes pour générer un calldata spécifique qui déclenche l'appel vulnérable et transfère les actifs vers une adresse contrôlée par l'adversaire.
• Validation : Les exploits générés sont validés dans un environnement blockchain local (utilisant un nœud d'archive pour reconstruire les états historiques) afin de garantir qu'ils exécutent avec succès le transfert d'actifs.

3. Principales contributions

1. Méthode de désobfuscation : Une technique novatrice pour supprimer l'obfuscation du flux de contrôle dans le bytecode EVM en reconstruisant les tables de saut, permettant aux outils d'analyse statique de fonctionner sur des contrats obscurcis.
2. Exécution symbolique par graines de transactions : Une approche évolutive qui utilise les transactions historiques publiques comme graines concrètes pour guider l'exécution symbolique, atténuant l'explosion de chemins et améliorant l'efficacité de la détection de vulnérabilités.
3. Implémentation de skanf : Un outil qui intègre la désobfuscation et l'exécution guidée pour détecter les vulnérabilités de gestion d'actifs et générer automatiquement des exploits pour les contrats à code source fermé.
4. Évaluation empirique : Une étude à grande échelle de 6 554 bots MEV réels, démontrant la prévalence des vulnérabilités et l'efficacité de l'approche proposée.
5. Découverte d'attaques de phishing MEV : Identification d'une nouvelle classe d'attaques où des adversaires attirent les bots MEV à interagir avec des contrats malveillants via des opportunités fabriquées, entraînant des pertes financières significatives.

4. Résultats

Les auteurs ont évalué skanf sur un ensemble de données de 6 554 bots MEV :

• Efficacité de la désobfuscation : skanf a réussi à augmenter la couverture de code pour les contrats obscurcis. Pour les contrats où les outils standards (Gigahorse) avaient une couverture inférieure à 50 %, skanf a restauré une couverture proche de 100 % dans 90 % des cas.
• Détection de vulnérabilités :
  • skanf a identifié 1 030 contrats vulnérables.
  • Il a réussi à générer et valider des exploits pour 394 de ces contrats.
  • La perte économique potentielle de ces exploits synthétisés est estimée à 10,6 millions de dollars (basée sur les soldes de jetons au moment de la rédaction et les sommets historiques).
  • Comparé aux outils de pointe (Mythril, ETHBMC, JACKAL, Securify), skanf détecte nettement plus de vulnérabilités, principalement grâce à sa capacité à gérer l'obfuscation et à utiliser l'exécution guidée par graines.
• Attaques réelles :
  • L'étude a mis au jour 104 attaques de « phishing MEV » réelles ciblant 37 bots MEV entre 2021 et 2025.
  • Ces attaques ont entraîné une perte totale de 2,76 millions de dollars.
  • skanf a pu redécouvrir les vulnérabilités de 28 de ces contrats exploités, suggérant que ces attaques auraient pu être évitées.
  • Seules 3 des 104 attaques avaient été publiquement rapportées auparavant.

5. Signification et affirmations

L'article affirme que « l'insécurité par l'obscurité » est un risque tangible dans l'écosystème des smart contracts. En cachant le code, les développeurs empêchent involontairement les outils de sécurité de détecter des failles critiques, particulièrement celles impliquant la gestion d'actifs.

• Implication de sécurité : L'obfuscation n'améliore pas la sécurité ; elle crée plutôt un faux sentiment de sécurité tout en masquant des vulnérabilités qui mènent à des pertes financières substantielles.
• Utilité pratique : skanf fournit un mécanisme défensif pour les développeurs et les auditeurs afin d'analyser le bytecode fermé ou obscurci avant le déploiement ou l'interaction, identifiant les risques qui resteraient autrement cachés.
• Contexte MEV : L'étude souligne que les bots MEV, qui gèrent de gros volumes d'actifs et sont souvent à code source fermé, sont une cible privilégiée pour ces vulnérabilités. La découverte des « attaques de phishing MEV » révèle un vecteur d'attaque sophistiqué où les adversaires exploitent la nature automatisée de ces bots.
• Modestie : Les auteurs reconnaissent des limites, telles que la dépendance aux outils sous-jacents (Gigahorse et Greed) pour l'analyse initiale et la focalisation actuelle principalement sur les instructions CALL (excluant DELEGATECALL, CALLCODE, etc.). Ils notent également que bien qu'ils aient identifié de nombreuses attaques, leur méthode de détection est basée sur des modèles (patterns) et peut manquer des attaques ne correspondant pas aux critères spécifiques du « phishing ».

En résumé, l'article démontre que sans outils d'analyse capables de gérer l'obfuscation, la stratégie de « sécurité par l'obscurité » dans les smart contracts est fondamentalement erronée, laissant des actifs importants exposés à l'exploitation.