Un petit script devenu surface d’attaque
Le dernier récit public de Polymarket présente l’incident du 29 octobre comme la compromission d’un script tiers de suivi des performances chargé sur Polymarket.com, et non comme une compromission du moteur de trading ou des smart contracts de la plateforme . Selon l’entreprise, l’attaquant a remplacé ce script de confiance par un code conçu pour cibler spécifiquement les utilisateurs de Polymarket qui avaient le site ouvert pendant une courte fenêtre cet après-midi-là . Pour les traders connectés touchés, le code malveillant a utilisé l’autorité déjà disponible dans la session du navigateur afin de vendre des positions et de déplacer des fonds hors des wallets .
L’ampleur financière est désormais plus précise qu’au moment des premières alertes. The Hacker News a rapporté le 1er novembre que Polymarket rembourse environ 2,7 millions de dollars à 726 wallets affectés, tandis que les données blockchain montrent qu’environ 2,64 millions de dollars en crypto ont atteint le wallet des attaquants en moins d’une heure . Dans son propre postmortem, Polymarket indique retourner 3,9 millions de dollars au total: les 2,7 millions liés à l’attaque, plus 1,2 million pour les pertes liées à la pause des échanges et des gestes commerciaux .
Ce deuxième montant est essentiel. Polymarket ne traitait pas seulement le vol direct; la plateforme devait aussi compenser des traders dont les marchés ont bougé ou expiré pendant l’arrêt. D’après l’entreprise, le remboursement couvre les positions prises pendant l’attaque, le slippage causé par des ventes forcées, ainsi que certaines pertes pendant la suspension ou juste après la reprise des échanges .
Chronologie: moins d’une heure, des fonds bien réels
La fenêtre d’attaque a été brève, mais suffisante. La reconstitution technique d’Ohey indique que le script de real-user monitoring de DebugBear chargé par Polymarket a été remplacé par un wallet drainer, les premiers fonds arrivant dans le wallet destinataire à 17:10:23 UTC le 29 octobre, avant qu’un build de Polymarket retire le script à 17:59:20 UTC . La même analyse affirme que le wallet destinataire a reçu 28 636 284,45 POL et des positions provenant de 33 wallets de dépôt entre 17:10 et 18:02 UTC, puis a transféré les actifs vers des wallets en aval avant 18:38 UTC .
La page de statut de Polymarket décrit un incident majeur affectant l’application web et l’accès aux comptes entre 17:38 et 18:15 UTC, avec une phase de panne majeure terminée à 18:06 UTC . L’Associated Press a rapporté que les échanges sur la plateforme internationale de Polymarket ont été suspendus pendant environ une heure puis ont repris jeudi après-midi, après que l’entreprise a déclaré avoir identifié et corrigé le problème . Polymarket a également indiqué avoir transmis l’affaire aux autorités compétentes au Royaume-Uni, où DebugBear est basé .
La réponse opérationnelle a été simple, mais lourde: retirer le script fournisseur compromis, vider les caches, suspendre les échanges et les actions du relayer, réinitialiser les sessions actives, puis rouvrir seulement lorsque le site a été considéré comme propre . Dans son postmortem du 30 octobre, Polymarket a indiqué que 95 % des wallets affectés avaient déjà été intégralement remboursés . The Hacker News a ensuite rapporté que 689 des 726 wallets avaient été remboursés en totalité au 30 octobre, les 37 restants étant payés au fur et à mesure des vérifications .
Comment le drainer a fonctionné
Il s’agit d’une attaque de supply chain côté client. Le code malveillant n’avait pas besoin de casser un mot de passe, de voler une seed phrase ou d’exploiter un smart contract; il s’exécutait dans le contexte du navigateur d’utilisateurs déjà connectés à Polymarket . Selon Ohey, le script visait uniquement Polymarket: il lisait des clés de stockage propres à Polymarket, appelait des API de Polymarket et cherchait dans la page le client de trading de Polymarket .
La mécanique est importante, car elle montre pourquoi les défenses purement serveur peuvent rater ce type d’attaque. Le drainer cherchait des entrées de stockage local contenant le contexte de compte et de trading, puis parcourait les structures React de la page pour trouver le client de trading actif et son signer . Une fois ce signer trouvé, il utilisait le chemin de relayer de Polymarket pour soumettre les transactions . Autrement dit, la dépendance compromise empruntait les mêmes outils côté navigateur que le site légitime.
Le comportement variait selon le type de compte. The Hacker News rapporte que, pour les comptes connectés avec un wallet crypto personnel, le code tentait de déplacer directement les positions de marché prédictif vers l’adresse des attaquants; pour les comptes connectés par e-mail, il vendait d’abord les positions à des prix de plus en plus défavorables, puis déplaçait les fonds obtenus . Ohey a également constaté que les comptes avec wallet navigateur étaient ciblés par des transferts groupés de positions éligibles, tandis que les comptes e-mail voyaient leurs positions vendues via des ordres de vente fill-and-kill avant le balayage du cash .
L’enjeu n’est donc pas simplement de savoir si chaque utilisateur a validé une transaction manifestement frauduleuse. La leçon plus dérangeante est qu’un script de confiance, une fois compromis, peut interagir avec une application web active comme s’il faisait partie de l’application. Tous les hôtes appelés par le drainer, à l’exception de l’infrastructure DebugBear, figuraient dans la politique de sécurité de contenu de Polymarket, ce qui signifie que les requêtes entraient dans le périmètre normalement autorisé par le site .
DebugBear, DNS et le risque supply chain
Le rôle de DebugBear est central, car son produit de real-user monitoring a servi de canal de livraison. L’Associated Press a rapporté que DebugBear a publié être touché par un incident de sécurité en cours et a conseillé aux clients utilisant l’un de ses produits de retirer le code d’intégration de leurs sites . The Hacker News a rapporté que DebugBear a attribué la compromission à ses enregistrements DNS via son registrar, que les premiers éléments indiquaient une attaque ciblant le site d’un seul client, et que l’entreprise n’avait pas constaté de signe d’intrusion dans ses propres systèmes tout en poursuivant l’enquête .
La reconstitution d’Ohey soutient l’hypothèse d’une URL familière dont le contenu a changé. Le fichier DebugBear propre avait auparavant été servi depuis Google Cloud Storage, tandis que pendant l’incident un autre serveur répondait pour les noms d’hôte DebugBear et servait le drainer de 15 187 octets . C’est le scénario le plus dangereux pour le JavaScript tiers: le navigateur charge la même URL fournisseur déjà approuvée par le site, mais la charge utile est devenue hostile.
Polymarket affirme redéployer les scripts tiers avec des contrôles d’intégrité supplémentaires, notamment une politique de sécurité de contenu plus stricte, du version pinning explicite, du sandboxing, une surveillance continue et des mécanismes de vérification . Ces mesures n’effacent pas l’incident, mais elles désignent la bonne famille de contrôles. Une application financière ne peut pas traiter les scripts d’analytics, de monitoring, de chat, de tag management ou de mesure de vitesse comme de simples décorations. S’ils s’exécutent dans la même page que des wallets, des sessions, des signers et des clients de trading, ils font partie de la surface d’attaque financière.
Pourquoi l’incident dépasse Polymarket
L’attaque rappelle que la sécurité fintech ne concerne plus seulement les systèmes backend, les smart contracts, l’authentification ou la conservation des actifs. Elle concerne aussi ce qui s’exécute dans le navigateur de l’utilisateur après la connexion. Une petite dépendance ajoutée pour la télémétrie de performance peut devenir un acteur privilégié si elle tourne à côté de l’état de compte et des outils de transaction.
Pour les traders, le message immédiat est limité: Polymarket indique qu’aucune réclamation ni aucun ticket n’est nécessaire pour les wallets éligibles identifiés, mais fournit un formulaire aux utilisateurs qui pensent que le montant est incorrect ou qu’ils auraient dû recevoir un paiement . Pour les plateformes, le message est plus sévère. Chaque script tiers doit être inventorié, attribué à un responsable, surveillé pour détecter les changements, protégé par des contrôles d’intégrité, isolé lorsque c’est possible, et accompagné d’un interrupteur d’urgence activable rapidement.
L’attaque contre Polymarket n’a pas eu besoin d’une brèche spectaculaire dans une forteresse. Elle a eu besoin d’une dépendance de confiance, d’une session active et d’un navigateur disposant de trop d’autorité. Le script s’est chargé, puis l’argent a bougé.
Commentaires
Sois le premier à commenter.