Биржа Bybit подверглась хакерской атаке около 14:00 по всемирному координированному времени (UTC) 21 февраля 2025 года, что привело к убыткам, приближающимся к 1,5 миллиарда долларов — это крупнейший инцидент безопасности в истории криптовалют на сегодняшний день. В отличие от предыдущих взломов, эта кража была вызвана не проблемами с разрешениями смарт-контрактов, а вредоносным обновлением мультиподписного кошелька Safe, используемого Bybit. Злоумышленник обманом заставил нескольких операторов кошелька Safe подписать транзакцию обновления кошелька, тем самым успешно получив контроль над ним. Получив доступ, атакующий вывел средства.
Мы обнаружили, что эта атака была тщательно спланированной операцией, направленной против Bybit: злоумышленник развернул и протестировал контракт для атаки в сети за два дня до запуска основного наступления. В этой статье мы начнем с обзора кошелька Safe, проанализируем весь процесс атаки и в заключение предложим несколько рекомендаций по безопасности.
Что такое мультиподписной кошелек Safe
Мультиподписной кошелек Safe — это тип кошелька на базе смарт-контракта, главной особенностью которого является использование нескольких ключей для авторизации транзакций. Такой кошелек требует, чтобы несколько пользователей (обычно заранее назначенные владельцы ключей) подписали транзакцию, прежде чем перевод или иная операция будут выполнены. Это повышает безопасность и предотвращает возникновение единой точки отказа или последствия компрометации одного ключа.
При создании кошелька настраивается несколько ключей (обычно используется модель «n из m»), что означает, что среди нескольких владельцев ключей для выполнения транзакции требуется определенное количество подписей. Например, мультиподписной кошелек «3 из 5» означает, что для действительности транзакции необходимо как минимум три подписи из пяти владельцев ключей.
Хотя существуют методы формирования транзакций без использования официального сайта Safe, с точки зрения пользовательского опыта большинство пользователей предпочитают создавать и подписывать транзакции через сайт Safe. Как правило, пользователи заходят на https://app.safe.global для формирования транзакций. При использовании кошелька Safe для подготовки и подписания транзакции пользователи сначала имитируют ее, чтобы понять потенциальный результат после выполнения в блокчейне и проверить, соответствует ли он их ожиданиям. Только если результат ожидаем, оператор приступает к процессу подписания.
Ниже приведен скриншот интерфейса формирования транзакции в кошельке Safe. Поскольку сайт Safe в настоящее время временно недоступен, следующий скриншот взят из интернета (источник: https://milkroad.com/reviews/safe-wallet/).
В действительности при использовании кошелька Safe существуют следующие риски безопасности:
-
Длинная цепочка безопасности: Пользователи должны доверять официальному сайту Safe, приложению и серверным службам, а также собственному компьютеру, браузеру и, наконец, кошельку, используемому для подписания (будь то расширение браузера или аппаратный кошелек). Если любой из этих компонентов будет скомпрометирован злоумышленником, оператор может получить неверную информацию (например, вы можете подписывать транзакцию обновления, в то время как интерфейс отображает обычную транзакцию перевода).
-
Отсутствие парсинга транзакций в аппаратных кошельках: Аппаратные кошельки, как правило, не имеют возможности анализировать транзакции Safe. Это означает, что если пользователи введены в заблуждение интерфейсом Safe, у них нет способа перепроверить данные во время финального подписания, что приводит к так называемой «слепой подписи».
Процесс атаки
Перед началом финальной атаки злоумышленник уже развернул и протестировал контракт для атаки в сети. В процессе атаки было задействовано несколько различных адресов.
Шаг 1: Получение средств
Сначала злоумышленнику нужно было получить первоначальные средства для атаки. Обычно атакующие получают средства через миксеры (например, Tornado Cash), чтобы замести следы. Однако в данном случае средства злоумышленника поступили с Binance. Мы полагаем, что это мог быть способ сокрытия личности, поскольку средства и адреса из сервисов микширования обычно находятся под пристальным наблюдением охранных фирм, тогда как средства с бирж отслеживаются менее строго. Кроме того, хотя средства поступили с биржи, возможно, что аккаунт не проходил процедуру KYC или что информация KYC была поддельной.
Шаг 2: Развертывание и тестирование контракта
Перед началом реальной атаки злоумышленник провел серию тестов. Эти тесты включали развертывание кошелька Safe, развертывание контракта для атаки и использование тестового кошелька Safe для выполнения операции обновления, а также вывода средств из обновленного кошелька. Более того, во время тестирования атакующий экспериментировал только с ограниченным набором активов — теми же, что находились в кошельке Bybit, который в итоге был опустошен. Это указывает на то, что злоумышленник целенаправленно выбирал кошелек Safe биржи Bybit.
Злоумышленник создал кошелек Safe для целей тестирования; один из адресов тестового кошелька:
0x509b1eDa8e9FFed34287ccE11f6dE70BFf5fEF55
Атакующий протестировал обновление контракта Safe. Информацию об этом можно посмотреть через Phalcon Explorer по ссылке:
После проверки обновления злоумышленник перешел к тестированию процесса вывода средств. Они напрямую вывели активы stEth из обновленного контракта Safe по адресу:
0x509b1eda8e9ffed34287cce11f6de70bff5fef55
Шаг 3: Обман пользователей для формирования и подписания транзакции обновления
После завершения тестов злоумышленнику нужно было обманом заставить пользователей сформировать и подписать транзакцию обновления контракта Safe. Поскольку тесты проводились двумя днями ранее, обман, вероятно, произошел в течение двух дней после тестов. Пока публично не подтверждено, было ли это достигнуто путем атаки на серверы Safe или на компьютеры операторов кошелька.
Шаг 4: Запуск атаки
Как только злоумышленник получил достаточное количество подписей, он отправил транзакцию в блокчейн и успешно выполнил обновление контракта. После обновления атакующий вывел средства. Мы обнаружили, что вредоносная транзакция обновления была идентична предыдущей тестовой транзакции.
Уроки и выводы
На самом деле подобные атаки случались дважды в прошлом году — включая кражи из Radiant и индийской биржи WazirX (с убытками более 200 миллионов долларов) — все они были результатом вредоносных транзакций, подписанных с использованием кошельков Safe. Разница в этом инциденте заключается в том, что на этот раз была подписана транзакция обновления контракта. Поэтому извлечение уроков из таких инцидентов и предотвращение будущих атак остаются задачей, которую должны решать биржи и проектные команды, владеющие большими объемами цифровых активов. Этого можно достичь путем улучшения повседневных операций, управления внутренними процессами, протоколов безопасности для критических операций и настроек децентрализации для снижения риска быть атакованными.
Во-вторых, вопрос о том, как кошельки могут эффективнее участвовать в процессе обеспечения безопасности при подписании транзакций, остается открытым. В настоящее время аппаратные кошельки, как правило, не способны анализировать сложные транзакции. Более того, поскольку аппаратные кошельки не подключаются напрямую к интернету, проблема выполнения имитации транзакции (и представления результатов пользователям в легко понятной форме), чтобы избежать «слепой подписи», остается актуальной.
Кроме того, необходимо внедрять комплексные меры безопасности, например, использовать платформы мониторинга, такие как BlockSec Phalcon, для контроля кошельков Safe, обеспечивая быстрое обнаружение и устранение любого аномального поведения. На самом деле, Phalcon уже имеет возможность мониторинга кошельков Safe, и мы продолжим обновлять наши продукты, чтобы в будущем такой мониторинг можно было настраивать автоматически, помогая пользователям избегать рисков при использовании Safe для управления крупными суммами активов. Хотя этот инцидент был вызван использованием кошелька Safe, не нужно бояться «Safe»; он остается фактическим стандартом для мультиподписных кошельков, а безопасность его контрактов подтверждена временем.
Наконец, мы должны подчеркнуть, что защита безопасности никогда не бывает полем битвы для прорывов в одной точке, как и не существует «серебряной пули», которая работает раз и навсегда. Обеспечивая операционную и бизнес-безопасность, участники отрасли могут использовать BlockSec Phalcon в качестве последнего рубежа обороны для защиты своих активов.
