Polymarket відновив торгівлю 29 жовтня після того, як скомпрометований сторонній провайдер призвів до переривання міжнародного прогнозного ринку. Цей інцидент став другим безпековим порушенням на мільйони доларів за чотири місяці для Polymarket. Офіційний журнал інциденту Polymarket фіксує початок обмежень на торгівлю о 18:05 UTC, а вирішення — о 19:05 UTC. Polymarket повідомив, що проблему було виправлено, а правоохоронні органи були сповіщенні. Polymarket також обіцяв повну компенсацію для постраждалих користувачів.
Bubblemaps, фірма з аналізу блокчейну, оцінила, що взлом 29 жовтня вплинув на більше ніж 700 користувачів Polymarket і скомпрометував приблизно $3,46 мільйона активів. Зловмисники обміняли близько $2,7 мільйона на POL і вивели кошти. Ще $750 000 залишилися на Polymarket на момент проведення оцінки.
Polymarket повідомила 25 червня, що скомпрометований постачальник увімкнув введення шкідливого сценарію. Polymarket заявила, що вразливий залежний елемент було видалено, і обіцяла повне повернення коштів. Source Defense повідомила про збитки приблизно на $3 мільйони внаслідок атаки у червні. Source Defense встановила, що доставка здійснювалася через маркетинговий тег, який завантажував зовнішню бібліотеку ідентичності, яку атакуючий замінив на дренер, розрахований на Polymarket. Дослідники Source Defense сказали, що завантаження у червні цілилося у гаманці з більш ніж $100 000 і неодноразово намагалося отримати цифрове дозволення. Схвалене дозволення проходило через релей Polymarket, який надсилає підписані дії.
Аналіз Hudson Rock за жовтень описував код, отриманий з URL, пов’язаного з DebugBear, який шукав активного клієнта для торгівлі та підписувача в межах увійденої сесії. Підписувач — це компонент, який запитує криптографічну авторизацію. Hudson Rock виявив, що програмна поведінка сценарію варіювалася залежно від типу акаунту. Один гілка запитувала перекази токенів позиції; інша — продажі з подальшим переказом отриманих коштів. Hudson Rock також виявив метадані збірки для виробництва, які фіксували видалення скрипта моніторингу DebugBear. Однак статичний аналіз Hudson Rock не підтвердив, що код виконувався, тихо отримував підписи чи крав приватні ключі. Аналогічно, аналіз не встановив повного ланцюжка від жертв до одержувачів. Метадані про видалення не визначають точно, коли закінчилася експозиція користувачів.
Маркетинговий сценарій червня та сценарій, пов’язаний із моніторингом у жовтні, надавали різні шляхи доступу до фінансово чутливої інтерфейсу. Механізм червня, як повідомляється, залежав від схвалених авторизацій, тоді як код жовтня шукав інструменти для торгівлі та запитував підписи. Заміна лише скомпрометованого постачальника не вирішує загальної проблеми зловмисного коду, що досягає фінансових функцій на веб-сайті. Повторні порушення викликають питання щодо фінансових повноважень, до яких зовнішній код може отримати доступ через браузер трейдера.
Документація MDN з браузерів стверджує, що сторонній сценарій, завантажений безпосередньо на сторінку, може отримати доступ до інших сценаріїв і даних на цій сторінці. MDN пояснює, що розміщення сценарію в іншому місці не видаляє цього доступу, тоді як контент з іншого походження в окремому фреймі має іншу межу безпеки. Зменшення зовнішнього коду, обмеження запитів підпису та перевірка завантажених файлів вирішують різні етапи ланцюжка атаки. Видалення непотрібних інтеграцій із сторінок торгівлі та підпису зменшує кількість зовнішнього коду, що дозволено в цих середовищах. Перевірка доступу підписувача та визначення дій, які потребують нової підтвердження користувача, обмежують запити, які код може здійснювати після отримання доступу.
Subresource Integrity дозволяє браузерам перевіряти завантажені скрипти проти очікуваного криптографічного відбитка та відхиляти змінені файли. Subresource Integrity також може захищати відповідно закріплений ресурс, розміщений на довіреному домені. Детальний постмортем, що охоплює період витоку, постраждалі акаунти та маршрути авторизації, допоможе оцінити залишковий ризик. Чи може ще один скомпрометований інтеграційний компонент перетворити доступ до інтерфейсу торгівлі на придатну фінансову авторизацію, залишається невирішеним.
Polymarket зазнав другої багатомільйонної кібератаки за чотири місяці
CryptoSlateПоділитися
Короткий зміст
Polymarket зазнав другої серйозної порушення безпеки 29 жовтня 2026 року після компрометації стороннього провайдера. Атака вплинула на понад 700 користувачів та $3,46 мільйона активів, з яких $2,7 мільйона було виведено. Обсяг торгівлі різко знизився під час інциденту. Polymarket запобіг повну компенсацію та повідомив органи влади. Bubblemaps повідомили про порушення, а Hudson Rock встановив, що шкідливий скрипт походить від DebugBear. Це відбулося після подібного інциденту у червні 2026 року, який також був пов’язаний із постачальником. Індекс страху та жадібності для криптовалютних ринків з того часу впав до медв’ячого рівня.
Джерело:Показати оригінал
Відмова від відповідальності: Інформація на цій сторінці може бути отримана від третіх осіб і не обов'язково відображає погляди або думки KuCoin. Цей контент надається лише для загального інформування, без будь-яких запевнень або гарантій, а також не може розглядатися як фінансова або інвестиційна порада. KuCoin не несе відповідальності за будь-які помилки або упущення, а також за будь-які результати, отримані в результаті використання цієї інформації.
Інвестиції в цифрові активи можуть бути ризикованими. Будь ласка, ретельно оцініть ризики продукту та свою толерантність до ризику, виходячи з ваших власних фінансових обставин. Для отримання додаткової інформації, будь ласка, зверніться до наших Умов використання та Розкриття інформації про ризики.