Трейдеры 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 как провайдера, involved в инциденте с 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 не сообщил, будет ли он восстанавливать проданные контракты, компенсировать клиентам по определённой рыночной цене или применять другой метод. Его публичное обещание охватывает пострадавших трейдеров, не уточняя, как будет обрабатываться каждый тип активности аккаунта.

Документация платформы об ордерах фиксирует этапы между подачей ордера и подтверждением исполненной сделки. Ордера могут оставаться открытыми, совпадать с другим трейдером, истекать или не исполняться.

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

В уведомлении о восстановлении не появилось общеcompany графика выплат. В заявлении компании не предлагалось клиентам платить за восстановление или раскрывать учётные данные для восстановления кошелька, чтобы получить возврат.

Июньская утечка привела к более раннему обещанию полного возврата средств

Более раннее обещание возврата компании последовало за оценкой блокчейн-аналитика 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 по Subresource Integrity описывает метод проверки загруженного скрипта на соответствие криптографическому отпечатку, указанному веб-сайтом.

Если загруженный файл отличается от ожидаемого отпечатка, браузер отказывается его выполнять. Таким образом, поставщику, изменяющему файл, потребовалось бы одобрение новой версии со стороны веб-сайта, прежде чем она смогла бы запуститься при такой проверке.

Защита зависит от того, применяет ли веб-сайт её для соответствующего ресурса. Уведомление Polymarket не сообщает, использовала ли затронутая интеграция такую проверку, и не публикует выводы о том, почему полученный код был принят.

Руководство Mozilla по Content Security Policy описывает ещё один набор механизмов контроля над исполняемыми скриптами. Политика может ограничивать источники или авторизовать конкретный код с помощью nonce и хешей.

Разрешение для хоста поставщика само по себе не проверяет каждый файл, который этот хост предоставляет. Хост может оставаться тем же, в то время как доставляемый с него контент меняется.

Эти механизмы действуют до или в момент выполнения кода в браузере. Они служат иной цели, нежели биржевой надзор, который проверяет ордера после того, как торговый клиент их отправил.

Торговые полномочия и полномочия на вывод средств имеют разные ограничения

Собственная документация Polymarket описывает усилия по ограничению того, что может делать делегированный подписант. Её бета-система сессионных ключей позволяет владельцу кошелька авторизовать отдельный ключ для торговли в заданных пределах.

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

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

Polymarket не указала бета-систему сессионных ключей в качестве точки входа в октябре. Исследователи описывали попытки найти действующий клиент и подписанта, доступных приложению, тогда как компания пока не объяснила, какие разрешения были успешно использованы в каждом затронутом аккаунте.

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

Затем расчёт происходит через блокчейн-контракты. Записи отличают сопоставленный ордер от ордера, расчёт по которому подтверждён или не удался.

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

Публичные выводы не устанавливают, что каждый тип кошелька допускал беззвучное подписание или что каждое предпринятое действие удалось. Polymarket поддерживает несколько вариантов кошельков, и её корпоративное расследование пока не сопоставило затронутые аккаунты с этими вариантами.

Июньский инцидент компании уже выявил аналогичную зависимость от стороннего кода веб-сайта. Её более ранняя компрометация фронтенда включала вредоносный скрипт, доставленный некоторым посетителям через скомпрометированную зависимость.

Октябрьская реакция снова потребовала действий на уровне платформы: торгового ограничения, приостановки действий релеера и исправления затронутой интеграции. Отдельные торговые устройства клиентов не давали им контроля над программным обеспечением, которое веб-сайт решил загрузить.

Возврат средств должен учитывать как сделки, так и недостающую наличность

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

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

Компания не сообщила, будет ли она заменять контракты, использовать цену непосредственно перед спорной продажей или применять иной метод оценки. Она не объявила, что пользователям придется ждать разрешения лежащих в основе событий.

Торговые записи Polymarket и история кошелька предоставляют отдельные части этого счета. История ордеров фиксирует изменения позиций, тогда как записи блокчейна могут показывать последующие переводы обеспечения или токенов.

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

Более раннее июньское расследование отслеживало активы из Polygon через мост и в ETH в Ethereum. Его пересмотренная оценка убытков выросла после первоначального объявления о возврате средств, поскольку аналитики отследили больше активности.

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

Платформа возобновила торговлю в 19:05 UTC 29 октября. В ее публичном уведомлении инцидент с обслуживанием значится как разрешенный, при этом сохраняется обязательство компенсировать пострадавшим клиентам.

На что обратить внимание

Технические выводы: Какие разрешения учетной записи скрипт успешно использовал и какие типы кошельков были затронуты.

Контроль поставщиков: Выводы компании о том, как стороннее программное обеспечение попало в торговое приложение.

Учет убытков: Итоговая сумма компании, которая сверяет пострадавшие счета и несанкционированные транзакции.

Условия возврата средств: Как Polymarket оценивает проданные позиции и когда клиенты получают компенсацию.

Часто задаваемые вопросы