Выбрать язык

Кража доверия: анализ атак со слепыми сообщениями в аутентификации Web3

Анализ новой уязвимости 'атаки со слепыми сообщениями' в Web3-аутентификации, её обнаружение с помощью Web3AuthChecker и защита с помощью Web3AuthGuard для MetaMask.
tokens-market.com | PDF Size: 0.6 MB
Оценка: 4.5/5
Ваша оценка
Вы уже оценили этот документ
Обложка PDF-документа - Кража доверия: анализ атак со слепыми сообщениями в аутентификации Web3

1. Введение и обзор

Web3, построенный на децентрализованной блокчейн-технологии, пережил взрывной рост в таких областях, как DeFi, NFT и игры, с общим заблокированным капиталом в миллиарды долларов. Фундаментальным компонентом этой экосистемы является Web3-аутентификация — протокол запрос-ответ, в котором пользователи идентифицируются по своему открытому ключу (адресу кошелька). Приложения отправляют сообщение в криптокошелёк пользователя (например, MetaMask), пользователь подписывает его своим закрытым ключом, а приложение проверяет подпись для предоставления доступа.

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

Ключевая статистика вкратце

  • 75,8% протестированных развёртываний Web3-аутентификации были уязвимы.
  • 22 из 29 реальных приложений подвергались риску.
  • 80% успешных обнаружений атак с помощью Web3AuthGuard.
  • Назначены два идентификатора CVE для обнаруженных уязвимостей.

2. Атака со слепыми сообщениями

2.1 Модель атаки и уязвимость

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

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

2.2 Технический механизм

Атака представляет собой форму атаки «человек посередине» (MitM) на уровне приложения, но она облегчается недостатками проектирования в протоколе взаимодействия кошелька и приложения. API кошелька (например, eth_requestAccounts, personal_sign) не обеспечивает принудительного или чёткого отображения контекстных метаданных о запрашивающем домене для всех типов сообщений, создавая для пользователя «слепую зону».

3. Обнаружение и защита

3.1 Инструмент Web3AuthChecker

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

3.2 Web3AuthGuard для MetaMask

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

4. Оценка и результаты

4.1 Экспериментальная установка

В исследовании были оценены 29 популярных Web3-приложений из различных категорий, включая платформы DeFi (например, Uniswap, Aave), маркетплейсы NFT (например, OpenSea) и Web3-игры. Web3AuthChecker был развёрнут для автоматического тестирования их конечных точек аутентификации.

4.2 Ключевые выводы и статистика

Результаты были тревожными: 22 из 29 (75,8%) приложений были уязвимы для атак со слепыми сообщениями. Такая высокая распространённость указывает на то, что уязвимость является системной, а не редким случаем. Последующая оценка Web3AuthGuard показала, что он может успешно активировать предупреждения в 80% протестированных уязвимых процессов аутентификации, демонстрируя осуществимость защиты пользователей в реальном времени.

Описание диаграммы (представленной): Столбчатая диаграмма показала бы, что столбец «Уязвимые приложения (22)» значительно выше, чем «Безопасные приложения (7)». Вторая диаграмма показала бы, что столбец «Успешные предупреждения Web3AuthGuard» покрывает 80% столбца «Протестированные уязвимые процессы».

5. Технический глубокий анализ

5.1 Математические основы

Web3-аутентификация основана на цифровых подписях с использованием эллиптической криптографии, обычно кривой secp256k1, используемой в Ethereum. Основная проверка подписи $(r, s)$ для сообщения $m$ и открытого ключа $Q$ (полученного из адреса) выглядит следующим образом:

$ \text{Verify}(m, (r, s), Q) = \text{true} \quad \text{if} \quad s^{-1} \cdot (eG + rQ)_x \equiv r \ (\text{mod}\ n) $

где $e$ — хеш сообщения $m$, $G$ — образующая точка, а $n$ — порядок кривой. Атака не взламывает эту криптографию. Вместо этого она нарушает предположение протокола о том, что $m$ привязано к определённому источнику/контексту. Сбой безопасности заключается в $ \text{Context}(m) \neq \text{PerceivedContext}_{user} $.

5.2 Пример аналитической структуры

Пример: анализ входа в DeFi-панель управления.

  1. Шаг 1 — Разведка: Использовать Web3AuthChecker для вызова конечной точки API входа панели управления и захвата проверочного сообщения $C_d$.
  2. Шаг 2 — Моделирование пересылки: Встроить $C_d$ в запрос на подпись, сгенерированный поддельным вредоносным сайтом $M$.
  3. Шаг 3 — Отправка подписи: Отправить подпись $\sigma$, сгенерированную подписанием $C_d$ в контексте $M$, обратно на исходную конечную точку проверки панели управления.
  4. Шаг 4 — Подтверждение уязвимости: Если панель управления принимает $\sigma$ и устанавливает сессию, атака со слепыми сообщениями подтверждается. Недостаток заключается в том, что панель управления проверяет только $\text{Verify}(C_d, \sigma, Q)$, а не $\text{Origin}(\sigma) == \text{Dashboard}$.

6. Взгляд аналитика

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

Логическая последовательность: Логика исследования безупречна. Начать с гипотезы (сообщения аутентификации могут быть злонамеренно пересланы), создать инструмент (Web3AuthChecker) для масштабного тестирования, обнаружить ошеломляющую распространённость (75,8%), а затем разработать практическую контрмеру (Web3AuthGuard), чтобы доказать возможность защиты. Назначение CVE формализует угрозу, переводя её из академической концепции в уязвимость, которую необходимо исправить.

Сильные стороны и недостатки: Сила заключается в разрушительно простом, но ранее упущенном из виду векторе атаки и его огромном влиянии на реальный мир. Прототип защиты прагматичен. Недостаток, как и во многих исследованиях безопасности систем, заключается в том, что Web3AuthGuard — это временное решение. Он добавляет проверку там, где сам протокол должен обеспечивать безопасность. Долгосрочное исправление требует от поставщиков кошельков (таких как MetaMask) и органов по стандартизации (таких как EIP-712) обязательного криптографического привязывания контекста домена к подписываемому сообщению. Опыт десятилетий исследований фишинга доказывает, что полагаться на внимание пользователей к предупреждениям неэффективно.

Практические рекомендации: Для разработчиков: Немедленно проведите аудит вашего процесса аутентификации. Не просто проверяйте подпись; проверяйте, что источник подписи соответствует вашему домену через привязку сессии. Для создателей кошельков: Это чрезвычайная ситуация. Реализуйте подпись структурированных данных EIP-712 с обязательным разделением доменов и сделайте её по умолчанию для всех запросов аутентификации. Отображайте ненадёжные запросы personal_sign с открытым текстом с явным, предупреждающим интерфейсом. Для органов по стандартизации: Ускорьте принятие протоколов, которые делают атаки с пересылкой криптографически невозможными, а не просто визуально предупреждаемыми. Время вежливых предложений прошло; экосистема DeFi стоимостью $52 млрд требует надёжных примитивов безопасности.

7. Будущие применения и направления

Последствия выходят за рамки входа в систему. Любой запрос на подпись в Web3 — для транзакций, одобрений токенов, голосований в DAO — потенциально уязвим для подобных атак со слепой пересылкой. Будущие исследования и разработки должны быть сосредоточены на:

  1. Решения на уровне протокола: Широкое внедрение и применение EIP-712 и его преемников, которые позволяют типизировать и структурировать сообщения с проверяемыми параметрами домена, делая их непересылаемыми.
  2. Интеграция с аппаратными кошельками: Расширение проверки контекста на экраны аппаратных кошельков, которые в настоящее время также отображают ограниченные данные сообщений.
  3. Формальная верификация процессов аутентификации: Применение формальных методов, аналогичных используемым для смарт-контрактов (например, в фреймворке KEVM), для проверки свойств безопасности самого внецепного протокола аутентификации.
  4. Детекторы на основе машинного обучения: Развитие инструментов, подобных Web3AuthChecker, для создания систем непрерывного мониторинга для магазинов dApp или аудиторов безопасности, которые автоматически помечают уязвимые реализации аутентификации.
  5. Конвергенция с децентрализованной идентификацией (DID): Эта работа подчёркивает необходимость более надёжных стандартов аутентификации DID (таких как W3C Verifiable Credentials), которые с самого начала разрабатываются с учётом этих векторов атаки.

8. Ссылки

  1. Yan, K., Zhang, X., & Diao, W. (2024). Stealing Trust: Unraveling Blind Message Attacks in Web3 Authentication. Proceedings of the 2024 ACM SIGSAC Conference on Computer and Communications Security (CCS’24).
  2. Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System.
  3. MetaMask. https://metamask.io
  4. EIP-712: Ethereum Typed Structured Data Hashing and Signing. https://eips.ethereum.org/EIPS/eip-712
  5. Atzei, N., Bartoletti, M., & Cimoli, T. (2017). A survey of attacks on Ethereum smart contracts (SoK). Principles of Security and Trust.
  6. Zhuang, Y., et al. (2020). Tools and benchmarks for automated log parsing. IEEE International Conference on Software Engineering (ICSE). (Пример строгой методологии оценки инструментов).
  7. DeFi Llama. Total Value Locked Statistics. https://defillama.com