Не только закрытые ключи: от кошельков, L2 до цепочек поставок — как защитить границы безопасности Web3?

Прошедший июнь ознаменовался в криптомире целой серией инцидентов безопасности, затронувших множество звеньев.

Согласно последнему ежемесячному отчёту безопасности PeckShield, в июне произошло 40 крупных хакерских атак, общий ущерб от которых составил 75,87 миллиона долларов. Что ещё более тревожно, эти атаки не ограничивались одним конкретным вектором, а затронули дефекты реализации подписей в кошельках, уязвимости протоколов L2 и атаки на цепочку поставок сторонних сервисов. В одном месяце оказались скомпрометированы сразу несколько линий обороны.

Когда риски безопасности Web3 расширяются от единой точки входа до всей цепочки взаимодействия, каждый пользователь вынужден заново задаться вопросом: а безопасны ли мои криптоактивы на самом деле?

I. Важность реализации подписей в кошельках помимо закрытых ключей

Инцидент безопасности с кошельком SecondFi в экосистеме Cardano в июне — наиболее наглядный пример.

SecondFi ранее был известен как кошелёк Yoroi в экосистеме Cardano. С 21 по 23 июня злоумышленники вывели около 16 миллионов ADA с адресов некоторых пользователей SecondFi, затронув примерно 374 кошелька. На тот момент стоимость составляла около 2,4 миллиона долларов. Впоследствии SecondFi заявил, что благодаря экстренным мерам дополнительно защитил около 129 миллионов ADA, которые могли оказаться под угрозой.

Самое примечательное в этом инциденте то, что пострадавшие пользователи не передавали свои сид-фразы злоумышленникам добровольно. Проблема заключалась в реализации подписей на уровне кошелька. Согласно анализу агентства безопасности BlockSec, ошибка заключалась в некорректном извлечении nonce для подписи из открытых данных транзакций — был упущен секретный nonce prefix, предусмотренный стандартной реализацией.

Это означало, что каждый раз, когда пользователь подписывал транзакцию с помощью уязвимой версии кошелька, публикуемые на блокчейне открытые данные подписи раскрывали информацию, достаточную для вычисления закрытого ключа адреса. Таким образом, злоумышленнику не нужно было взламывать телефон пользователя или получать сид-фразу; достаточно было проанализировать открытые ончейн-данные, чтобы восстановить закрытый ключ подписи соответствующего адреса.

С точки зрения пользователя, кошелёк продолжал работать нормально: сид-фраза не была раскрыта во всплывающем окне, пароль не взломан, транзакции действительно инициировались самим пользователем. Однако на криптографическом уровне, как только пользовательский адрес создавал несколько действительных подписей с помощью уязвимой версии, открытые данные транзакций и подписей могли позволить злоумышленнику вычислить закрытый ключ подписи этого адреса.

В конечном счёте, безопасность кошелька зависит от того, правильно ли генерируются закрытые ключи, строго ли соблюдаются криптографические стандарты при подписании, а также от того, доступен ли этот критически важный код для внешнего аудита и верификации. Вот почему так важно сохранять открытый исходный код ключевых компонентов кошелька.

Разумеется, это был дефект реализации в конкретной версии конкретного кошелька, а не универсальная проблема всех самостоятельно хранящих кошельков. Например, TokenCore от imToken — открытый репозиторий на GitHub, охватывающий такие базовые функции кошелька, как управление ключами, деривацию адресов и подписание транзакций.

Хотя открытый исходный код не гарантирует отсутствия уязвимостей и не означает, что пользователи могут полностью ослабить бдительность, для наиболее чувствительных криптографических компонентов кошелька он обеспечивает как минимум важное предварительное условие: исследователи безопасности, разработчики и сообщество могут проверять код, воспроизводить проблемы и проводить непрерывное тестирование, вместо того чтобы доверять непроверяемому «чёрному ящику».

Для обычных пользователей подобные инциденты также диктуют несколько более прагматичных принципов безопасности.

Во-первых, кошельки следует загружать только с официальных сайтов или из официальных магазинов приложений и своевременно обновлять до безопасных версий.

Во-вторых, не стоит хранить все активы в одном повседневном кошельке для взаимодействия. Крупные долгосрочные активы лучше хранить с помощью аппаратных кошельков или отдельных холодных кошельков, изолированных от горячего кошелька, который часто подключается к DApp.

Что ещё более важно, если разработчик кошелька официально подтвердил уязвимость на уровне генерации ключей или реализации подписей, простой импорт той же сид-фразы в другой кошелёк, как правило, не решает проблему. После импорта той же сид-фразы в другой кошелёк уже скомпрометированные адреса и закрытые ключи не меняются. Пострадавшие активы необходимо перевести на новый адрес, который никогда не создавал подписей через уязвимую версию. Для обычных пользователей более безопасным подходом обычно является создание совершенно нового набора кошелька и сид-фразы в соответствии с официальной процедурой экстренного реагирования, а затем перенос активов, а не многократный импорт или манипуляции с исходным адресом.

II. L2 — это не просто «более дешёвый Ethereum», это целая сложная цепочка доверия

Помимо кошельков, несколько июньских инцидентов указали на риски, связанные со всё более сложными системами L2.

14 и 18 июня были атакованы два старых развёртывания Rollup, связанных с Aztec, что привело к совокупным потерям около 4,35 миллиона долларов.

Необходимо особо отметить, что атаке подверглись старые развёртывания, такие как Aztec Connect, которые уже находились в режиме устаревшей версии. Это не равноценно атаке на текущую основную сеть Aztec Network. Однако проблемы, выявленные этими двумя инцидентами, весьма поучительны для всей области ZK Rollup.

В одном из инцидентов злоумышленник использовал несоответствие между количеством транзакций и фактически обработанными данными, чтобы система зафиксировала в доказательстве депозит, но обошла соответствующее списание баланса на L1.

Другой инцидент был вызван отсутствием ограничения в схеме доказательства с нулевым разглашением. Система верифицировала формально корректное доказательство, но не обеспечила полного соответствия использованного в доказательстве частного дерева состояний публичному корню состояния на Ethereum, который действительно используется для расчётов. Таким образом, злоумышленник мог сгенерировать доказательство на основе поддельного дерева состояний и вывести активы из контракта L1.

Такого рода проблемы трудно охарактеризовать традиционным «есть ли в контракте строка с уязвимым кодом». Ведь доказательство с нулевым разглашением может подтвердить, что определённый вычислительный процесс соответствует заданным правилам, но при условии, что сами правила корректны и полны. Если разработчик забыл ограничить какую-то ключевую переменную, доказательство всё равно может быть математически верным, но доказывать результат, не соответствующий реальному состоянию расчётов.

Последующий инцидент безопасности с Taiko выявил другой тип риска цепочки доверия L2.

22 июня был использован процесс верификации доказательств на основе SGX в Taiko, что привело к потерям около 1,7 миллиона долларов. Согласно анализу BlockSec, злоумышленник использовал закрытый ключ подписи SGX enclave, который ранее был загружен в публичный репозиторий GitHub. Также была использована уязвимость в контракте верификации на блокчейне, который не отклонял Enclave в режиме DEBUG. Это позволило зарегистрировать вредоносного проверяющего как легитимный экземпляр.

Затем злоумышленник подделал доказательство состояния L2, заставив контракт на Ethereum принять несуществующее состояние L2, и в итоге вывел средства из моста. Суть в том, что ключ, используемый для подписи доверенной среды исполнения (enclave), был раскрыт, а правила удалённой аттестации не полностью проверяли атрибуты среды исполнения. В результате «аттестованное» доказательство утратило своё подразумеваемое доверие.

Тем временем 25–26 июня на Base произошла остановка производства блоков в основной сети. В пост-анализе Base сообщила, что обе остановки были вызваны одним и тем же дефектом в логике построения блоков: неудачно выполненная транзакция не очистила должным образом ранее записанное состояние, что привело к неверному расчёту газа для последующих транзакций и генерации блока, содержащего недопустимое преобразование состояния. Поскольку другие узлы не могли принять такой блок, сеть в конечном итоге остановилась. Base заявила, что целостность цепочки во время инцидента не была нарушена, а средства пользователей всегда оставались в безопасности.

Это не было кражей активов или внешней атакой, а техническим сбоем, повлиявшим на доступность и способность сети к восстановлению. Однако в более широком смысле безопасности доступность сама по себе является частью модели безопасности L2.

Для пользователя безопасность цепочки определяется не только тем, может ли хакер подделать активы, но также и тем, могут ли блоки постоянно производиться, работает ли кроссчейн-мост, могут ли узлы быстро восстановиться, и есть ли у пользователя осуществимый путь выхода в случае сбоя системы.

Поэтому при использовании L2 пользователям не следует сравнивать только комиссии и ожидания от эйрдропа. Для L2 с небольшим масштабом, недавно запущенных или с быстро меняющимися механизмами безопасности следует избегать длительного хранения крупных сумм, превышающих фактические потребности. Перед кроссчейн-переводом следует убедиться, что используется официальный мост, и ознакомиться со временем вывода, механизмом приостановки и способом экстренного выхода. В случае остановки производства блоков, аномалий в кроссчейн-операциях или официальных предупреждений безопасности не следует многократно отправлять транзакции или продолжать перемещать активы через мост.

Более безопасный подход — распределённое управление активами разного назначения и уровня риска, а не концентрация всей ликвидности на одном L2, одном кроссчейн-мосте или одном механизме выхода.

III. Контракт не взломан, но сторонние сервисы могут привести атаку к пользователю

Если проблемы с кошельками и L2 всё ещё лежат в более низкоуровневых технологических компонентах, то инцидент с Polymarket показывает, что ближайший к пользователю веб-фронтенд также может стать точкой входа для кражи средств.

25 июня Polymarket сообщил, что один из используемых им сторонних поставщиков услуг был скомпрометирован. Злоумышленник внедрил вредоносный скрипт в фронтенд Polymarket, к которому обращались некоторые пользователи.

Согласно данным агентств безопасности и ончейн-аналитиков, инцидент привёл к потере пользовательских активов на сумму около 3 миллионов долларов, затронув примерно 11 кошельков. Украденные средства были затем переведены из Polygon на Ethereum и обменяны на примерно 1893 ETH. Впоследствии Polymarket заявил, что удалил скомпрометированную зависимость и полностью возместит ущерб пострадавшим пользователям.

Ключевой момент этого инцидента в том, что пользователи, вероятно, заходили на правильный домен Polymarket; в имеющихся отчётах не указывается на уязвимость в основных смарт-контрактах Polymarket. Проблема была в основном в сторонних зависимостях фронтенда, загружаемых веб-страницей.

Это зеркало: сегодня большинство Web3-приложений не работают полностью на блокчейне. Веб-страницы, которые видят пользователи (например, интерфейсы для торговли), по-прежнему в значительной степени зависят от традиционной интернет-инфраструктуры и сторонних пакетов. Если любая из этих зависимостей будет скомпрометирована, это может позволить легитимному сайту отображать пользователям неверную информацию, подменять адреса для получения средств или побуждать кошелёк подписывать вредоносные транзакции.

Поэтому «URL-адрес настоящий» не обязательно означает «весь код, загруженный в данный момент, безопасен». «Контракт прошёл аудит» не означает, что весь путь взаимодействия между пользователем и контрактом свободен от рисков. Столкнувшись с фронтенд-атаками и атаками на цепочку поставок, обычным пользователям сложно самостоятельно проверить каждый фрагмент кода, загружаемый веб-страницей. Однако они всё же могут ограничить потенциальный ущерб, снизив разрешения для каждого отдельного взаимодействия:

• Используйте отдельный кошелёк для взаимодействия с DApp: не подключайте кошелёк для долгосрочного хранения напрямую к различным сайтам DeFi, NFT, прогнозных рынков и эйрдропов. В повседневном кошельке для взаимодействия храните только средства, предназначенные для использования в ближайшее время. Даже если фронтенд или авторизация будут скомпрометированы, масштаб воздействия будет относительно ограниченным.

• Перед подписанием обращайте внимание на фактические действия, а не только на текст на кнопке: если на странице написано «Войти», «Получить» или «Подтвердить заказ», это не означает, что подпись, появившаяся в кошельке, относится к тому же самому.

• При появлении необычного поведения на странице не продолжайте действовать по инерции: если страница внезапно просит заново импортировать сид-фразу, загрузить дополнительный плагин или отображает содержимое транзакции, не соответствующее описанию на странице, следует приостановить взаимодействие, проверить информацию через несколько официальных каналов проекта, а также проверить и отозвать неиспользуемые исторические разрешения.

С точки зрения продуктов-кошельков, это также означает, что роль кошелька меняется.

Он не должен быть просто инструментом для хранения закрытых ключей и отображения окон подписей. Он также должен помогать пользователям понимать намерения транзакции, выявлять аномальные разрешения, отображать изменения в активах и предоставлять достаточно чёткие предупреждения до совершения высокорисковых взаимодействий.

Однако кошелёк не может устранить все риски за пользователя. Более реалистичная модель безопасности — это совместное сокращение поверхности атаки со стороны кошельков, протоколов, L2, сторонних сервис-провайдеров и пользователей, а не перекладывание всей ответственности на какую-либо одну сторону.

Заключение

Раньше часто говорили: «Кто владеет закрытым ключом, тот владеет ончейн-активами».

Это утверждение по-прежнему верно, но оно не охватывает весь путь от «возникновения намерения совершить транзакцию» до «окончательного расчёта на блокчейне». Сегодня безопасность Web3 — это не просто защита сид-фразы; это защита всей цепочки: от генерации ключей кошельком, отображения транзакции, выполнения подписи до проверки сетью и окончательного расчёта.

Разумеется, это не означает, что пользователям следует избегать любых ончейн-взаимодействий. Для пользователя действительно эффективная привычка безопасности означает раздельное управление активами по назначению, уровню риска и сценарию взаимодействия: долгосрочные активы — максимальная изоляция, повседневные взаимодействия — с небольшими суммами, для незнакомых DApp — минимальные разрешения, для высокорисковых операций — многократная проверка.

В конце концов, когда риски безопасности расширяются от точки до цепочки, защита пользователя также должна перейти от простого сохранения закрытого ключа к целостной системе привычек.

Будем взаимно вдохновляться.