Comment est-il possible que la ligne de défense de Drift soit si fragile, de la pré-signature à la perte de droits ?
Rédaction : Four Pillars
Compilation : AididiaoJP, Foresight News
Points clés
Le 1er avril 2026 à 16h05 (UTC), le protocole Drift a subi une attaque majeure d'environ 285 millions de dollars. Drift est la principale bourse décentralisée de contrats perpétuels dans l'écosystème Solana. Cette attaque faisait partie d'un mécanisme complexe de manipulation des collatéraux : les attaquants ont utilisé des clés d'administrateur divulguées pour lancer un nouveau marché au comptant pour un jeton sans valeur, puis ont désactivé le mécanisme de protection des retraits, et enfin, ont extrait des actifs réels en falsifiant la valeur des collatéraux.
Cette attaque a combiné une technique de pré-signature basée sur des nombres aléatoires persistants avec des méthodes avancées d'ingénierie sociale. À partir du 23 mars, les attaquants ont créé des comptes de nombres aléatoires persistants pour deux signataires multi-signatures et deux comptes contrôlés par les attaquants. Même après que le protocole a effectué une migration multi-signature légitime le 27 mars, les attaquants ont réussi à regagner l'accès aux deux signataires dans la nouvelle multi-signature. En trompant le contenu des transactions, les attaquants ont obtenu des pré-signatures de signataires légitimes, stockées avec des nombres aléatoires persistants, et les ont exécutées en masse le 1er avril, prenant finalement le contrôle administratif. Cet événement n'impliquait pas de fuite de phrase de récupération ou de vulnérabilité de contrat intelligent.
Cet événement est une autre grave erreur de sécurité opérationnelle, survenant seulement 10 jours après l'incident d'attaque de Resolv. L'effondrement de Resolv provenait du fait qu'il n'avait pas mis en place de mécanisme multi-signature ; tandis que Drift, bien qu'il dispose d'une multi-signature, a également échoué en raison d'un seuil trop bas et du manque de mécanismes de sécurité supplémentaires. Ces deux événements montrent clairement qu'une refonte fondamentale de l'architecture des privilèges est extrêmement urgente.
Aperçu de l'événement
Source : @DriftProtocol
Le 1er avril 2026 à 16h05 (UTC), le protocole de la bourse décentralisée Drift, le principal contrat perpétuel sur Solana, a subi une attaque massive. Drift est un protocole offrant des services de trading à effet de levier, de trading au comptant, de prêt et d'autres services financiers décentralisés, alliant un teneur de marché automatique virtuel et un carnet de commandes en chaîne. Juste avant l'attaque, la valeur totale verrouillée par le protocole était d'environ 309 millions de dollars.
Source : @PeckShieldAlert
Environ à 18h10 (UTC), soit environ deux heures après le début de l'attaque, l'équipe de Drift a publié sur la plateforme X, demandant aux utilisateurs de suspendre les dépôts. Par la suite, l'équipe a confirmé l'incident d'attaque et a suspendu toutes les fonctionnalités de dépôt et de retrait. Plusieurs entreprises de sécurité et d'analyse en chaîne, y compris PeckShield et Lookonchain, estiment les pertes à environ 285 millions de dollars. Le portefeuille Phantom a rapidement agi pour bloquer l'accès à ce protocole.
Cette attaque a attiré une attention particulière car elle s'est produite seulement 10 jours après l'incident d'attaque de Resolv, devenant ainsi un autre événement de fuite massive de clés d'administrateur survenant en peu de temps. Les deux événements partagent une cause commune : la cause profonde n'est pas une vulnérabilité dans le code du contrat intelligent, mais une erreur dans la sécurité opérationnelle.
Analyse des causes profondes
Le cœur de cette attaque réside dans le fait que les attaquants ont utilisé des privilèges administratifs divulgués pour manipuler les collatéraux. Si l'événement Resolv était la « fuite d'une clé ayant des privilèges de frappe », alors l'événement Drift est la « fuite d'une clé ayant des privilèges de mise en marché et de configuration de sécurité ». Bien que les deux se manifestent différemment, leurs racines sont les mêmes. Ce qui suit est une analyse progressive du processus d'attaque.
Source : Dexscreener
L'outil le plus direct de cette attaque est le CarbonVote Token (CVT), un jeton avec une liquidité extrêmement faible. L'une des adresses contrôlées par les attaquants (FnYXwy...LpAjjx) a émis ce jeton trois semaines avant l'attaque. L'offre totale de CVT est d'environ 750 millions, dont plus de 80% sont détenus par le portefeuille des attaquants. Les attaquants ont créé un pool de liquidité minimal d'une valeur d'environ 500 dollars sur Raydium, puis ont effectué des transactions à volume élevé en continu.
La fonction initializeSpotMarket dans le protocole Drift permet aux administrateurs de spécifier directement l'adresse de l'oracle et la source de ses paramètres. En consultant la configuration de l'outil de développement logiciel du marché au comptant, on peut voir que chaque marché définit séparément son oracle, sa source d'oracle et les champs d'émission de jetons. Cela signifie que même des jetons comme le CVT, qui n'ont pas de prix oracle Pyth, peuvent être mis en marché par les attaquants s'ils obtiennent les droits d'administrateur.
Dans cette attaque, les attaquants ont désigné un prix oracle Switchboard pour le marché CVT comme leur oracle. Switchboard est un réseau d'oracles où la création de prix personnalisés est relativement facile. Les attaquants ont configuré un prix contrôlé par eux, évaluant la valeur de 750 millions de CVT à plusieurs centaines de millions de dollars. Les plateformes de suivi des prix telles que Dexscreener affichent un prix de CVT d'environ 1 dollar, mais sa liquidité de marché réelle et sa valeur intrinsèque sont presque nulles.
Le portefeuille utilisé pour l'attaque (HkGz4K...ovpZES) est apparu actif environ huit jours auparavant, le 24 mars. Ce portefeuille avait l'intention d'obtenir un préchargement via le protocole NEAR, et les enregistrements en chaîne montrent que jusqu'au jour de l'attaque, ce portefeuille avait effectué 325 transactions.
L'historique des activités en chaîne du signataire administrateur utilisé le jour de l'attaque (H7PiGq...y7ZgL) mérite également d'être noté. Cette clé n'a enregistré que 29 transactions. Sa première transaction a eu lieu le 31 mars à 15h05 (UTC), soit la veille de l'attaque ; la dernière transaction a eu lieu le 1er avril à 18h05 (UTC), soit le jour de l'attaque. La durée totale de présence en chaîne de cette clé est d'environ 27 heures. La raison en est clairement visible dans les enregistrements en chaîne.
Les droits d'administrateur du protocole Drift ne sont pas gérés par un seul compte externe, mais sont réalisés par un mécanisme multi-signature. Cependant, les chemins d'attaque révélés par l'enquête ultérieure sont beaucoup plus complexes qu'une simple intrusion multi-signature. Environ neuf jours avant l'attaque, les attaquants ont créé quatre comptes de nombres aléatoires persistants. Deux de ceux-ci étaient associés à des signataires de la multi-signature du comité de sécurité de Drift, et les deux autres étaient contrôlés par les attaquants. Les nombres aléatoires persistants sont un mécanisme sur Solana qui permet de contourner la période de validité d'environ une minute du hachage de bloc dans les transactions ordinaires, permettant de recueillir des signatures à l'avance et de les exécuter ultérieurement. On pense que les attaquants ont utilisé ce mécanisme pour obtenir des pré-signatures de signataires légitimes en trompant le contenu des transactions.
Quatre jours plus tard, l'équipe de Drift a effectué une migration multi-signature planifiée en raison d'un changement de membre du comité de sécurité. Cette migration fait partie d'un processus opérationnel régulier, mais les attaquants se sont adaptés avec succès à ce changement.
Le jour précédant l'attaque, les attaquants ont créé un nouveau compte de nombre aléatoire persistant pour un signataire dans la multi-signature migrée (6UJbu9...Pvu924). À ce moment-là, les attaquants avaient déjà regagné un accès effectif à deux cinquièmes des signataires dans la nouvelle multi-signature. Cela montre que les attaquants s'étaient profondément infiltrés dans le système, pouvant même faire face à des changements imprévus tels que la migration multi-signature.
Le jour de l'attaque, l'équipe de Drift a effectué un retrait de test de routine du fonds d'assurance. Environ une minute plus tard, les attaquants ont rapidement exécuté deux transactions de nombres aléatoires persistants pré-signées de manière consécutive.
Source : solscan
La première transaction a exécuté les instructions VaultTransactionCreate, ProposalCreate et ProposalApprove sur la multi-signature Squads, créant une proposition de transfert administrateur malveillante et enregistrant la première approbation.
Immédiatement après, la deuxième transaction a utilisé le nombre aléatoire persistant pour exécuter les instructions ProposalApprove et VaultTransactionExecute. Le seuil de deux cinquièmes a été atteint, et comme le verrou temporel était fixé à zéro seconde, la transaction a été exécutée immédiatement. À ce moment-là, l'instruction UpdateAdmin dans le programme Drift V2 a été appelée, transférant l'adresse d'administrateur aux attaquants (H7PiGq...y7ZgL).
Le détail clé ici est que ces deux transactions avaient été entièrement signées à l'avance et soumises en masse le jour de l'attaque. Les signataires n'ont probablement pas bien compris le contenu des transactions qu'ils signaient. Le terme « malentendu de transaction » utilisé par l'équipe de Drift indique que les signataires ont été trompés pour signer des transactions de transfert administrateur malveillantes déguisées en opérations régulières. La fonction des nombres aléatoires persistants est de stocker indéfiniment ces pré-signatures, permettant aux attaquants de les exécuter au moment de leur choix.
Le signataire administrateur remplacé a ensuite appelé le programme Drift V2 (dRifty...cn33UH) pour exécuter deux opérations.
Source : solscan
Premièrement, les attaquants ont enregistré le CVT comme un nouveau marché au comptant sur Drift via l'instruction initializeSpotMarket. Dans ce processus, un nouveau compte de marché au comptant (BY3WYn...FVU1Cf) et deux comptes de jetons CVT ont été créés, et l'adresse dérivée du programme du trésor Drift (PDA, JCNCMF...XXJfrw) a été définie comme propriétaire des jetons.
Drift fonctionne sur un système de collatéral multi-actifs, ce qui signifie que les jetons enregistrés sur le nouveau marché au comptant peuvent être immédiatement utilisés comme collatéral. Cependant, pour être considérés comme un collatéral éligible, les paramètres initial_asset_weight et maintenance_asset_weight du marché doivent être fixés à des valeurs positives supérieures à zéro, tandis que la valeur d'initialisation par défaut est assez basse ou proche de zéro. L'analyse des transactions d'attaque (4a5962R...st82X) montre que updateSpotMarketMarginWeights (ou une mise à jour équivalente des paramètres de risque) a été regroupée avec initializeSpotMarket et exécutée dans la même transaction, les attaquants ayant fixé le poids du collatéral de CVT à sa valeur maximale.
Cela expose un défaut de conception clé du point de vue de la défense en profondeur : les opérations telles que le lancement du marché, la désignation de la source oracle, la configuration du poids maximal du collatéral et la désactivation de la protection des retraits peuvent toutes être réalisées en une seule transaction. Le facteur de remise du poids, utilisé pour prévenir le risque de concentration des positions importantes, perd également son utilité réelle après que le poids lui-même a été fixé à sa valeur maximale. Si le programme impose une limite supérieure aux poids des marchés nouvellement créés ou s'il impose un verrouillage temporel indépendant pour les modifications de poids, alors une attaque pouvant anéantir toutes les mesures de défense en une seule fois ne serait pas réalisable.
Source : solscan
Deuxièmement, dans la même transaction, les attaquants ont appelé cinq fois l'instruction updateWithdrawGuardThreshold, augmentant le plafond de retrait du marché des actifs principaux à un niveau extrême. Tous les plafonds du marché ont été fixés à une valeur unifiée d'environ 500 trillions, rendant en réalité l'activation du mécanisme de protection des retraits infinie, abolissant ainsi les fonctionnalités de sécurité conçues pour empêcher les retraits anormalement élevés.
Cette transaction (4a5962R...st82X) a également détruit les trois principales lignes de défense de Drift.
Premièrement, en allouant un prix oracle contrôlé par les attaquants via Switchboard, le mécanisme de prix a été compromis. Deuxièmement, le poids du collatéral a été fixé à sa valeur maximale, permettant à un jeton sans valeur intrinsèque d'être considéré comme un excellent collatéral. Troisièmement, le seuil du mécanisme de protection des retraits a été relevé à environ 500 trillions, éliminant pratiquement tout mécanisme d'interruption des retraits anormaux.
Y compris le changement des privilèges administratifs, l'attaquant a démoli toute l'architecture de sécurité du protocole en seulement deux transactions. D'un point de vue d'audit de code, cela soulève un paradoxe profond : le code du contrat de Drift fonctionne exactement comme confirmé par l'audit. initializeSpotMarket a enregistré un nouveau marché comme prévu, désignant la source oracle et définissant les paramètres de poids ; updateWithdrawGuardThreshold a modifié les plafonds comme prévu. La véritable source du problème réside dans la conception du système lui-même - cette conception permet de réaliser une chaîne d'attaques complète en une seule transaction. Cela ne relève plus du domaine de l'audit de code, mais de la conception de l'architecture des privilèges et des contraintes de paramètres.
Finalement, les attaquants ont déposé environ 750 millions de CVT en tant que collatéral via un nouveau compte utilisateur Drift créé. Le prix oracle contrôlé par les attaquants a évalué cette valeur à plusieurs centaines de millions de dollars, tandis que le poids maximal du collatéral a reconnu presque toute l'évaluation comme collatéral valide. Le système de marge de Drift fonctionnait entièrement comme prévu. Le problème réside dans le fait que chaque paramètre entré dans ce système a été manipulé de manière malveillante par les attaquants.