В июне, который только что прошел, криптомир пережил серию инцидентов безопасности, затронувших множество звеньев.
Согласно последнему ежемесячному отчету о безопасности от 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.
Таким образом, каждый раз, когда пользователь подписывал транзакцию в затронутой версии кошелька, публичные данные подписи, размещенные в блокчейне, раскрывали информацию, достаточную для вычисления приватного ключа адреса. Поэтому злоумышленникам не нужно было взламывать телефон пользователя или получать сид-фразу — им достаточно было проанализировать публичные данные в блокчейне, чтобы восстановить приватный ключ подписи для соответствующего адреса.
С точки зрения пользователя, кошелек продолжал работать нормально: сид-фраза не всплывала в окнах, пароль не был взломан, транзакции действительно инициировались им самим. Но с криптографической точки зрения, если адрес пользователя когда-либо создавал действительные подписи через затронутую версию, публичные данные о транзакциях и подписях могли помочь злоумышленнику вывести приватный ключ подписи для этого адреса.
В конечном счете, безопасность кошелька зависит от корректности генерации приватных ключей, строгого следования криптографическим стандартам при подписании и возможности внешнего аудита и верификации этого критического кода. В этом заключается важность поддержания открытого исходного кода для ключевых компонентов кошелька.
Конечно, это дефект реализации конкретной версии конкретного кошелька, а не общая проблема всех некастодиальных кошельков. Например, TokenCore от imToken — его основной репозиторий с кодом открыто размещен на GitHub и охватывает базовые функции кошелька, такие как управление ключами, генерация адресов и подпись транзакций.
Хотя открытый исходный код не гарантирует отсутствия уязвимостей и тем более не означает, что пользователи могут полностью расслабиться, для самых чувствительных криптографических и подписывающих компонентов кошелька открытый код, по крайней мере, предоставляет важную предпосылку: исследователи безопасности, разработчики и сообщество могут проверять код, воспроизводить проблемы и постоянно тестировать, а не просто доверять непроверяемому «черному ящику».
Для обычного пользователя подобные инциденты также означают несколько более практичных принципов безопасности.
- Во-первых, кошелек всегда следует скачивать с официального сайта или из официальных магазинов приложений и своевременно обновлять до безопасных версий.
- Во-вторых, не стоит хранить все активы в одном кошельке для ежедневного взаимодействия. Крупные долгосрочные активы можно хранить на аппаратном кошельке или в отдельном холодном кошельке, изолированном от горячего кошелька, который часто подключается к DApps.
- Что еще важнее, если официальные представители кошелька подтверждают уязвимость на уровне генерации ключей или реализации подписи, просто импортировать ту же сид-фразу в другой кошелек обычно не решает проблему;
Потому что после импорта того же набора сид-фраз в другой кошелек, уже скомпрометированные адреса и приватные ключи не изменятся. Затронутые активы необходимо перевести на новый адрес, который никогда не использовался для подписи в уязвимой версии. Для обычного пользователя более безопасным подходом обычно является следование официальной процедуре действий в чрезвычайной ситуации: создание совершенно нового кошелька и новой сид-фразы, а затем перенос активов, а не самостоятельные повторные импорты или манипуляции со старыми адресами.
II. L2 — это не просто «более дешевый Ethereum», а целая сложная цепочка доверия
Помимо кошельков, несколько инцидентов в июне указали на риски, связанные со все более сложными системами L2.
14 и 18 июня две старые реализации Rollup, связанные с Aztec, подверглись атакам, общие потери составили около 4,35 млн долларов.
Важно уточнить, что атакованы были устаревшие реализации, такие как Aztec Connect, которые уже перешли в статус legacy, и это не равнозначно атаке на текущую основную сеть Aztec Network. Однако проблемы, выявленные в этих двух инцидентах, весьма показательны для всей сферы ZK Rollup.
В одном из инцидентов злоумышленник воспользовался несоответствием между количеством транзакций и фактически обрабатываемыми данными, заставив систему зачислить депозит во внутреннем доказательстве, но обойдя соответствующий процесс списания баланса в L1.
Другой инцидент произошел из-за отсутствия ограничений в схеме доказательства с нулевым разглашением (ZK circuit). Система верифицировала доказательство, формально корректное, но не обеспечила полного соответствия приватного дерева состояний, использованного в доказательстве, с публичным корнем состояния, фактически используемым для расчетов в Ethereum. Это позволило злоумышленнику сгенерировать доказательство вокруг сфальсифицированного дерева состояний и вывести активы из контракта L1.
Подобные проблемы сложно описать в терминах традиционного «есть ли уязвимость в конкретной строке кода контракта». В конце концов, доказательства с нулевым разглашением могут подтвердить, что некий вычислительный процесс соответствует заданным правилам, но при условии, что сами правила корректны и полны. Если разработчик забыл ограничить критическую переменную, доказательство может оставаться математически верным, но будет доказывать результат, не соответствующий реальному состоянию расчетов.
Инцидент безопасности с Taiko выявил другой риск в цепочке доверия L2.
22 июня процесс верификации доказательств Taiko, основанный на SGX, был использован злоумышленниками, что привело к потерям около 1,7 млн долларов. Согласно анализу BlockSec, злоумышленник использовал приватный ключ подписи SGX enclave, который ранее был загружен в публичный репозиторий на GitHub, и воспользовался уязвимостью в контракте верификации в блокчейне, который не отвергал Enclave в режиме DEBUG.
Злоумышленник зарегистрировал вредоносного провайдера доказательств как легитимный экземпляр. Затем он сфабриковал доказательство состояния L2, заставив контракт в Ethereum принять несуществующее состояние L2, и в итоге вывел активы из мостовых средств. В конечном счете, причина в том, что ключ, использованный для подписи доверенной среды исполнения (TEE), оказался публичным, а правила удаленной аутентификации не проверяли полностью свойства среды исполнения, что лишило «аутентифицированное» доказательство его изначального доверенного смысла.
В то же время, 25-26 июня в сети Base произошла серия остановок производства блоков в основной сети. В послемортемном анализе Base заявили, что оба сбоя были вызваны одним и тем же логическим дефектом в построении блоков: транзакция, завершившаяся неудачей, не очистила корректно ранее записанное состояние, что привело к некорректному расчету Gas для последующих транзакций и генерации блока, содержащего недопустимое изменение состояния. Поскольку другие узлы не могли принять этот блок, сеть в итоге прекратила продвижение. Base заявили, что целостность цепи не была нарушена во время инцидента, средства пользователей оставались в безопасности.
Это не была кража активов или внешняя атака, а технический сбой, повлиявший на доступность сети и способность к восстановлению. Но в более широком смысле безопасности, доступность сама по себе является частью модели безопасности L2.
Потому что для пользователя безопасность цепи зависит не только от того, может ли хакер сфабриковать активы, но и от того, могут ли блоки производиться непрерывно, работают ли кросс-чейн мосты, могут ли узлы быстро восстанавливаться, и есть ли у пользователя可行ный путь выхода, если в системе происходит сбой.
Поэтому, используя L2, пользователям не стоит сравнивать только комиссии и ожидания эирдропов. Для L2 с небольшим масштабом, только что запущенных или с быстро меняющимися механизмами безопасности, стоит избегать долгосрочного хранения крупных сумм, превышающих фактические потребности в использовании. Перед кросс-чейном следует убедиться, что используется официальный мост, и понять время вывода, механизмы приостановки и способы экстренного выхода. При остановке производства блоков, аномалиях в кросс-чейне или публикации официальных предупреждений о безопасности не следует повторно отправлять транзакции или продолжать перевод активов через мост.
Более безопасным подходом является диверсификация управления активами для разных целей и уровней риска, а не концентрация всей ликвидности на одном L2, одном кросс-чейн мосте или одном механизме выхода.
III. Контракт не взломан, но сторонние сервисы могут доставить атаку пользователям
Если проблемы с кошельками и L2 все еще происходят на уровне относительно низкоуровневых технических компонентов, то инцидент с Polymarket показывает, что фронтенд веб-страницы, ближайший к пользователю, также может стать точкой входа для средств.
25 июня Polymarket сообщили, что один из используемых ими сторонних поставщиков был скомпрометирован, и злоумышленники воспользовались этим для внедрения вредоносного скрипта во фронтенд Polymarket, который видели некоторые пользователи.
По данным организаций безопасности и ончейн-аналитиков, инцидент привел к потере активов пользователей на сумму около 3 млн долларов, было затронуто около 11 кошельков. Похищенные средства были переведены через кросс-чейн с Polygon на Ethereum и обменены на примерно 1893 ETH. Впоследствии Polymarket заявили, что удалили затронутую зависимость и полностью возместят ущерб пострадавшим пользователям.
Ключевой момент этого инцидента в том, что пользователи, возможно, заходили на правильный домен Polymarket, и имеющиеся данные не указывают на уязвимость в основном смарт-контракте Polymarket. Проблема в основном заключалась в сторонних фронтенд-зависимостях, загружаемых веб-страницей.
Это также зеркало реальности: сегодня большинство Web3-приложений не работают полностью в блокчейне. Веб-страницы, которые видят пользователи, такие как интерфейсы для торговли, по-прежнему сильно зависят от традиционной интернет-инфраструктуры и сторонних пакетов программного обеспечения. Компрометация любой из этих зависимостей может привести к тому, что легальный сайт будет показывать пользователям некорректную информацию, подменять адреса для получения средств или побуждать кошелек подписывать вредоносные транзакции.
Следовательно, «URL верный» не обязательно означает, что «весь код, загружаемый в данный момент, безопасен». «Контракт прошел аудит» также не означает, что на всем пути взаимодействия пользователя с контрактом нет рисков. Перед подобными фронтенд-атаками и атаками на цепочки поставок обычному пользователю сложно самостоятельно проверять каждый фрагмент кода, загружаемый страницей, но все же можно снизить потенциальные потери, ограничивая разрешения для единичных взаимодействий:
- Использовать отдельный кошелек для взаимодействия с DApps: Кошелек для долгосрочных сбережений по возможности не подключать напрямую к различным DeFi, NFT, прогнозным рынкам и сайтам с эирдропами. Кошелек для ежедневного взаимодействия должен содержать только средства, предназначенные для недавнего использования. Даже если возникнут проблемы с фронтендом или разрешениями, масштаб воздействия будет относительно ограничен.
- Перед подписанием обращать внимание на фактические действия, а не только на кнопки на странице: То, что на веб-странице написано «Войти», «Забрать» или «Подтвердить заказ», не означает, что во всплывающем окне кошелька запрашивается подпись для того же самого действия.
- При появлении аномалий на веб-странице не действовать по инерции: Если страница внезапно требует повторного импорта сид-фразы, загрузки дополнительного плагина или отображает содержимое транзакции, не соответствующее описанию на странице, следует приостановить взаимодействие, подтвердить ситуацию через несколько официальных каналов проекта, а также проверить или отозвать исторические разрешения, которые больше не используются.
С точки зрения продуктов-кошельков, это также означает, что роль кошелька меняется.
Он не должен быть просто инструментом для хранения приватного ключа и отображения окна подписи. Ему также необходимо, насколько это возможно, помогать пользователю понимать намерение транзакции, распознавать подозрительные разрешения, отображать изменения активов и предоставлять достаточно четкие предупреждения до совершения рискованных взаимодействий.
Но кошелек также не может устранить все риски за пользователя. Более реалистичная модель безопасности — это когда кошельки, протоколы, L2, сторонние поставщики услуг и пользователи совместно сокращают поверхность атаки, а не перекладывают всю ответственность на какую-либо одну сторону.
В заключение
Раньше часто говорили: кто владеет приватным ключом, тот владеет активами в блокчейне.
Это утверждение по-прежнему верно, но оно не охватывает весь процесс от «возникновения намерения совершить транзакцию» до «завершения расчетов в блокчейне». Безопасность Web3 сегодня — это не просто защита набора сид-фраз. Это защита всего пути: от генерации ключей в кошельке, отображения транзакции и выполнения подписи до верификации сетью и окончательного расчета.
Конечно, это не означает, что пользователям нужно избегать всех взаимодействий в блокчейне. Для пользователя по-настоящему эффективные привычки безопасности означают необходимость раздельного управления активами по их назначению, уровню риска и сценарию взаимодействия: долгосрочные активы — с акцентом на изоляцию, ежедневные взаимодействия — с небольшими суммами, незнакомые DApps — с низкими разрешениями, рискованные операции — с дополнительной проверкой.
В конце концов, когда угрозы безопасности расширяются от точки до цепочки, защита пользователя также должна эволюционировать от простой защиты приватного ключа до целостного набора привычек.
Всех с этим.
