Une exploitation de smart contract détourne une faille du code, de la conception économique, des permissions ou d’une dépendance externe pour obtenir un résultat non prévu, souvent le vol ou le gel d’actifs. Elle diffère d’un simple vol de clé : l’attaquant peut utiliser des règles valides du contrat dans une séquence inattendue.
Commencer par le modèle de risque#
Les catégories courantes comprennent les défauts de contrôle d’accès, la manipulation d’oracles de prix, la réentrance, les erreurs comptables, les mises à niveau non sécurisées et les clés administrateur compromises. La perte visible peut n’être que la dernière étape d’une défaillance plus longue entre plusieurs dépendances.
Le contrôle final à appliquer#
Évaluez les mécanismes de confinement et les pouvoirs d’administration : le protocole peut-il suspendre, mettre à niveau ou récupérer des actifs, et qui contrôle ces fonctions ? Ces mêmes pouvoirs peuvent limiter un incident ou créer un risque supplémentaire.
Réagir étape par étape#
- Identifiez le contrat touché et sa version déployée. Comparez l’adresse exacte, le réseau, l’implémentation et, s’il existe, le proxy avec les informations officielles.
- Suspendez les interactions et révoquez les autorisations associées si les sources vérifiées le recommandent. Utilisez un outil officiel ou reconnu et contrôlez chaque transaction avant de signer.
- Déterminez si le front-end, le contrat ou une clé administrateur est compromis. La mesure adaptée diffère : éviter l’interface ne suffit pas si le contrat lui-même est vulnérable.
- Suivez les communications officielles sur l’incident et conservez les preuves de transaction. Gardez les identifiants, horaires et adresses dans leur forme originale afin de pouvoir reconstituer la situation.
- Refusez les liens non sollicités de remboursement ou de récupération. Retrouvez toute procédure d’indemnisation depuis le site et les canaux officiels, sans connecter un portefeuille à un formulaire reçu en réponse sociale.
Les situations qui piègent les utilisateurs#
- Supposer qu’un audit couvrait toutes les dépendances. Son périmètre, sa date et la version examinée peuvent exclure l’oracle, le pont, le front-end ou une mise à niveau ultérieure.
- Déposer pendant un incident non résolu pour profiter d’un rendement accru. Ce rendement peut refléter la fuite de liquidité ou une distorsion du protocole, pas une prime durable.
- Signer une « migration d’urgence » trouvée dans les réponses d’un réseau social. Les fraudeurs imitent les équipes précisément lorsque les utilisateurs sont pressés.
- Confondre une perte de marché avec une exploitation de code. Une baisse de prix n’implique pas nécessairement une faille ; identifiez le mécanisme avant de prendre une mesure risquée.
Un résultat propre ne se limite pas à une transaction ou à un réglage terminé. Il doit pouvoir être vérifié indépendamment, reproduit et récupéré si le service environnant fait défaut.
Confirmer le résultat#
Ne jugez pas l’issue uniquement parce que l’interface affiche une réussite. Utilisez des preuves encore contrôlables après la fermeture de la page.
| Point de contrôle | Preuve à obtenir | Condition d’arrêt |
|---|---|---|
| Identifier le contrat touché et la version déployée | Adresse exacte et version rapprochées de la documentation officielle | Audit supposé couvrir toutes les dépendances sans contrôle du périmètre |
| Suspendre les interactions et révoquer les permissions recommandées | Identifiants des révocations et état on-chain correspondant | Nouveau dépôt pendant un incident non résolu |
| Distinguer front-end, contrat et clé administrateur | Avis officiel et indicateurs techniques cohérents | « Migration d’urgence » provenant de réponses sociales |
Conservez les identifiants de transaction, numéros de dossier officiels et captures datées utiles pour documenter l’exploitation, mais excluez toute phrase de récupération, clé privée et code d’authentification.
Questions fréquentes#
Un contrat exploité peut-il être corrigé ?
Un système évolutif peut parfois être modifié, tandis qu’un déploiement immuable exige souvent une migration. La récupération dépend de l’architecture et des pouvoirs encore disponibles.
Le code open source empêche-t-il les exploits ?
Non. Il facilite l’examen, mais ne garantit pas que chaque bug, dépendance ou interaction économique soit découvert avant son exploitation.
Faut-il révoquer les autorisations après un exploit ?
Si le bénéficiaire compromis peut encore les utiliser, la révocation réduit l’exposition future. Vérifiez le réseau, l’adresse exacte et les recommandations officielles avant d’agir.
Guides associés#
- Révoquer une autorisation illimitée de jetons
- Vérifier l’historique des autorisations d’un portefeuille
Sources#
Avertissement sur les risques : les opérations en cryptomonnaies peuvent être irréversibles. Ne communiquez jamais votre phrase de récupération, votre clé privée, votre mot de passe ou un code d’authentification, et vérifiez indépendamment chaque domaine et chaque demande affichée par votre portefeuille.
Règles éditoriales
Ce guide est éducatif et fondé sur des sources. Les mesures de sécurité, règles des plateformes et exigences légales peuvent évoluer ; vérifiez les étapes importantes auprès des sources officielles.
