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