Alerte de 680 millions de dollars : La plupart des attaques DeFi échappent à la portée des audits

Auteur : Liam 'Akiba' Wright, cryptoslate

Traduit par : Chopper, Foresight News

Dans le domaine de la finance décentralisée, "audité" est souvent considéré comme un gage de sécurité pour l'ensemble du projet. Cependant, en réalité, les audits ne couvrent généralement qu'un point dans le temps spécifique, des codes, des composants et des versions désignés. Tout ajout, suppression ou manipulation en dehors de cette portée peut donner des résultats d'audit complètement différents.

Un nouvel article préliminaire fournit des chiffres concrets sur cet écart. La société de sécurité ack3 et des chercheurs de l'Université technique de Prague ont analysé 135 incidents de sécurité signalés au cours du premier semestre 2026, entraînant des pertes allant jusqu'à 939,86 millions de dollars. Ils ont découvert que 68 de ces incidents avaient des antécédents d'audit public identifiables.

Dans cet échantillon de 68 incidents, les chercheurs ont classé 46 chemins d'attaque comme étant complètement en dehors de toute portée d'audit vérifiable ; 20 incidents étaient couverts par au moins un audit ; les 2 restants ne pouvaient pas être déterminés. Les incidents en dehors de la portée d'audit représentaient 67,6 % du nombre total d'incidents, mais correspondaient à 94,4 % du montant total des pertes signalées.

Ce rapport étonnant n'est pas une évaluation de l'efficacité des audits, ni une preuve que les limitations de la portée des audits entraînent des pertes. Il représente simplement la distribution des pertes dans l'échantillon d'incidents de sécurité publique sélectionnés. Deux incidents majeurs ont eu un impact énorme sur les données : en excluant les pertes de 292 millions de dollars de Kelp DAO et de 285 millions de dollars de Drift Protocol, la part des pertes dues à des attaques en dehors de la portée d'audit dans le même échantillon déjà audité est tombée à 72,1 %.

Même avec ces limitations, cette étude révèle un problème fondamental de confiance en matière de sécurité : un projet peut prétendre avoir été audité, mais les utilisateurs ne peuvent pas savoir si le système en fonctionnement, les flux de fonds et les mesures de contrôle associées ont été examinés.

La véritable signification des données

L'étude d'ack3 couvre la période du 1er janvier au 29 juin 2026, avec un total de 122 incidents d'attaques confirmés et 13 incidents suspects. Dans l'ensemble de l'échantillon, 35 incidents n'ont pas trouvé de dossier d'audit, et 32 avaient une histoire d'audit inconnue, ces deux catégories n'étant pas incluses dans le décompte des 68 incidents ci-dessus.

Dans l'échantillon de 68 incidents, les événements en dehors de la portée d'audit correspondaient à des pertes de 680,97 millions de dollars, pour un total de pertes de 721,24 millions de dollars, d'où le chiffre de 94,4 %. En excluant Kelp DAO et Drift Protocol, les pertes en dehors de la portée d'audit s'élevaient à 103,97 millions de dollars, pour un total de pertes de 144,24 millions de dollars, soit 72,1 %. Le fichier json du jeu de données peut reproduire le nombre de classifications d'incidents et les montants des pertes.

L'étiquette "dans / hors de la portée d'audit" est un jugement fait par les chercheurs sur la base de preuves publiques. L'équipe de recherche a consulté les archives des projets et des organismes d'audit, a trouvé les rapports d'audit avant l'attaque et a comparé le chemin d'attaque final avec le code, la version et les exclusions examinées. Cette étude est un article préliminaire de 6 pages, produit en collaboration avec le fournisseur de données, dont deux auteurs appartiennent à la société d'audit de sécurité ack3.

Cette étude manque d'un groupe de contrôle non attaqué et n'a pas statistiquement évalué la durée d'exposition au risque des différents systèmes. Par conséquent, elle ne peut pas prouver que les protocoles audités sont globalement plus sûrs, ne peut pas estimer la probabilité d'occurrence des événements, et ne peut pas confirmer que "hors de la portée d'audit" est la cause directe de chaque perte. Certaines audits non publiés et des incidents privés peuvent être manquants, et les données de pertes déjà signalées ne sont pas entièrement comparables.

Ainsi, cette étude ne peut tirer que des conclusions limitées : les dossiers d'audit et la portée d'audit sont deux indicateurs indépendants. Un contrat intelligent examiné ne signifie pas que les mises à jour de contrat, les clés de privilège, le front-end, les relais, les oracles, les services cloud ou les processus de réponse d'urgence bénéficient d'une sécurité équivalente.

Les deux incidents survenus en août confirment cette distinction sous différents angles. Le cas de l'ICON Network montre de manière intuitive qu'il y a eu des défaillances aux frontières de deux segments de code examinés ; tandis que l'incident de sécurité aelf en août représente une autre situation, où les preuves d'audit existantes ne peuvent pas encore relier le chemin d'attaque à la portée d'audit préalable.

ICON Network : Échantillon d'échec aux frontières de l'examen

Lors de l'attaque par répétition de l'ICON Network le 27 août, deux modules de la chaîne de retrait ont eu des divergences dans l'interprétation du même message.

Selon le rapport de rétrospective de la fondation ICON : le contrat de migration s'appuie sur le bit de poids fort du numéro de séquence du message de retrait pour déterminer si le message est unique ; mais la signature cryptographique ne couvre que les 256 bits inférieurs du numéro de séquence. L'attaquant a modifié le bit de poids fort, qui n'était pas inclus dans la vérification de la signature, et a soumis 1492 fois deux messages de retrait légitimes en répétition pendant environ 20 minutes, dont 1490 appels ont réussi.

Cette attaque par répétition a libéré 119,866 millions de ICX et 531,600 bnUSD. Lors de la publication de la rétrospective, ICON a confirmé une perte nette d'environ 150,2 ETH plus 31,204 USDC. La fondation a déclaré que 531,600 bnUSD et 1,366 millions de SODA avaient été récupérés, et que les dépôts des utilisateurs, les soldes de compte et les positions n'avaient pas été affectés.

ICON a déclaré que ce contrat de migration avait été soumis à un audit externe et que les recommandations d'audit avaient été mises en œuvre, y compris les modifications pertinentes dans la même zone de module ; la logique de relais correspondante avait également été soumise à un examen spécial. La liste d'audit des documents de développement de Sodax comprend 8 rapports couvrant différents composants, y compris le rapport d'audit du relais de Sodax de novembre 2025.

Cependant, le rapport de rétrospective précise que la logique de vérification d'unicité et la valeur de vérification de la signature ne faisaient pas partie des découvertes de l'audit susmentionné. Une simple étiquette de projet "audité" ne permet pas aux utilisateurs de savoir si les deux extrémités de la chaîne de retrait maintiennent des critères de jugement cohérents concernant "l'unicité du message".

La chronologie de la réponse a également révélé une autre catégorie de problèmes de frontière. La première alerte automatisée d'ICON a été déclenchée à 02h08 UTC, environ 7 minutes après le début de l'attaque. Le personnel a commencé l'enquête vers 03h40, a suspendu le contrat affecté à 03h53, et a suspendu l'ensemble du réseau à 06h18:54.

Il y avait un intervalle d'environ 90 minutes entre la première alerte et la gestion complète de l'urgence. ICON a attribué cela à l'ajustement du mécanisme d'alerte, car cette règle d'alerte avait généré de nombreuses fausses alertes lors de précédents problèmes de connectivité réseau, et n'a donc pas été signalée avec une priorité élevée au personnel de garde. La fondation prévoit de déployer un mécanisme de déclenchement d'arrêt automatique, de réduire le seuil de coupure, et de mener une révision spéciale sur l'unicité des messages et la protection contre les répétitions.

Ces mécanismes de gestion des risques ne peuvent pas remplacer les audits, mais ils répondent à une autre question clé : lorsque les mesures préventives échouent, le système peut-il détecter rapidement et isoler le risque ?

aelf : La sécurité nécessite une mise à jour continue

L'incident de sécurité aelf en août confirme ce point de vue sous un autre angle. Les documents publics décrivent une intrusion en temps d'exécution et une récupération contrôlée, mais les preuves existantes ne suffisent pas à déterminer si le chemin d'attaque se trouvait dans la portée d'audit spécifique préalable.

L'annonce officielle du projet indique qu'il existe un contrat intelligent non autorisé capable d'injecter un programme .NET codé et des instructions dans le lien d'exécution des nœuds en utilisant des paramètres de transaction.

Le rapport d'enquête préliminaire attribue l'incident à des défauts de réflexion en temps d'exécution et de vérification de chargement dynamique, ainsi qu'à une isolation insuffisante entre l'environnement d'exécution du contrat et les nœuds sensibles, les ressources d'infrastructure. aelf a identifié un total de 155 transactions pertinentes, 5 ensembles de charges utiles indépendants, les charges utiles ayant la capacité d'exécuter des commandes sur l'hôte principal, d'essayer de communiquer à l'extérieur, d'accéder aux clés des nœuds, de faire de la reconnaissance d'infrastructure, etc.

Avoir la capacité ne signifie pas que toutes les charges utiles ont été exécutées avec succès, ni que l'attaquant a obtenu tous les certificats cibles ou que des données sensibles ont été divulguées. aelf a déclaré avoir renouvelé les clés de signature et les certificats d'infrastructure conformément aux normes de fuite potentielles.

Au 11 septembre, cette conclusion reste un jugement préliminaire. Le blog officiel d'aelf n'a pas publié de mises à jour spécifiques concernant cet incident après le 26 août. L'annonce du 26 août promettait de publier des mises à jour et une rétrospective finale.

aelf indique dans ses documents de sécurité technique que sa blockchain et le contrat de jeton ELF ont été soumis à plusieurs audits, sans problèmes de sécurité détectés. Cependant, la page publique actuelle ne peut pas relier le chemin d'exécution de l'attaque d'août à un rapport d'audit antérieur. Par conséquent, qualifier l'incident de négligence d'audit ou de défaillance en dehors de la portée d'audit manque de preuves suffisantes.

Cette incertitude a elle-même une signification de référence. Un rapport d'audit avec un horodatage finira par se déconnecter du code système actuel, des bibliothèques de dépendance et de l'état opérationnel réel. Les utilisateurs ont besoin d'un dossier de sécurité avec version pour refléter cette différence.

Ce dossier de sécurité devrait indiquer : la version du dépôt examiné et du code soumis, l'adresse du contrat déployé, les composants exclus, les rôles de privilège, les bibliothèques de dépendance ; tout en enregistrant les mises à jour de contrat, la gestion et le renouvellement des clés, les stratégies d'isolation en temps d'exécution, les mécanismes d'alerte et de coupure, ainsi que l'état de récupération des actifs avec horodatage, distinguant les pertes confirmées, les actifs gelés et les risques non résolus.

Cela ne remet pas en question la valeur des audits, mais permet d'aligner la promotion des audits avec le contenu réel du travail et de le relier au système en fonctionnement actuel.

Un simple badge d'audit ne peut pas répondre à la question : les composants examinés, le système déployé et les mécanismes de réponse aux pannes sont-ils toujours dans la même frontière de sécurité ?

Ce contenu est fourni à titre informatif uniquement et ne constitue pas un conseil financier, d'investissement, juridique ou fiscal. Les événements, récompenses, promotions en ligne ou informations mentionnées ici ne doivent pas être considérés comme une recommandation, une sollicitation ou une invitation à acheter, vendre, trader ou effectuer toute autre opération sur des actifs crypto. Les actifs crypto sont très volatils et peuvent entraîner des pertes. La disponibilité des services, produits et événements liés à WEEX peut varier selon les régions. Veuillez vous assurer que votre participation respecte les lois et réglementations locales applicables.