Source originale : Beosin
Le 9 juin, Anthropic a officiellement lancé la version publique de Mythos, Claude Fable 5. Auparavant, Mythos avait démontré une capacité exceptionnelle à découvrir des vulnérabilités de sécurité, en identifiant rapidement des failles cachées au sein des systèmes, suscitant une grande attention dans le domaine de la cybersécurité.
L'incident récent de Zcash est un exemple typique de la capacité de l'IA à découvrir des vulnérabilités dans la blockchain. Le chercheur en sécurité Taylor Hornby, en utilisant le modèle Anthropic Claude Opus 4.8, a découvert en quelques heures seulement une faille de soundness (intégrité) dans le bassin de confidentialité Orchard, qui était restée latente pendant quatre ans et n'avait été détectée par aucun audit manuel précédent. Cette vulnérabilité pourrait théoriquement permettre de miner un nombre illimité de ZEC non détectés, entraînant directement une chute de près de 40 % du prix du ZEC.
Actuellement, l'IA démontre une efficacité surprenante dans des domaines comme la correspondance de motifs de code, le tri initial par lots, etc. L'intégration de l'IA dans les processus d'audit de sécurité de la blockchain et des contrats intelligents devient une tendance dans l'industrie de la sécurité Web3. Cet article, en s'appuyant sur des cas réels de vulnérabilités et les performances mesurées de Fable 5, analysera les avantages et les inconvénients de l'IA dans l'audit des contrats intelligents.
Scénarios avantageux pour l'audit par IA
Étude de cas : Collision d'emplacements de stockage
Un contrat utilise simultanément les deux composants suivants :
1. Un mapping de récompenses personnalisé (utilisé pour enregistrer les récompenses réclamables par l'utilisateur)
2. Le ReentrancyGuard de la bibliothèque Solady (pour prévenir les attaques par réentrance)
Or, la disposition du stockage des deux composants est entrée en conflit.
Le ReentrancyGuard de Solady, pour une optimisation extrême du gas, utilise un emplacement de stockage fixe et à numéro bas (généralement obtenu par un calcul spécifique donnant un slot proche d'une constante). La logique typique du modificateur nonReentrant est :
// Une version simplifiéemodifier nonReentrant() { // à l'entrée, écrire l'emplacement de garde comme 0xff...ff (Valeur Sentinel) assembly { if eq(sload(REENTRANCY_GUARD_SLOT), 2) { revert(...) } // 2 représente verrouillé sstore(REENTRANCY_GUARD_SLOT, 2) // verrouillé } _; // récupération à la fin de la fonction assembly { sstore(REENTRANCY_GUARD_SLOT, 1) }}
Mapping de récompenses personnalisé :
mapping(address => uint256) public rewards;
En raison des règles de disposition du stockage de Solidity (le premier slot d'un mapping est calculé à partir de sa position de déclaration), le premier emplacement du mapping de récompenses est exactement le même que l'emplacement de protection fixe du ReentrancyGuard.
Processus d'attaque (étapes détaillées) :
1. L'attaquant appelle la fonction getReward()
2. Le modificateur nonReentrant se déclenche, écrivant la valeur 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff (tous des 1) dans l'emplacement de garde.
3. Le code du contrat lit ensuite rewards[adresse de l'attaquant] — mais en raison de la collision d'emplacement, il lit en réalité la valeur énorme 0xff...ff de l'emplacement de garde.
4. Le contrat pense qu'il y a une « énorme récompense », transfère donc cette somme d'ETH à l'attaquant, tout en essayant de remettre rewards[attaquant] à zéro (mais il écrit à nouveau dans le même emplacement de garde).
5. Parce que le modificateur restaure l'emplacement à la fin de la fonction, l'attaquant peut rappeler getReward() et le processus se répète.
6. L'attaquant appelle en boucle 200 fois, extrayant à chaque fois un montant fixe d'ETH, jusqu'à ce que l'ETH extractible du contrat soit épuisé.
Il est important de noter qu'il ne s'agit pas d'une « attaque par réentrance » (reentrancy attack) au sens traditionnel, mais du mécanisme de protection du ReentrancyGuard lui-même qui est exploité à l'envers par la collision de stockage, devenant une vulnérabilité permettant des réclamations infinies de récompenses. Lors d'un audit manuel, il est extrêmement rare de fouiller ligne par ligne la disposition du stockage des bibliothèques tierces, alors que l'IA peut instantanément effectuer une comparaison de versions de bibliothèques + un mappage précis des emplacements de stockage, ciblant directement ce type de vulnérabilité de « collision cachée ».
Scénarios désavantageux pour l'audit par IA
Fable 5 excelle dans la détection de vulnérabilités au sein d'un contrat unique, de pure syntaxe de code, ou liées au stockage de bas niveau, mais face à la sémantique combinatoire inter-protocoles ou aux attaques combinant plusieurs contrats, des limites évidentes persistent. Nous avons utilisé la dernière version publique de Fable 5 pour retester les contrats liés à l'événement d'attaque sDOLA de Curve LlamaLend, et les résultats confirment ce problème.
La liste des contrats concernés par cet audit comprenait : crvUSD Controller.vy, sDOLA.sol, ERC4626.sol et d'autres contrats. Fable 5 n'a pas réussi à identifier le risque central correspondant à cette attaque :
Cet événement relève d'une vulnérabilité combinatoire inter-protocoles typique. La syntaxe et la logique du code d'un contrat unique sont correctes, mais l'attaquant utilise l'interaction de plusieurs protocoles pour construire une chaîne d'attaque :
1. En utilisant un outil de flash loan, manipuler le prix du pool de liquidités de Curve pour baisser artificiellement le prix de l'actif sDOLA (parts du coffre ERC-4626) ;
2. De nombreuses positions d'emprunt utilisant sDOLA comme collatéral déclenchent leur seuil de liquidation ;
3. L'attaquant exécute des opérations de liquidation en lots, en tirant profit.
Ce type de vulnérabilité repose sur la combinaison de plusieurs protocoles DeFi, mettant à l'épreuve la capacité d'analyse globale de l'IA / des experts en audit concernant le modèle économique global et les protocoles. Actuellement, l'audit par IA présente encore des lacunes dans la compréhension de la sémantique combinatoire inter-protocoles.
Conclusion
Les tests sur des cas réels montrent que Fable 5, dans des scénarios standardisés et détaillés tels que les conflits d'emplacements de stockage, les vulnérabilités de motifs de code, les défauts de logique dans un contrat unique, ou le tri initial par lots de code, peut efficacement découvrir des vulnérabilités cachées facilement omises par les audits manuels. Cependant, face aux vulnérabilités impliquant la sémantique combinatoire inter-protocoles, les modèles économiques DeFi, les attaques multi-contrats, ou la logique métier complexe, il peine à comprendre la nature métier de l'écosystème on-chain et à découvrir les chemins d'attaque combinés. Cette partie nécessite encore une analyse dirigée par des auditeurs de sécurité professionnels.
Dans le travail d'audit quotidien, Beosin a établi un processus d'audit mature combinant IA + experts en audit de sécurité, augmentant non seulement considérablement l'efficacité de l'audit, mais permettant également de mieux découvrir les risques potentiels de détail et les vulnérabilités de logique métier complexes, rendant le travail d'audit plus efficace, complet et approfondi.
