Polymarket a repris ses activités le 29 octobre après qu'un fournisseur tiers compromis a perturbé le marché de prévisions international. Cet incident a marqué la deuxième faille de sécurité multimillionnaire de Polymarket en quatre mois. Le journal d'incident officiel de Polymarket indique que les restrictions de trading ont commencé à 18:05 UTC et ont été résolues à 19:05 UTC. Polymarket a déclaré que le problème avait été résolu et que les autorités compétentes avaient été informées. Polymarket a également promis une compensation complète aux utilisateurs concernés.
Bubblemaps, une entreprise d'analyse de blockchain, a estimé que la violation du 29 octobre a affecté plus de 700 utilisateurs de Polymarket et compromis environ 3,46 millions de dollars en actifs. Les attaquants ont échangé environ 2,7 millions de dollars contre POL et ont transféré les fonds. Un autre montant de 750 000 dollars est resté sur Polymarket au moment de l'évaluation.
Polymarket a révélé le 25 juin qu'un fournisseur compromis avait permis l'injection d'un script malveillant. Polymarket a indiqué que la dépendance affectée avait été supprimée et a promis des remboursements complets. Source Defense a signalé des pertes d'environ 3 millions de dollars suite à l'attaque de juin. Source Defense a identifié que la livraison s'était effectuée via une balise marketing qui récupérait une bibliothèque d'identité externe, que l'attaquant avait remplacée par un draineur adapté à Polymarket. Les chercheurs de Source Defense ont déclaré que la charge utile de juin ciblait les wallets contenant plus de 100 000 $ et cherchait à plusieurs reprises une autorisation numérique. Une autorisation approuvée passait par le relayer de Polymarket, qui soumet des actions signées.
L'analyse d'octobre de Hudson Rock a décrit un code obtenu à partir d'une URL associée à DebugBear qui cherchait à identifier le client de trading actif et le signataire au sein d'une session connectée. Le signataire est le composant qui demande une autorisation cryptographique. Hudson Rock a constaté que le comportement programmé du script variait selon le type de compte. Une branche demandait des transferts de jetons de position ; une autre demandait des ventes suivies de transferts des produits. Hudson Rock a également identifié des métadonnées de build de production documentant la suppression du script de surveillance DebugBear. Toutefois, l'analyse statique de Hudson Rock n'a pas prouvé que le code s'est exécuté, n'a pas obtenu de signatures silencieusement ni volé de clés privées. L'analyse n'a pas non plus établi une trace complète allant des victimes aux destinataires. Les métadonnées de suppression n'établissent pas précisément quand a pris fin l'exposition des utilisateurs.
La dépendance marketing de juin et le script associé à la surveillance d'octobre offraient des chemins différents vers une interface financièrement sensible. Le mécanisme de juin dépendait apparemment d'autorisations approuvées, tandis que le code d'octobre recherchait des outils de trading et demandait des signatures. Remplacer un fournisseur compromis seul ne résout pas le problème plus vaste du code malveillant accédant aux fonctions financières du site web. Les violations répétées soulèvent des questions sur l'autorité financière que le code externe peut obtenir via le navigateur d'un trader.
La documentation navigateur de MDN indique qu'un script tiers chargé directement dans une page peut accéder à d'autres scripts et données de cette page. MDN explique que héberger le script ailleurs ne supprime pas cet accès, tandis que le contenu cross-origin dans un cadre séparé possède une limite de sécurité différente. Réduire le code externe, limiter les demandes de signature et vérifier les fichiers téléchargés traitent différentes étapes de la chaîne d'attaque. Supprimer les intégrations inutiles des pages de trading et de signature réduit le code externe autorisé dans ces environnements. Examiner l'accès des signataires et identifier les actions nécessitant une confirmation fraîche de l'utilisateur restreint les demandes que le code peut effectuer après avoir obtenu un accès.
Subresource Integrity permet aux navigateurs de vérifier les scripts téléchargés par rapport à uneempreinte cryptographique attendue et de rejeter les fichiers modifiés. Subresource Integrity peut également protéger une ressource correctement ancrée hébergée sur un domaine de confiance. Un post-mortem détaillé couvrant la période d'exposition, les comptes affectés et les routes d'autorisation aiderait à évaluer le risque restant. Il reste non résolu si une autre intégration compromise pourrait convertir l'accès à l'interface de trading en une autorisation financière utilisable.