Polymarket : un script tiers détourné a vidé des portefeuilles, comment s'en protéger

Le 29 octobre, du code malveillant a pris la place d'un script de mesure de vitesse de pages sur le site de Polymarket, une plateforme de marchés prédictifs. Des positions de traders connectés ont été vendues ou transférées, et leurs fonds envoyés vers le portefeuille des pirates. Polymarket rembourse environ 2,7 millions de dollars à 726 portefeuilles.

Ce qui s'est passé

Le script remplacé venait de DebugBear, dont l'outil de surveillance des utilisateurs réels (RUM) mesure la vitesse de chargement des pages. Selon DebugBear, ses enregistrements DNS ont été compromis via son registrar de noms de domaine. Ses premières conclusions indiquent que l'attaque visait le site d'un seul client. Il n'a pas vu de trace d'intrusion dans ses propres systèmes, mais l'enquête continue.

Chaque client de DebugBear charge sa propre copie du script, et le fichier échangé était celui de Polymarket. Des chercheurs de Hudson Rock ont téléchargé le fichier malveillant le jour même, depuis l'adresse que le site utilisait pour charger le script.

Comment le code a pris l'argent

Le code réutilise l'accès qu'un trader connecté possède déjà dans une page Polymarket ouverte. Il lit des informations de compte stockées dans le navigateur, dont des clés d'API de trading. Ces clés seules ne permettent pas de passer un ordre, car il faut aussi une signature de portefeuille. Hudson Rock n'a trouvé aucun morceau de code qui envoie les clés, un mot de passe, une phrase de récupération ou une clé privée vers le serveur des pirates.

Le code cherche plutôt la partie du site qui passe les ordres et le signataire qui approuve les transactions du compte. Ensuite, deux chemins :

• pour les comptes connectés avec leur propre portefeuille crypto, il déplace directement les positions vers le portefeuille des pirates ;
• pour les comptes connectés par e-mail, il vend les positions à des prix de plus en plus mauvais, puis déplace l'argent.

Dans les deux cas, le code demande au signataire du compte de signer ses requêtes et les transmet au relayeur de Polymarket. Hudson Rock précise qu'une demande de signature ne prouve pas à elle seule qu'un trader a signé sans voir d'invite : le fournisseur du portefeuille peut encore demander une confirmation ou refuser.

Selon la traçabilité de Ohey, le portefeuille des pirates a reçu ses premiers fonds à 17h10 UTC et les derniers à 18h02, soit 28,6 millions de jetons POL (environ 2,64 millions de dollars) et des positions de 33 portefeuilles, puis tout a été envoyé vers trois autres adresses.

La réponse de Polymarket

Polymarket a publié un premier message à 17h38 UTC, puis mis son exchange en mode « annulation seulement » à 18h05, avec les actions du relayeur suspendues. Le script a été retiré « dans l'heure », tous les caches vidés, toutes les sessions de connexion réinitialisées et les échanges suspendus le temps de nettoyer le site. L'affaire est transmise aux autorités. Au 30 octobre, 689 des 726 portefeuilles touchés étaient intégralement remboursés. Polymarket verse aussi 1,19 million de dollars à environ 5 500 portefeuilles qui ont perdu de l'argent pendant la suspension ou dont des positions ont été prises, soit 3,9 millions au total. Aucune demande n'est nécessaire.

Ce que ça change pour votre site

Chaque script externe chargé sur une page est du code que vous exécutez chez vos utilisateurs, avec leurs droits. Si le fournisseur est compromis, vous l'êtes aussi. Les conseils de Hudson Rock :

• ne chargez pas de code tiers inutile sur les pages où l'on paie, où l'on signe ou où l'on saisit des données sensibles ;
• quand un fichier peut être figé, utilisez Subresource Integrity (SRI) : le navigateur rejette le fichier si son contenu change ;
• une politique de sécurité qui autorise simplement un CDN de confiance ne vérifie pas les fichiers que ce CDN sert ;
• vérifiez ce que le code d'une page connectée peut demander au signataire du compte.

Polymarket remet ses scripts tiers avec des contrôles supplémentaires : une Content Security Policy plus stricte, des versions figées et du sandboxing.

Que faire maintenant ?

• Faites l'inventaire des scripts externes de votre site (analytics, chat, mesure de performance, widgets) et supprimez ceux qui ne servent plus.
• Ajoutez l'attribut integrity sur ceux qui ont une version fixe :

<script src="https://exemple.com/lib.js"
        integrity="sha384-..."
        crossorigin="anonymous"></script>

• Durcissez votre CSP pour limiter les domaines autorisés à charger du script et à recevoir des données.
• Protégez le compte de votre registrar et de votre DNS (authentification forte, verrouillage du domaine) : c'est ce maillon qui a cédé chez DebugBear.
• DebugBear a demandé à ses clients de retirer son code d'intégration RUM de leurs sites : si vous l'utilisez, appliquez-le.

Source : The Hacker News