Цю статтю підготував BlockWeeks
Платформа Ostium була атакована зловмисником, який викрав приблизно 24 мільйони доларів США в USDC, що включало вісім транзакцій. Атакуючий, одночасно володіючи ключами підпису авторизованих оракулів та роллю PriceUpKeep переднього плану, подавав правильно підписані звіти про ціни на майбутні дати та багаторазово відкривав і закривав торгові пари, створюючи фіктивний прибуток без жодного реального ринкового ризику.
Атака відбулася у восьми транзакціях, кожна з яких переказувала кошти на той самий гаманець 0x321Df1…8bfD9, причому найбільший одноразовий переказ був циклічною операцією відкриття-закриття, виконаною в атомарному пакеті. Ostium працює на Arbitrum і дозволяє користувачам торгувати деривативами у формі форвардних контрактів, які відстежують ціни базових активів, але не передбачають поставки базового активу чи фіксованої дати погашення.
Проблема виникає через те, як система оракулів Ostium авторизує дані про ціни. Валідатор отримує звіт про ціну, виводить особу підписувача з підпису та перевіряє, чи є підписувач у списку авторизованих. Він перевіряє лише особу підписувача, а не точність самої ціни. Атакуючий, одночасно володіючи ключами підпису авторизованих оракулів та зареєстрованою роллю PriceUpKeep переднього плану (відповідальною за виконання відкладених замовлень), використав цю комбінацію для подання правильно підписаних звітів про ціни на майбутні дати, а потім багаторазово відкривав і закривав торгові пари, що хеджували їх. Це дозволило їм, з точки зору системи, генерувати торговий прибуток без жодного реального ринкового ризику.
Інцидент з Ostium є одним із кількох значних вразливостей на рівні додатків цього року, включаючи випадки Drift та rsETH від KelpDAO. Спільною темою є те, що смарт-контракти та їх логіка залишаються надійними, а атакуючі в основному націлюються на операційну інфраструктуру та людську довіру — у випадку Ostium це були скомпрометовані облікові дані підписувача, у випадку Drift — соціальна інженерія для захоплення попередньо підписаного адміністратора, а у випадку KelpDAO — отруєна RPC-інфраструктура.
Після цих гучних вразливостей деякі закликають встановити захисні заходи на рівні додатків для коштів користувачів, такі як обмеження виведення, щоб стримувати зловмисну поведінку та обмежувати збитки у разі вразливості. Таким пропозиціям слід протистояти.
Обмеження виведення вводить прямий ризик цензури на рівні додатків. Як тільки протокол може в односторонньому порядку затримувати або обмежувати депозити чи виведення користувачів, концепція самозберігання на цьому рівні додатків перестає бути абсолютною і стає умовною. У такому випадку рішення про доступність та використання коштів приймає додаток, а не користувач. Така практика також розмиває межу між атакуючим та звичайним користувачем, оскільки захисні заходи, розроблені для запобігання атакам, неминуче застосовуються до всіх користувачів, які використовують цей додаток.
Ризик "ефекту слизького схилу" ще більше посилює цю проблему. Як тільки протокол технічно має можливість обмежувати або заморожувати депозити/виведення, ця можливість стає прецедентом. Регулятори можуть посилатися на це як на доказ того, що такі додатки вже мають інструменти для виконання наказів про замороження, KYC-бар'єрів або інших вимог, і тому їх також слід зобов'язати це робити. Захисні заходи, побудовані для запобігання атакам, можуть перетворитися на гачок, який притягує протоколи до зобов'язань, які вони інакше не могли б взяти на себе.
Крім того, невинні учасники ринку також будуть стимульовані обходити тертя, спричинені такими заходами. Наприклад, обмежені користувачі, які шукають способи вийти з економічного ризику, зазвичай означають появу торгованої вимоги для заповнення прогалини (наприклад, токени-квитанції, боргові розписки, обгорнуті замінники криптовалют). Ця вимога сама стає новою залежністю з власним профілем ризику — на ринковому рівні (можливий розрив прив'язки, розширення дисконту під час паніки) та на технічному рівні (нові контракти, нові оракули, нові незалежні від додатку об'єкти, які можна експлуатувати). Захисні заходи, призначені для стримування єдиної точки відмови, зрештою посилюють вразливість, яку вони намагаються запобігти.
Такий контент не означає, що протоколи не повинні посилювати те, що дійсно виходить з ладу (наприклад, управління ключами підписувача, резервування валідаторів). Але спосіб виправлення слабких місць в операційній інфраструктурі та людській довірі полягає в посиленні цих аспектів, а не в додаванні довільних контролів над коштами користувачів, які підривають основну ціннісну пропозицію того, що захищається.
