Ostium втратила $23,75 млн через компрометацію Oracle-підписувача на Arbitrum

$23,75 мільйона з єдиного пулу ліквідності, спустошених у восьми транзакціях, направлених через одну пару контрактів і виведених на один гаманець. Такою є картина злому Ostium 15 липня 2026 року, і незручна деталь для кожної DeFi-команди, що читає це: смарт-контракти поводились саме так, як і було визначено. Збій стався на один рівень вище — в офчейн-інфраструктурі oracle та серед людей, які тримають її ключі.

Торгівля на перп-майданчику на базі Arbitrum досі заморожена на момент написання цієї статті, при цьому Ostium обіцяє щонайменше 24 години попередження перед тим, як знову запустити торги. Забезпечення трейдерів та відкриті позиції залишились неушкодженими. Весь збиток ліг на провайдерів ліквідності.

Що сталося

15 липня зловмисник, який мав два набори дійсних облікових даних — один для авторизованого oracle-підписувача та один для зареєстрованого форвардера PriceUpKeep (роль keeper), — почав надсилати криптографічно дійсні, але фактично шахрайські цінові звіти до oracle-конвеєра Ostium. Як задокументувала Rescana, логіка верифікації oracle перевіряла лише те, чи є підписувач у авторизованому списку, і нічого більше. Вона не перевіряла, чи знаходиться заявлена ціна в будь-якому правдоподібному діапазоні реальності.

Маючи цей примітив, механіка була гранично простою. Зловмисник відкривав великі позиції з плечем, пушив ціну oracle підписаним звітом та закривав позиції проти маніпульованого фіду. Повторити вісім разів через ту саму пару контрактів, усі виплати надходили на 0x321Df1...8bfD9. Найбільша одноразова виплата була виконана як атомарний батч, що зациклював відкриття та закриття позицій в одній транзакції — це ефективна інженерія крадіжки: жодного вікна для keeper, щоб помітити щось у процесі.

Після того як сховище Ostium Liquidity Pool (OLP) спорожніло, зловмисник конвертував вкрадені USDC у 12 080 ETH і направив 10 540 з них у TornadoCash. Це залишає приблизно 1 540 ETH незмішаними на момент підготовки звіту — відстежуваний слід: якщо ці залишки будуть нерухомими або потраплять на CEX, аналітичні фірми блокчейну матимуть матеріал для роботи.

Ostium призупинила торгівлю протягом 60 хвилин після першої транзакції злому, повідомила спільноту 16 липня та залучила команду реагування на інциденти і правоохоронців. Galaxy Research опублікував технічний розбір 17 липня. Джерело не розкриває, як саме були скомпрометовані два набори облікових даних, що важливо, оскільки викрадення облікових даних через фішинг, інсайдера або скомпрометовану машину для підписання передбачає дуже різні способи виправлення.

Технічна анатомія

Oracle Ostium — це класична гібридна конструкція: офчейн-воркери збирають та підписують цінові дані, ончейн-форвардер (PriceUpKeep) їх надсилає, а рушій перпів споживає їх як першоджерело. Перевірка підпису відповідає рівно на одне питання: "чи підписано це ключем, якому ми довіряємо?" Вона не відповідає на питання "чи є ця ціна розумною?", "чи є ця ціна актуальною?" або "чи збігається ця ціна з другим незалежним фідом?"

Порівняйте це з тим, як Chainlink структурує свої Data Feeds, де кілька незалежних операторів вузлів надсилають звіти, а ончейн-агрегатор обчислює медіану перед тим, як значення стає доступним споживачам (дивіться документацію Chainlink). Один скомпрометований підписувач у агрегаторі m-of-n може змістити медіану лише в обмеженому вікні, і лише якщо інші оператори мовчать або запізнюються. Конструкція Ostium звела властивість m-of-n фактично до 1-of-1 для цілей цієї атаки: одного дійсного підпису було достатньо для повноважень.

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

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

Хто постраждав

Провайдери ліквідності Ostium поглинули всі $23,75 мільйона. Це збиток першого порядку. Чи буде він відшкодований, залежить від резервів казначейства та страхових угод, які джерело не розкриває, — це єдина найбільша невизначеність на наступні 90 днів. Якщо Ostium соціалізує збиток на LP, очікуйте різкого скорочення TVL після відновлення торгів. Якщо вона поглине збиток із казначейства або страхового фонду, очікуйте повільнішого відтоку LP та переоцінки комісій, які LP вимагатимуть за участь.

Збиток другого порядку торкнеться кожного перп-DEX, що використовує конструкцію oracle з малою кількістю підписувачів. Аудитори почнуть ставити гострі питання щодо зберігання ключів підписувача, використання HSM, розділення ролей keeper та захисту від неправдоподібних цін. Команди, що відповідали на ці питання фразою "наші підписувачі на довіреному сервері", тепер змушені відповідати на них архітектурними діаграмами. Страховики, що покривають DeFi-протоколи, зроблять той самий підрахунок і переоцінять премії відповідним чином.

Сам Arbitrum є стороннім спостерігачем (це не проблема L2), але майданчик важливий для подальших дій правоохоронців. 10 540 ETH у TornadoCash — це оперативний факт відмивання. Джерело зазначає, що використання міксерів є поширеним серед фінансово мотивованих акторів, включаючи північнокорейські угруповання, при цьому прямо стверджуючи, що прямої атрибуції жодній відомій групі немає. Залишок приблизно 1 540 ETH є тестовою межею: якщо протягом наступних 30 днів він потрапить до санкціонованого міксера або KYC-біржі, ми маємо побачити або повідомлення OFAC, або повідомлення про заморожування коштів на біржі з посиланням на гаманець 0x321Df1...8bfD9.

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

Посібник для Crypto та DeFi

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

По-перше, проведіть аудит припущення "лише перевірка підпису". Якщо ваш ончейн-споживач oracle довіряє будь-якому єдиному підписувачу, ставтеся до цього як до активної вразливості. Додайте межі правдоподібності цін (максимальне відхилення від попередньої прийнятої ціни, максимальне відхилення від вторинного фіду, перевірки застарілості відносно міток часу блоків). Нічого з цього не є екзотикою, і будь-яке з них пом'якшило б атаку на Ostium.

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

По-третє, додайте ліміти виплат на блок та на часове вікно до LP-сховищ. Вісім транзакцій для обнуління сховища — це симптом відсутності обмеження швидкості виведення коштів відносно розміру сховища. Ліміт, що автоматично призупиняє сховище, коли відтоки перевищують, скажімо, 5 відсотків TVL у ковзному вікні, дав би команді реагування на інциденти годину реального запасу часу замість 60-хвилинного призупинення по факту.

По-четверте, відпрацюйте призупинення. 60-хвилинна реакція Ostium є пристойною за галузевими нормами, але недостатньо швидкою, щоб мати значення після того, як атомарний батчинг вступив у гру. Команди мають вимірювати час до призупинення від першої аномальної транзакції, а не від людського сповіщення. Для довідки щодо патернів ончейн-автоматичних вимикачів, документація для розробників Ethereum охоплює примітиви; складна частина — підключити їх до детектора аномалій, а не написати функцію призупинення.

Ключові висновки

• $23,75 мільйона покинули сховище OLP Ostium у восьми транзакціях 15 липня 2026 року, всі на один гаманець, без жодної помилки в смарт-контракті.
• Основною причиною став oracle, що перевіряв ідентичність підписувача, але не правдоподібність цін, у поєднанні з компрометацією облікових даних як підписувача, так і keeper.
• 10 540 з 12 080 вкрадених ETH потрапили в TornadoCash; залишок приблизно 1 540 ETH є відстежуваним слідом для атрибуції протягом наступних 30 днів.
• Питання без відповіді з жорсткою межею: джерело не розкриває, як саме були викрадені два набори облікових даних. Поки Ostium не опублікує посмертний аналіз із зазначенням вектора (фішинг, інсайдер, скомпрометована інфраструктура підписання), інші перп-DEX не зможуть знати, чи мають вони ту саму вразливість.
• Прогноз: коли Ostium відновить роботу, APR для OLP має помітно переоцінитись вгору протягом першого тижня, щоб компенсувати LP за щойно виявлений ризик oracle. Якщо цього не відбудеться, ринок не оцінює цю ситуацію правильно.