🥷 Безопасность web3: уязвимости на стыке блокчейна и веб-технологий — Арсений Реутов
Интернет похож на Дикий Запад — пользователей отовсюду поджидают опасности: фишинг, роботы, сайты-ловушки, фейковые приложения. Блокчейн и сила децентрализации призваны освободить пользователей от страха потерять личную информацию из-за взломов. Считается, что новое поколение Интернета — web3 — создаст условия повышенной приватности и безопасности. Но правда в том, что web3 все еще работает на инфраструктуре web2. Поэтому, например, популярное браузерное расширение Metamask или Etherscan, один из важнейших ресурсов для экосистемы Ethereum, — не так безопасны и децентрализованы, как все думают.
Во время митапа Cyber Academy с Арсением Реутовым мы разбирались, что не так с web3-кошельками и другими децентрализованными приложениями, почему браузерные расширения ставят под угрозу весь сайт и как защитить web3-приложения от атак.
Предлагаем вам прочитать краткий пересказ доклада Арсения + бонусом ловите список упоминаемых ссылок ✨
Краткое досье: Арсений Реутов, аудитор, специалист компании Positive Technologies, занимается безопасностью приложений уже более 10 лет, в частности — web3. Исследует безопасность блокчейнов и смарт-контрактов.
Оглавление:
∘ Что такое web3 и web3-приложения
∘ Проблемы web3
∘ Атаки на фронтенд
∘ Появление Ethereum Name Service или ENS-доменов
∘ Что позволяет сделать XSS
∘ Как защитить и децентрализовать фронтенд
∘ Что делать в случае DNS Hijaking
∘ Как улучшить UX кошельков
∘ Утечка IP из Metamask
∘ Слепое подписывание
∘ Проблемы с UX Metamask
∘ Metamask Snaps
∘ Действия по улучшению UX
∘ Q&A
∘ Полезные ссылки c митапа
Что такое web3 и web3-приложения
Тема web3-безопасности находится на стыке технологий блокчейна и web 2.0. Но сначала разберемся, что такое web3.
Есть мнение, что web3 — что-то новое, разработка тут значительно отличается, а приложения выглядят иначе. Давайте разбираться, в чем заключается главное отличие web3 от web 2.0.
В web 2.0 есть клиент, который соединяется с централизованным сервером, выполняя некоторую логистику. Это может быть self-hosted сервер, облачный сервер или другие варианты централизованных серверов. Как правило, есть база данных, из которой собираются данные. Эти данные проходят процесс преобразования и передаются клиенту.
В web3 все меняется: появляется кошелек. Теперь пользователи, отправляя транзакции, подписывают свои запросы. Эти транзакции проходят через, пока еще централизованные, API, например, Infura или Alchemy. После этого транзакции оказываются в децентрализованном блокчейне Ethereum и исполняются там смарт-контрактами. Но ключевая фишка web3 — наличие кошелька.
С web 1.0 у человечества появился пароль — буквенно-числовое выражение, которое позволяет нам идентифицировать себя для приложений. В web 2.0 появились технологии, которые позволяют логиниться с помощью соцсетей и сторонних сервисов, по сути, получать доступ к сайтам без использования пароля. Web 3.0 позволяет не просто отказаться от пароля, но вообще забрать данные из владения централизованных систем. Нам больше не нужен пароль, теперь мы обладаем приватным ключом для подписи транзакций и для доказательства владения криптовалютами, NFT и так далее.
Проблемы web3
Пользователь, владея приватным ключом, ответственен за все свои действия. Но при этом, любая ошибка может стать фатальной. Никто не возместит потерю средств, если пользователь вызовет не тот смарт-контракт или отправит деньги на неправильный Ethereum-адрес.
Кошельки-расширения для браузеров, например Metamask, — не безопасны. Контекст исполнения расширений в браузерах шэрится вместе с контекстом исполнения самих веб-сайтов. То есть можно получить доступ к расширению. На первый план тут выходят клиентские уязвимости. В первую очередь, это — кросс-сайт скриптинг или XSS, то есть, возможность как-то инжектировать свой java-скрипт-код в контекст исполнения целевой веб-страницы.
UX кошельков в виде браузерных разрешений оставляет желать лучшего. В кошельках очень легко запутаться и совершить ошибку, которую, к тому же, никто не поможет исправить.
Атаки на фронтенд
Начнем с истории. В 2017 году прошла война хайпа и люди стали узнавать про смарт-контракты. EtherDelta стало одним из первых dApp — DEX в основной сети Ethereum на ордербуках. За каждую заявку нужно было отправлять транзакцию. Сейчас об этом даже сложно думать — слишком высокая цена за газ, но тогда транзакции стоили гораздо дешевле.
На бирже список доступных токенов выглядел как список адресов и была возможность импортировать любой токен и его переименовать. Это происходило ончейн — для переименования нужно было отправлять транзакцию в майннет. Один из злоумышленников вычислил, что можно вставлять произвольный java скрипт-код в имя токена. Этот код будет исполняться в контексте страницы. Еще одна особенность EtherDelta — возможность залогиниться как с помощью Metamask, так и с помощью приватного ключа. Если приватный ключ передается на сервер — он должен где-то храниться. EtherDelta хранила ключ прямо в DOM. Этим воспользовался хакер, строивший код, который похищал приватные ключи. И достаточно много людей пострадало от этой атаки.
Появление Ethereum Name Service или ENS-доменов
Это домены, которые записываются ончейн. Они не регистрируются как DNS, но внутри Ethereum позволяют по имени резолвить адрес. Имя регистрируется в виде NFT и связывалось с сетью Ethereum.
Это натолкнуло меня на мысль, что если эта строка вставляется также в DOM, то, если нет никаких проверок кода со стороны dAppa, это может привести к исполнению произвольного java-скрипт-кода в контексте страницы. Но как будет происходить валидация в таком случае. Вряд ли это будет будет делать смарт-контракт. Ведь в Solidity все очень сложно со строками. Чтобы что-то провалидировать в строках, нужно заплатить очень много за газ. И, вообще, поддержка строк там довольно скудная. В документации ENS значится, что сами dApps должны валидировать имена, согласно стандарту ETS-46, после того, как они разрезолвятся. Что-то подсказывало, что не все dApps будут это делать. После изучения смарт-контрактов, оказалось, что они проверяют только длину имени. Можно было записать любой ENS-домен, несмотря на то, что сайт ensdomains этого не позволяет и выбрасывает ошибку, что имеются спецсимволы в имени. Но все проходило без вопросов, если отправить напрямую транзакцию в смарт-контракт.
Я провел атаки таким способом нескольких страниц. Некоторые из них никак не валидировали смену имени. На Etherscan было сразу несколько страниц, на которые можно было заинжектить любой код. В том числе, на странице списка транзакций. Все это пофиксили. По сути, это центральная точка доверия экосистемы Ethereum, куда люди приходят посмотреть исходные коды транзакций. Если кто-то взломает Etherscan, это может иметь критические последствия для всех. Про уязвимость Zerion. При выводе DNS-домена, который также является NFT, тоже инжектился код. Метаданные многих NFT-площадок также хранятся на централизованном сервере. Можно их хранить в IPFS, но данные могут пропасть через некоторое время. Есть уязвимости, которые позволяют читать локальную файловую систему до исполнения кода. Исследователи из компании Checkpoint обнаружили XSS-уязвимость OpenSea — отсутствие валидации SVG. Исследователям удалось реализовать атаку.
Что позволяет сделать XSS
Можно напрямую обращаться к Metamask, при этом Metamask будет не настоящим — лишь имитация окна Metamask, куда пользователи могут вставить важную информацию — приватный ключ и т.д. Также можно делать подмену любых данных. Например, адреса — пользователь может отправить средства, не догадываясь, что отправляет их на ложный адрес. В декабре 2021 года взломали BadgerDAO на $120 млн после инжекта кода во фронтэнд. Код делал аппрув на распространенные ERC-20 токены. Этот аппрув дает право злоумышленникам распоряжаться токенами.
Есть миллионы способов взлома. Смотря где: на обычном хостинге или в облаке. В Amazon, например, сложнее отследить ключи и адреса, сложнее взломать.
Как защитить и децентрализовать фронтенд
Есть базовые требования к безопасности любых приложений на блокчейне. У React, кстати, все довольно приемлемо с безопасностью. И если пользователь вставляет странную строку, то не получится просто так ее вставить. Программа определит ее как dangerouslySetlnnerHtml. Часто пользователи вставляют код, как есть, что вызывает ошибки. Такие ошибки можно находить при помощи программы-сканера CodeQL. В браузерах есть средства, которые могут усложнить жизнь получившим доступ к модификации фронта. Все действия модерируются при помощи заголовков ответа — для всех JS скриптов, которые вы включаете в приложения, указать хеш контента. Если JS код поменялся — SRI не позволит ему исполниться на вашем сайте.
Есть довольно старая технология — Content Security Policy, она позволяет объявить с каких сайтов вы позволяете загружать ресурсы — картинки, видео, аудио и скрипты. Браузер не будет грузить посторонние скрипты. Тут важно избегать команд unsafe-inline и unsafe-eval, который позволяет браузеру выполнять скрипты прямо в коде вашего приложения. Более новая техника — Trusted Types — появилась в Chrome как инициатива Google, не поддерживается некоторыми браузерами. Но эта техника довольно эффективна против DOM XSS. Работает против незащищенных синков, например innerHTML.
Что делать в случае DNS Hijaking
Но что делать, если произошел хак и у злоумышленника появился доступ к вашей админ-панели облачного провайдера, например Amazon, и он может рулить DNS-записями? Такая ситуация произошла с PancakeSwap Их доменные имена начали резолвиться по сторонним адресам. В их случае появлялся фейковый Metamask, который просил сид-фразу.
Тут, как раз, обычно используют технологии децентрализации: PFS+ENS. IPFS — технология децентрализованного хранения файлов, документы резолвятся по хешу их содержимого. Обычно IPFS используют в связке с DNS. Если у нас есть возможность разрезолвить DNS-домен и получить оттуда хеш, то мы можем надежно получить именно тот контент, который был на сайте. Но здесь есть уязвимость — DNS — чтобы получить доступ к ENS, надо как-то разрезолвить его. Пока что ничего лучше, чем сделать это с помощью DNS не придумали. Существуют сервисы, которые позволяют по ENS-имени отдавать документы из IPFS (eth.link и eth.limo). Тут также присутствует уязвимость к DNS Hijacking.
Есть еще одна альтернатива — Skynet Homescreen. Это децентрализованный хостинг на базе блокчейна Sia. Sia — децентрализованное хранилище с платным размещением файлов (похоже на Filecoin). Homescreen — приложение для хранения фронтендов, пользователь тут сам может решать, какую копию использовать. 1inch поддержал интеграцию со Skynet Homescreen. Идея Homescreen — в том, что пользователи сохраняют приложение себе на устройство, а не хранят его где-то на централизованном сервере на стороне. Но здесь есть момент резолва DNS. В любом случае мы должны полагаться на централизованную систему на самом первом этапе. При этом для хранения копий не обязательно использовать децентрализованное хранилище, можно пользоваться им локально. Также идею «user owns apps» можно реализовать в виде дескоптного приложения.
Как улучшить UX кошельков
Ни для кого не секрет, что самый распространенный кошелек — Metamask, который все еще работает как расширение для браузера. Из исследования уязвимости расширения для браузера видно, что некоторые уязвимости несут большие последствия в плане безопасности для сайтов, которые сами по себе безопасны, но из-за расширений становятся уязвимыми. Все может заканчиваться выполнением кода на хосте с использованием месседжей. Есть функция пост-месседж, которая позволяет общение между окнами. Если какое-то окно, в котором вставлено расширение браузера, имеет хендлер такого пост-месседжа, и оно не проверяет источник сообщения, то тут может быть нарушена логика и исполнен код. Это может быть клиентский код или код в системе.
У Metamask довольно жирный пакет — 2195 зависимостей (Metamask весит 849 мб) если хоть в одной зависимости будет заинжектен сторонний код, то такой код попадет в сам Metamask.
Утечка IP из Metamask
Также есть кейс с утечкой IP из Metamask. Недавно основатель Signal Мокси Марлинспайк, который решил углубиться в web3 и проверить, как работают dApps. Он указал на то, что несмотря на то, что web3 считает децентрализованным — Metamask полагает на централизованные сервисы, такие как Infura и Opensea. С Opensea Metamask подтягивает все NFT и может отображать их в кошельке. И все коммуникации в этих процессах происходят через централизованные сервера. Все ответы от них никак не проверяются. Это ставит под сомнение концепт web3 и децентрализацию.
Metamask автоматически делает обращение в Opensea. Поэтому хакеры придумали делать такой трюк: они посылают жертве фейковый NFT и в этой коллекции злоумышленник указывает свой сервер для всех метаданных. IP утечет злоумышленнику и он сможет узнать всю информацию о вас из интернета и устроить таргетированную атаку. Разработчики Metamask признали проблему и работают над ее исправлением.
Слепое подписывание
Думаю, многие, когда делают транзакции в Metamask с замиранием в сердце проверяют адрес. Это потому что, мы понятия не имеем, как транзакция исполнится по факту. Один из кейсов — таргетированная атака на CEO Nexus Mutual в декабре 2020 года, в результате которой он потерял $8 млн.
На его компьютере была установлена модифицированная версия Metamask, чтобы похитить его криптовалюту, несмотря на хардверный кошелек — слив произошел при помощи фейкового адреса. Подсадка фейковой версии Metamask могла произойти несколькими способами — например, через заражение. Пользователя могли заманить на специальный сайт, где есть эксплойты для пробивания браузера, связка эксплойтов подстраивается под определенную версию браузера и использует уязвимости этой версии.
Можно защититься от таких атак при помощи постоянного обновления до актуальной версии браузера. Но никто не отменяет zero day атаки, которые нацелены на уязвимости, о которых никто не знает. Есть целый рынок zero day уязвимостей, которые используются правительствами и хакерами по всему миру.
Проблемы с UX Metamask
Было бы неплохо иметь аналитику по адресу получателя — нет даже базовой проверки по известным адресам.
Перед отправкой транзакции нельзя предсказать, как она исполнится. Хорошо бы заранее знать, что изменится в сторадже контракта.
Нет предупреждения, что аппрув делается для адреса, а не для смарт-контракта.
Нет предупреждения, что есть бесконечный аппрув для прокси, который может измениться.
Metamask Snaps
Metamask начал поддерживать систему плагинов в рамках Metamask Flask. Это
официальная модификация Metamask для разработчиков — своеобразная песочница, где они могут тестировать новые фичи. Плагины добавляют возможность аудита адреса перед отправкой и другие функции. Не очень понятно, когда это все появится в основном Metamask. Плагины внутри плагинов — больше точек атаки. Известный криптограф Мэтью Грин посмотрел, какие библиотеки используются в Metamask, такое ощущение, что никто даже в Metamask не знает, какие именно библиотеки используются.
Действия по улучшению UX
Можно посмотреть на возраст контракта — если его создали совсем недавно, то вероятно, он не очень благонадежен. Можно показывать аналитику по активности транзакций в контракте. Можно также обеспечить симуляцию транзакций — чтобы посмотреть, какой будет результат. Например в интеграции с Tenderly или экспериментальный API от Blocknative. Можно использовать Token Lists для распознавания известных адресов. Также можно отображать скоринг DefiSafety.
Q&A
Lana Ivina: а есть ли еще тулзы, помимо EtherScan, где можно увидеть и отменить свои бесконечные аппрувы?
Арсений Реутов: да, таких сервисов много. Например: rugdoc.io — достаточно полезный ресурс, где делают мини-аудиты смарт-контрактов.
Михаил из Telegram-чата @Miklat: есть ли сервис, которым можно изучить смарт-контракты на предмет распространенных ошибок или бэкдоров?
Арсений Реутов: сейчас нет сайта, который позволяет проверить целостность смарт-контракта. У меня есть свой сервис, который позволяет проверить, насколько отличается смарт-контракт от того, что есть в GitHub.
Михаил из Telegram-чата @Miklat: насколько высока безопасность новых сетей, написанных на RUST?
Арсений Реутов: появляется много альтернативных L1-сетей, которые, в основном, используют RUST. Гевин Вуд, который стоял у истоков Ethereum, но он ушел и создал свою компанию Parity. Он создал свой блокчейн на RUST. Он мотивировал свой ход тем, что на Solidity нельзя сделать какие-то сложные вещи, advanced смарт-контракты. Но практика показывает, что сложные смарт-контракты легко взломать.
Михаил из Telegram-чата @Miklat: насколько отличается безопасность в сетях, использующих EVM?
Арсений Реутов: с точки зрения механизма исполнения смарт-контрактов в EVM — он общий для всех. Есть отличия в L2-сетях типа Optimism или Arbitrum. Тут приходится заменять некоторые параметры окружения смарт-контракта, например, нет поля с номером блока.
Как бороться с централизацией хостеров, на которых расположены валидаторы сетей PoS?
Арсений Реутов: риски очевидны, централизованный сервис, который хранит приватные ключи уже подвергает опасности пользователей. Обычно проекты используют холодные кошельки и другие средства. Pos-валидаторов централизованных хостингов пока вроде не взламывали.
Как влияют Cookies и т. д. на безопасность?
Арсений Реутов: web3 работает на той же инфраструктуре, что web2, поэтому риски — все те же самые. Бесконечные Cookies — техника, которая позволяет идентифицировать пользователей даже, если включен режим инкогнито в браузере. Никто не мешает трекать вас и в децентрализованных приложениях. Metamask в виде расширения браузера — только ухудшает ситуацию. Есть специальные расширения, которые смотрят контент веб-страниц и удаляют трекеры. Рекомендации все те же самые, что и для обычного Интернета для предотвращения трекинга, фишинга и других скамов.
Полезные ссылки, которые упоминались во время митапа:
#2 Репозиторий на Github от Петра Кочергинского, в котором собрано много CTF
#3 Утилита, которая позволяет регистрировать ENS-домена
#4 Проверка NFT-маркетплейсов
#5 Проверка кода React https://codeql.github.com
#6 Материал от Microsoft про кейс BadgerDAO
#7 Проверка аппрувов: rugdoc.io
#8 Проверка адресов: DefiSafety, Token Lists
#9 Исследование про OpenSea и кошельки
#10 Проблемы UX
