Трейдери Polymarket втратили кошти через постачальника вебсайту. Наскільки безпечний торговий екран?

Порушення безпеки Polymarket 29 жовтня торкнулося трейдерів через скомпрометованого постачальника вебсайту. Дослідники виявили код, який намагався використати авторизовані облікові записи для продажу позицій і переміщення активів, що викриває довіру, яку трейдери покладають на екран, який вони використовують для управління своїми грошима.

Трейдер під іменем Car сказав, що приблизно 800 000 доларів зникли з його облікового запису Polymarket і всі його позиції були продані. Він сказав, що продовжував торгувати на окремому пристрої та уникав незнайомих посилань.

Інші трейдери повідомляли про збитки, коли Polymarket обмежив свою міжнародну біржу 29 жовтня. Компанія пізніше підтвердила, що сторонній постачальник був скомпрометований, і пообіцяла відшкодувати постраждалим клієнтам.

Технічний звіт, що з'являється, вказує на програмне забезпечення, завантажене всередині справжнього торгового вебсайту. Дослідники з безпеки виявили скрипт моніторингу, який намагався отримати доступ до інструментів, які використовує авторизований трейдер для розміщення ордерів і авторизації дій з гаманцем.

Для цих користувачів небезпека могла прийти через сторінку, яку вони вже відкрили для торгівлі. Розслідування стосується програмного забезпечення, що працює всередині цієї сторінки, та дозволів облікового запису, до яких воно могло отримати доступ.

Повідомлення про інцидент Polymarket фіксує зупинку з 18:05 до 19:05 UTC. Компанія заявила, що виправила проблему та передала інцидент правоохоронним органам, але не оприлюднила повне розслідування чи остаточну суму збитків.

Порушення сталося через 4 місяці після того, як інший скомпрометований постачальник впровадив шкідливий код на вебсайт. Polymarket також пообіцяв відшкодування після того інциденту.

Трейдери повідомляли про продані позиції до того, як Polymarket зупинив торгівлю

Трейдер під іменем Car сказав, що з його облікового запису було виведено приблизно 800 000 доларів, а його друг втратив ще 600 000 доларів. Він сказав, що всі його позиції були продані.

У дописах, що описують інцидент, Car сказав, що розділяв свою особисту діяльність, розробку програмного забезпечення та торгівлю між різними пристроями. Він підозрював проблему з вебсайтом платформи, оскільки інші користувачі, схоже, також постраждали.

Його обліковий запис описував збитки, зазнані під час використання торгового сервісу, а не переказ, який він, за його словами, навмисно схвалив. Подальша заява Polymarket підтвердила скомпрометованого постачальника, хоча вона не опублікувала висновків щодо його окремого облікового запису.

Інший обліковий запис, StarPlatinum, відстежував підозрюваний гаманець-одержувач і оцінив, що на ньому накопичилося 2,68 мільйона доларів. Обліковий запис заявив, що баланс зріс протягом приблизно години виведень.

Хронологія спостерігача відносила перші надходження приблизно до 17:05 UTC, до того як компанія опублікувала своє початкове обмеження обслуговування. Він стверджував, що гаманець містив 412 000 доларів станом на 17:25 UTC і 2,02 мільйона доларів станом на 17:50 UTC.

Як раніше повідомляв crypto.news, початкові повідомлення про збитки включали твердження, що кошти пройшли через інфраструктуру депозитних гаманців Polymarket. Ці описи надходили від трейдерів і блокчейн-спостерігачів, поки компанія ще проводила розслідування.

Компанія пізніше заявила, що виправила проблему та відшкодує постраждалим користувачам. Вона не підтвердила індивідуальні суми збитків і не прийняла оцінку спостерігача як свій остаточний облік.

Скріншот, що поширювався під час інциденту, показував запит на підписання гаманця, пов'язаний з доменом Polymarket. Він відображав поле даних DepositWallet та ідентифікатор ланцюга Polygon, але не показував завершеної транзакції чи повних деталей, необхідних для відтворення активності окремого облікового запису.

Повідомлення користувачів включали як активи, переведені з облікових записів, так і позиції, продані до того, як їхні власники мали намір їх закрити. Polymarket не повідомив, чи кожен постраждалий користувач зазнав обох.

Polymarket відновив роботу після годинної зупинки

Спочатку Polymarket перевів біржу в режим лише скасування та призупинив дії релеєра, поки його команда проводила розслідування. Обмеження дозволяло користувачам скасовувати наявні ордери, тоді як нові ордери та угоди не оброблялися.

О 18:37 UTC компанія повідомила, що виявила та виправила проблему, яка впливала на її міжнародну платформу. Вона заявила, що стороннього постачальника було скомпрометовано, і що торгівля залишалася тимчасово призупиненою як запобіжний захід.

Сторінка статусу містила ще одне оновлення о 18:55 UTC, у якому йшлося, що торгівля відновиться приблизно о 15:00 за східним часом. Інцидент було позначено як вирішений о 19:05 UTC, або о 15:05 за східним літнім часом.

Повідомлення компанії про відновлення роботи повторювало її зобов'язання відшкодувати кошти постраждалим трейдерам. У повідомленні не зазначалося, що всі відшкодування вже були виплачені на момент відновлення торгівлі.

Релеєр Polymarket є частиною інфраструктури, яка використовується для подання підписаних дій гаманця до блокчейну. Призупинення цих дій супроводжувало обмеження на його книгу ордерів під час розслідування.

У своїй документації щодо торгівлі вона описує систему, в якій користувачі створюють підписані ордери, оператор зіставляє покупців і продавців, а контракти розраховують угоди в блокчейні. У повідомленні про інцидент у жовтні серед постраждалих сервісів було названо Predictions Trading API, який зазвичай називають CLOB.

Компанія продовжувала публікувати оновлення через свій публічний сервіс статусу в міру розвитку реагування. Доступ до облікового запису, ринкові дані та виконання ордерів перелічені там окремо.

Обмеження, оголошене 29 жовтня, стосувалося міжнародної платформи. Polymarket не назвав свою окрему американську біржу постраждалим майданчиком у повідомленні про інцидент.

Сервіс відновив роботу, поки тривало розслідування несанкціонованих транзакцій. Публічні оновлення не називали зловмисника і не описували, як постачальника було вперше скомпрометовано.

Згідно із заявою Polymarket та подальшими повідомленнями, компанія передала інцидент владі Сполученого Королівства. DebugBear базується у Великій Британії.

Слідчі пов'язали злам із скриптом моніторингу

Продукти DebugBear допомагають операторам вебсайтів вимірювати швидкість завантаження та інші аспекти досвіду відвідувачів. Його сервіс моніторингу реальних користувачів використовує JavaScript, вбудований на вебсайті клієнта.

Постачальник визнав триваючий інцидент безпеки та порадив клієнтам, які використовують цей продукт, видалити його код вбудовування. Reuters ідентифікував DebugBear як постачальника, залученого до інциденту з Polymarket, посилаючись на особу, обізнану з питанням.

Власне повідомлення про статус Polymarket згадувало стороннього постачальника, не називаючи його. Компанія заявила, що проблему виправлено, але не опублікувала повний технічний звіт разом із цим оголошенням.

Компанія з безпеки Hudson Rock дослідила файл JavaScript, що надавався з інфраструктури DebugBear. У своєму розслідуванні дослідники заявили, що файл шукав у запущеній програмі Polymarket торговий клієнт і підписувач, які використовує авторизований обліковий запис.

Компанія заявила, що код перевіряв баланси та позиції, перш ніж намагатися перемістити цінність на налаштованого одержувача. Вона виявила різні шляхи для переказу токенів позицій і продажу позицій перед спробою переказати виручені кошти.

Hudson Rock заявила, що код прагнув повторно використати доступ, наявний в автентифікованій сесії. Її перевірка не виявила процедури, яка надсилала б seed-фразу, пароль або приватний ключ до кінцевої точки звітування скрипта.

Дослідники виявили згадку про видалення інтеграції DebugBear у метаданих робочої збірки Polymarket. Вони заявили, що цей запис підтверджує видалення інтеграції, залишаючи невирішеним точний період наражаності користувачів на ризик.

BleepingComputer окремо вивчив копію скрипта та описав спроби використати наявні торгові сесії для розміщення ордерів і переказу активів. Його огляд блокчейну прослідкував приблизно 28,6 мільйона POL від ймовірного одержувача до трьох додаткових гаманців.

Видання оцінило цей рух приблизно в 2,57 мільйона доларів на момент свого дослідження. Hudson Rock посилався на окремий знімок балансу одержувача близько 2,19 мільйона доларів, тоді як інші спостерігачі повідомляли про суми близько 2,7 мільйона доларів.

Polymarket не узгодив ці оцінки у звіті про збитки компанії. У звітах використовувалися різні спостереження та часи оцінки під час розслідування, яке ще тривало.

Жодне з публічних оновлень компанії не встановило особу, яка контролює гаманець одержувача. Компрометація постачальника, повідомлення про несанкціоновану торгівлю та подальші перекази залишаються предметом розслідування, переданого правоохоронним органам.

Обіцянка відшкодування охоплює трейдерів, чиї позиції були продані

Polymarket заявив, що постраждалі користувачі отримають повну компенсацію, і повторив, що повністю відшкодує трейдерам після відновлення роботи сервісу. У заяві не встановлено кінцевого терміну для подання претензій і не вимагалося від кожного клієнта виводити кошти протягом певного періоду.

Компанія не опублікувала детальну політику відшкодування щодо жовтневого інциденту. Вона ще не заявила, чи будуть виплати автоматичними в кожному випадку, чи деяким користувачам потрібно буде надати інформацію про спірну активність.

Повідомлення Кара про те, що його позиції були продані, порушує питання, яке виходить за межі відсутнього балансу гаманця. Трейдер може володіти контрактами на подію, яка ще не відбулася, продати їх до вирішення або зберегти їх до визначення результату.

Документація Polymarket щодо позицій описує володіння Yes і No окремо від застави, використаної для їх купівлі. Повний набір забезпечений 1 pUSD, тоді як остаточна виплата за окремим результатом залежить від зафіксованого результату.

Правила платформи дозволяють трейдерам продавати позиції до вирішення. Коли відбувається несанкціонований продаж, історія торгівлі облікового запису може фіксувати як вилучені контракти, так і отримані кошти до будь-якого подальшого виведення.

Polymarket не повідомив, чи відновить продані контракти, чи компенсує клієнтам за певною ринковою ціною, чи застосує інший метод. Його публічна обіцянка охоплює постраждалих трейдерів, не уточнюючи, як буде оброблятися кожен тип активності облікового запису.

Документація платформи щодо ордерів фіксує етапи між поданням ордера та підтвердженням виконаної угоди. Ордери можуть залишатися відкритими, зіставлятися з іншим трейдером, спливати або не виконуватися.

Компанія може використовувати як торгові записи, так і записи блокчейну під час перегляду спірної активності. Повідомлення користувачів про небажані продажі стосуються історії ордерів, тоді як перекази з гаманця залишають окремий запис транзакцій.

У повідомленні про відновлення не з’явився загальнокомпанійний графік виплат. У заяві компанії не вимагалося від клієнтів сплачувати плату за відновлення або розкривати облікові дані для відновлення гаманця для отримання відшкодування.

Червневий злам призвів до попередньої обіцянки повного відшкодування

Попередня обіцянка відшкодування компанії була зроблена після оцінки блокчейн-аналітика Specter, що щонайменше 11 гаманців втратили приблизно 2,94 мільйона доларів. Аналітик описав користувачів, які володіли PUSD, чиї активи згодом були конвертовані в ETH.

Specter охарактеризував інцидент як фішинг через уражений інтерфейс. У розкритті компанії було вказано скомпрометованого постачальника як шлях, через який скрипт потрапив до деяких користувачів.

Пізніше AMLBot підвищив оцінку червневих втрат до 3,1 мільйона доларів. У його звіті від 27 червня описано PUSD, взяті на Polygon, конвертовані через Relay, переведені до Ethereum та обміняні на ETH.

Червневе зобов’язання Polymarket полягало в повному відшкодуванні постраждалим користувачам. Жовтнева заява компанії містила нову обіцянку відшкодування щодо останнього інциденту.

Компанія не заявила, що два злами стосувалися одного й того самого постачальника або зловмисника. Червневе розкриття та жовтневе розслідування обидва стосуються зовнішнього програмного забезпечення, використовуваного платформою, але вони описують окремі події з інтервалом у чотири місяці.

Попередній інцидент стався, коли Polymarket розширював використання PUSD у своїй торговій інфраструктурі. У своїй червневій заяві компанія звернулася до користувачів, постраждалих від шкідливого скрипту, не оголошуючи про призупинення всіх ринків, що пропонуються під брендом Polymarket.

Жовтнева відповідь знову включала видалення або виправлення скомпрометованої інтеграції та обмеження активності, поки команда проводила розслідування. Технічні деталі та загальна кількість постраждалих, оприлюднені в кожному випадку, з'являлися в різні терміни.

Червневі звіти не містили детального звіту за кожною транзакцією, який би засвідчував завершення кожного відшкодування. Останнє повідомлення Polymarket також не публікує список завершених жовтневих відшкодувань.

Дослідники вивчили програмне забезпечення, що працює всередині торгової сторінки

Розслідування зосередилося на коді, який завантажується веб-сайтом, що користувачі вже впізнавали. Звіт Hudson Rock описував спроби знайти торговий клієнт у межах запущеної програми, а не вказівку користувачам відвідати окремо брендовану біржу.

Документація щодо браузера, яку підтримує Mozilla, пояснює, що JavaScript, включений безпосередньо в сторінку, може отримувати доступ до інших скриптів і даних у цій сторінці. Скрипт моніторингу, завантажений у такий спосіб, працює з доступом, який відрізняється від вмісту, ізольованого в окремому фреймі.

Оператори веб-сайтів використовують такі інтеграції для аналітики, звітування про помилки та вимірювання продуктивності. DebugBear описує свій продукт моніторингу реальних користувачів як такий, що збирає інформацію про те, як відвідувачі взаємодіють із веб-сайтом.

Торговий інтерфейс Polymarket виконує інший набір завдань, зокрема відображення позицій, підготовку ордерів і взаємодію з підписувачем. Дослідники заявили, що отриманий файл містив логіку, спрямовану на ці торгові функції.

Документація Polymarket щодо гаманців описує кілька типів облікових записів, зокрема депозитні гаманці, а також застарілі проксі-гаманці та сейф-гаманці. У своїй документації компанія відносить депозитні гаманці до облікових записів, розгорнутих 4 травня 2026 року або пізніше.

Платформа дозволяє власнику гаманця авторизувати окремого підписувача для визначеної торгової діяльності. У документації щодо бета-версії сесійних ключів зазначено, що такий ключ може торгувати від імені депозитного гаманця, але не може виводити його кошти.

Компанія не назвала сесійні ключі причиною жовтневого зламу. Звіт дослідників описує спроби використати клієнт і підписувача, які вже були доступні в програмі.

Посібник Polymarket щодо ордерів зазначає, що користувачі підписують структуровані повідомлення, які містять ідентифікатор результату угоди, сторону, ціну, розмір та інші умови. Оператор перевіряє підписи, баланси та дозволи перед зіставленням ордера.

Зіставлені угоди потім передаються до контрактів розрахунку, причому платформа фіксує, чи було виконання підтверджено або чи зазнало воно невдачі. Жовтневе повідомлення про статус не повідомляло про збій консенсусу Polygon і не оголошувало, що кожен контракт розрахунку було скомпрометовано.

Публічна відповідь компанії наразі визнала компрометацію постачальника та пообіцяла компенсацію, не оприлюднивши повного звіту про кожен шлях підписання та переказу.

Захист браузера залежить від того, якому коду довіряє веб-сайт

Веб-сайт може завантажувати програмне забезпечення постачальника, не перенаправляючи відвідувача на іншу адресу. Браузер отримує файл у процесі відкриття сторінки разом із власним кодом програми біржі.

Документація Mozilla щодо браузера пояснює, що скрипт, вбудований безпосередньо в сторінку, може працювати з доступом цієї сторінки. Комерційна роль постачальника як монітора продуктивності сама по собі не накладає обмеження браузера, яке б зводило його код виключно до вимірювання часу завантаження.

Вміст, розміщений в окремому ізольованому фреймі, має інші межі. Скрипт, включений у торгову програму, не набуває такої ізоляції лише тому, що його постачає інша компанія.

Жовтневе розслідування поміщає цю відмінність у контекст фінансової програми. Сторінка Polymarket відображає баланси та позиції, підключаючись до сервісів, які готують ордери та запитують підписи.

Компанія не опублікувала повного переліку зовнішнього коду, якому дозволено працювати в цьому середовищі. У її заяві про інцидент визнається компрометація постачальника без опису перевірки дозволів, що передувала інтеграції.

Браузери надають засоби контролю, покликані обмежити цю вразливість. Документація Mozilla щодо цілісності підресурсів описує метод перевірки завантаженого скрипту за криптографічним відбитком, вказаним вебсайтом.

Якщо завантажений файл відрізняється від очікуваного відбитка, браузер відмовляється його виконувати. Тому постачальник, який змінює файл, вимагатиме від вебсайту схвалення нової версії, перш ніж вона зможе запуститися за такої перевірки.

Захист залежить від того, чи застосовує вебсайт його для відповідного ресурсу. Повідомлення Polymarket не вказує, чи використовувала уражена інтеграція таку перевірку, чи публікує висновки про те, чому отриманий код було прийнято.

Настанова Mozilla щодо політики безпеки вмісту описує ще один набір засобів контролю над виконуваними скриптами. Політика може обмежувати джерела або авторизувати конкретний код за допомогою nonce та хешів.

Дозвіл для хоста постачальника сам по собі не перевіряє кожен файл, який цей хост надає. Хост може залишатися тим самим, тоді як вміст, що з нього доставляється, змінюється.

Ці засоби контролю діють до або під час виконання коду в браузері. Вони слугують іншій меті, ніж біржовий нагляд, який перевіряє ордери після того, як торговий клієнт їх подав.

Торгові повноваження та повноваження на виведення коштів мають різні межі

Власна документація Polymarket описує зусилля з обмеження того, що може робити делегований підписувач. Її бета-система сесійних ключів дозволяє власнику гаманця авторизувати окремий ключ для торгівлі в межах визначених лімітів.

Документація зазначає, що сесійний ключ не може виводити кошти. Його дозволи можуть охоплювати центральний книжковий ордер, комбіновані угоди або підтримувані торгові майданчики, а власник надає авторизацію на визначений період.

Торговий дозвіл усе ще допускає діяльність, яка змінює портфель. Ця відмінність важлива для клієнтів, які повідомляють про продаж позицій без їхньої згоди, ще до того, як будь-які кошти залишать гаманець.

Polymarket не визначив бета-систему сесійних ключів як точку входу в жовтні. Дослідники описали спроби знайти живий клієнт і підписувача, доступних застосунку, тоді як компанія ще не пояснила, які дозволи були успішно використані в кожному ураженому обліковому записі.

Посібник із життєвого циклу ордера платформи описує ордери, підписані поза мережею, перш ніж оператор їх перевірить і зіставить. Перевірки охоплюють підпис, баланси рахунків і дозволи, серед інших умов.

Потім розрахунок відбувається через блокчейн-контракти. Записи розрізняють зіставлений ордер від того, чий розрахунок підтверджено або який зазнав невдачі.

Дійсний підпис є частиною цього процесу, але він не встановлює, що особа, яка бачить екран, хотіла цієї транзакції. Описана атака прагнула використати авторизацію, доступну через застосунок, який готує ці запити.

Публічні висновки не встановлюють, що кожен тип гаманця дозволяв тихе підписування або що кожна спроба дії була успішною. Polymarket підтримує кілька конфігурацій гаманців, і її внутрішнє розслідування ще не зіставило уражені облікові записи з цими конфігураціями.

Інцидент компанії в червні вже виявив подібну залежність від стороннього коду вебсайту. Її попередній злам фронтенду включав шкідливий скрипт, доставлений деяким відвідувачам через скомпрометовану залежність.

Жовтнева реакція знову вимагала дій на рівні платформи: торгове обмеження, призупинені дії релеєра та виправлення ураженої інтеграції. Окремі торгові пристрої клієнтів не давали їм контролю над програмним забезпеченням, яке вебсайт вирішив завантажити.

Відшкодування має враховувати як угоди, так і відсутні кошти

Polymarket пообіцяв відшкодувати постраждалим користувачам, але його повідомлення про статус не пояснює, як він оцінюватиме позиції, закриті без згоди їхніх власників. Відновлення грошового балансу та відновлення відкритої позиції за подією можуть призвести до різних залишків на рахунку.

Трейдер, чиї контракти були продані, міг мати намір утримувати їх до оголошення результату виборів або розв'язання іншої події. Записи про продаж показують, яку ціну контракти принесли на той момент, тоді як їхня подальша ринкова вартість може змінитися до моменту відшкодування.

Компанія не повідомила, чи замінюватиме контракти, чи використовуватиме ціну безпосередньо перед спірним продажем, чи застосує інший метод оцінки. Вона не оголосила, що користувачам доведеться чекати на розв'язання відповідних подій.

Торгові записи Polymarket та історія гаманця надають окремі частини цього обліку. Історія ордерів фіксує зміни в позиціях, тоді як записи блокчейну можуть показувати подальші перекази забезпечення або токенів.

Баланс гаманця-отримувача сам по собі не може визначити втрати кожного клієнта. Окремі вимоги можуть включати низку угод, переказів і подальших рухів через інші адреси.

Попереднє червневе розслідування відстежувало активи від Polygon через міст і в ETH на Ethereum. Його переглянута оцінка втрат зросла після початкового оголошення про відшкодування, оскільки аналітики відстежили більше активності.

Polymarket не опублікував жовтневий граничний термін подання вимог або графік виплат. Його міжнародна служба підтримки залишається окремою від американської біржі, яку повідомлення про інцидент не визначило як постраждалу.

Платформа відновила торгівлю о 19:05 UTC 29 жовтня. Її публічне повідомлення фіксує інцидент обслуговування як вирішений, зберігаючи зобов'язання компенсувати постраждалим клієнтам.

На що звернути увагу

Технічні висновки: Які дозволи облікового запису скрипт успішно використав і які типи гаманців були уражені.

Контроль постачальників: Висновки компанії про те, як зовнішнє програмне забезпечення потрапило до торгового застосунку.

Облік втрат: Загальна сума компанії, яка узгоджує уражені рахунки та несанкціоновані транзакції.

Умови відшкодування: Як Polymarket оцінює продані позиції та коли клієнти отримують компенсацію.

FAQ