Polymarket met en place un plan de remboursement de 3,9 millions de dollars après une compromission de script tiers

TL;DR : Polymarket indique que son incident du 29 octobre impliquait un script de surveillance compromis. Sa mise à jour du 30 octobre a fixé le montant total des remboursements à 3,9 millions de dollars, y compris les pertes liées à la pause de trading.

Polymarket a publié un compte rendu plus détaillé de la compromission par un tiers qui a perturbé sa plateforme internationale le 29 octobre. La mise à jour déplace l'accent de la question de savoir si le trading avait repris à la manière dont l'attaque a fonctionné et comment les clients seraient indemnisés.

L'explication de l'entreprise rappelle également qu'une application on-chain peut dépendre de composants de site web off-chain ayant accès à des sessions utilisateur actives.

Le montant du remboursement inclut plus que des fonds drainés

Dans son rapport post-mortem du 30 octobre, Polymarket a déclaré qu'il remboursait 3,9 millions de dollars : 2,7 millions de dollars associés à l'attaque et 1,2 million de dollars pour les pertes liées à la pause. Il a rapporté que 95 % des portefeuilles affectés avaient été remboursés intégralement à cet après-midi-là.

L'entreprise a déclaré qu'un script de surveillance des performances compromis avait utilisé certaines sessions actives pour vendre des positions et déplacer des fonds. Sa réponse a inclus la suppression du script, le nettoyage des caches, la réinitialisation des sessions et l'arrêt temporaire des activités de trading et de relai.

Le chiffre de 95 % est un rapport d'entreprise horodaté. Il ne doit pas être présenté comme un taux de complétion de remboursement en direct ou comme preuve que chaque montant contesté par un client a été résolu.

Le code du site web peut devenir partie intégrante de la frontière financière

Un script tiers s'exécute parce qu'un site web choisit de le charger. En fonction de ses autorisations et de son environnement d'exécution, ce script peut interagir avec des parties de la page et la session du navigateur que les utilisateurs associent à l'application de confiance.

La documentation de Mozilla sur l'intégrité des sous-ressources décrit une défense : un navigateur peut comparer une ressource téléchargée à un hachage cryptographique attendu et refuser le contenu qui ne correspond pas. Cela aide à séparer un fichier approuvé d'un fichier modifié servi par la même adresse.

Ce mécanisme est utile mais limité. Il ne décide pas si le code approuvé était sûr, et une application a toujours besoin d'un processus solide pour examiner les mises à jour et contrôler quelles ressources sont autorisées à s'exécuter.

Une pause de trading peut créer une seconde catégorie de pertes

Dans un marché lié à un résultat sensible au temps, arrêter les transactions peut affecter les utilisateurs même si leur portefeuille n'a jamais été directement drainé. Une position pourrait se régler pendant l'interruption, ou sa valeur marchande pourrait changer avant la reprise du trading.

L'indemnisation pour ces effets nécessite un point de référence défini. Un opérateur doit déterminer l'horodatage pertinent, la taille de la position et la méthode d'évaluation, puis appliquer la même approche de manière cohérente. Sinon, un titre de remboursement peut dissimuler un désaccord sur les pertes incluses.

Ceci est particulièrement important lorsque des ventes forcées interagissent avec une liquidité faible. La différence entre un devis affiché et un prix exécutable peut devenir significative précisément lorsque la plateforme est sous pression.

Le test durable est le système de contrôle de remplacement

La suppression du fichier malveillant ferme la voie immédiate décrite dans le post-mortem. La question à long terme est de savoir comment les futurs changements de code sont vérifiés, quels privilèges les scripts externes conservent et à quelle vitesse une activité inhabituelle est détectée.

Il existe une hiérarchie sensée ici. Empêcher un script inutile d'atteindre une page sensible est différent de détecter un comportement indésirable après qu'il a déjà commencé. Les deux peuvent être utiles, mais ils ne doivent pas être considérés comme des protections interchangeables.

Les utilisateurs et les contreparties bénéficieront également d'une réconciliation claire des remboursements complétés et de tout litige restant. Un incident peut être résolu opérationnellement tandis que le travail comptable se poursuit.

La mise à jour de Polymarket fournit des informations concrètes sur ces tâches séparées. La prochaine évaluation devrait se concentrer sur les résultats d'indemnisation vérifiés et l'efficacité des contrôles révisés, sans supposer que le règlement blockchain protège seul un utilisateur de chaque composant de l'application utilisée pour y parvenir.

Rédigé par la rédaction et édité par Samuel Rae.