Exploit Profanity Wintermute

Le 20 septembre 2022, le market maker basé à Londres Wintermute a été drainé d'environ 160 millions de dollars depuis un hot wallet DeFi dont l'adresse avait été générée par Profanity, un générateur populaire d'adresses Ethereum vanity qui s'est révélé utiliser une source de nombres aléatoires critiquement faible.

Ce qui s'est passé

L'outil Profanity permettait aux utilisateurs de générer des adresses Ethereum avec des préfixes ou suffixes personnalisés (0x0000…, 0xWINT…, etc.). Pour faire cela efficacement, il forçait par force brute les clés privées jusqu'à ce qu'une produise une adresse avec le pattern désiré.

La faille fatale : Profanity initialisait son CPRNG avec un entier 32 bits — un espace de clé de seulement ~4 milliards de seeds possibles. Un attaquant avec des ressources GPU modestes pouvait énumérer tout l'espace de seeds en quelques jours et reconstruire chaque clé privée que Profanity avait jamais produite. La vulnérabilité avait été publiquement divulguée par 1inch environ une semaine avant l'incident Wintermute.

Wintermute a vu la divulgation et a agi dessus — ils ont retiré tout l'ETH du hot wallet affecté. Ce qu'ils n'ont pas fait, c'est retirer le rôle administrateur de cette adresse de leur contrat de coffre DeFi. Quand l'attaquant a finalement forcé par force brute la clé privée générée par Profanity pour ce wallet, ils ont utilisé le rôle admin toujours actif pour drainer 160 M$ en jetons directement depuis le coffre.

Conséquences

• Wintermute a offert à l'attaquant une prime white-hat de 10 %, qui a été refusée ; les fonds ont été envoyés vers Tornado Cash.
• Le CEO Evgeny Gaevoy a divulgué que la firme restait solvable avec ~320 M$ en capitaux propres après la perte.
• Profanity a été déprécié et des avertissements ont été émis pour chaque adresse qui avait été générée avec — beaucoup ont été drainées plus tard par des opérateurs séparés utilisant la même technique.

Pourquoi c'est important

Wintermute est le cas type pour la discipline de nettoyage post-incident : savoir qu'une clé peut être compromise ne suffit pas ; chaque système, contrat et rôle que cette clé a jamais touchés doit être révoqué, pas simplement vidé. La même leçon récidive sous différentes formes — une clé admin volée sur un contrat upgradeable (PlayDapp), un rôle de signature non rotaté après une brèche fournisseur — chaque fois que la remédiation d'un incident de sécurité est à moitié finie.