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

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

Автор: imToken

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. 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, в конечном итоге извлекая активы из мостовых средств, что произошло из-за того, что ключ, используемый для подписания доверенной среды выполнения, был раскрыт, а правила удаленной аутентификации не проверяли атрибуты среды выполнения полностью, что в конечном итоге сделало «сертифицированное» доказательство недействительным.

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

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

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

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

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

3. Контракты не были взломаны, но третьи стороны также могут принести атаки пользователям

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

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

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

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

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

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

• Используйте отдельный кошелек для взаимодействия с DApp: долгосрочные сберегательные кошельки не следует напрямую подключать к различным DeFi, NFT, предсказательным рынкам и сайтам аирдропов, повседневные кошельки должны хранить только средства, которые планируется использовать в ближайшее время, даже если фронтенд или разрешения вызывают проблемы, масштаб воздействия будет относительно ограничен;
• Обратите внимание на фактические действия перед подписанием, а не просто на кнопки на веб-странице: если на веб-странице написано «войти», «получить» или «подтвердить заказ», это не обязательно означает, что подпись, появляющаяся в кошельке, является тем же самым действием;
• Если веб-страница показывает аномалии, не полагайтесь на привычные действия: если страница внезапно требует повторного импорта мнемонической фразы, загрузки дополнительных плагинов или отображает содержимое транзакции, которое не соответствует описанию на веб-странице, следует приостановить взаимодействие, подтвердить ситуацию через несколько официальных каналов проекта и проверить или отменить неиспользуемые исторические разрешения;

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

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

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

В заключение

Ранее говорили, что кто владеет приватным ключом, тот владеет активами на цепочке.

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

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

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

Давайте поддерживать друг друга.