Исследование атаки валидаторов Proof-of-Stake

(Оригинал статьи от 04.08.2022) Обновление Merge стремительно приближается. Через несколько месяцев блокчейн Ethereum перейдет от Proof-of-Work (PoW) к Proof-of-Stake (PoS). Блокчейн Proof-of-Stake обычно называется ETH2. Это захватывающее событие, но мы должны обратить внимание на важную проблему конфиденциальности в блокчейне после обновления Merge. Команда HOPR в сотрудничестве с Decentralized Systems and Security Group из Имперского колледжа, возглавляет исследование сети Gnosis Beacon Chain (GBC). Мы выявили большие негативные стимулы для валидаторов проводить атаки друг на друга в попытке перехватить вознаграждение за блок.

Это возможно, поскольку схема PoS требует , чтобы публичные ключи валидатора в beacon chain или “сигнальном” блокчейне были известны всем заранее, поэтому все знают порядок валидаторов для слотов в течении эпохи. Эта информация в сочетании с информацией об IP-адресе валидатора позволяет провести очень серьезную атаку, в результате которой намеренно вывести из строя узел валидатора — например, с помощью атаки “отказ в обслуживании” (DoS) — и следующий валидатор сможет перехватить его вознаграждение.

О такой возможности было известно уже давно — фактически она упоминается в нескольких аудиторских отчетах по безопасности Ethereum от 2020 года (вот один из них от Least Authority и другой от Quantstamp). Но, как правило, эту проблему отмечают как “умеренную”

Однако исследования, проведенные в HOPR за последние несколько месяцев, а также параллельные исследования наших коллег Decentralized Systems and Security Group из Имперского колледжа Лондона, привели нас к выводу, что риск гораздо выше по трем причинам:

1. Стимулы для проведения этой атаки гораздо выше, чем считалось ранее
2. Выявить IP-адреса валидаторов проще, чем считалось ранее
3. Саму атаку легче провести и труднее предотвратить, чем считалось ранее

Давайте опишем этапы атаки, а затем рассмотрим эти три пункта более подробно.

Атака валидаторов — основы

Основная схема атаки проста: следите за “сигнальным” блокчейном достаточно долго, чтобы установить взаимосвязь между публичным ключом валидатора и его IP-адресом, а затем, когда этот валидатор станет предлагать блок, то выведите его узел из строя с помощью DoS-атаки. Он не сможет выполнить свои обязанности по предложению блока, и его слот истечет. Роль перейдет к следующему валидатору, который сможет использовать все возможности MEV и комиссии за транзакции, к которым имел доступ валидатор, подвергшийся атаке.

Но как получить публичный ключ и информацию об IP-адресе, необходимую для проведения атаки? Чтобы понять это, нам нужно глубже изучить, как будет работать Proof-of-Stake в ETH2 и аналогичных системах.

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

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

После выявления этой взаимосвязи остается только ждать подходящей возможности для атаки. Затем вы можете запустить атаку типа “отказ в обслуживании” (DoS) на выбранного валидатора. Это не похоже на привычные нам распределенные атаки типа “распределенный отказ в обслуживании” (DDoS), которые выводят из строя крупные сервисы на несколько часов. Атака не должна быть такой интенсивной или продолжительной: достаточно вывести узел валидатора из строя на такое время, чтобы он не мог выполнить свои обязанности в слоте. Но что из этого можно получить, и как часто возникают такие возможности для атаки?

Именно здесь предыдущие исследования, по-видимому, неверно оценивали масштаб.

Несоответствие стимулов

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

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

Чтобы атака была эффективной, нужно собрать три фактора одновременно:

• Знать IP-адрес предстоящего валидатора, предлагающего блок
• Иметь контроль над следующим слотом (либо потому, что вы являетесь валидатором в этом слоте, либо потому, что вы можете взаимодействовать с ним)
• Достаточные возможности MEV в мемпуле, чтобы их можно было использовать

По нашей оценке, это не какое-то случайное стечение обстоятельств. На самом деле, мы ожидаем, что это будет происходить очень часто, потому что:

• Поиск IP-адресов валидаторов с высокой степенью достоверности оказывается довольно простым
• Частота сотрудничества между искателями MEV и майнерами показывает, что возможности огромны, и эти взаимодействия возникают без особых трудностей в пространстве DeFi. Несмотря на то, что атаки MEV с помощью DoS вызывают больше осуждения, чем обычные MEV (которые тоже этически сомнительны) мы все равно ожидаем, что подобные совместные проекты и сервисы будут быстро появляться
• В настоящее время в Ethereum возможности для MEV возникают очень часто, и нет причин думать, что переход на ETH2 существенно изменит ситуацию

Связь между IP-адресами и публичными ключами

Давно известно, что можно наблюдать за сетью и формировать связи между публичными ключами валидаторов и их IP-адресами. Но, насколько нам известно, HOPR — первый проект, который действительно попробовал это сделать. В следующих разделах мы подробно объясним, что мы сделали и насколько это было просто.

Наша конфигурация

С 21 апреля 2022 года 11 членов команды HOPR по всему миру запускали узлы валидатора на Gnosis Beacon Chain, используя аппаратные узлы от наших замечательных партнеров из AVADO. Они добровольно поделились своими IP-адресами и публичными ключами с нашей аналитической группой, чтобы результаты могли быть подтверждены. Обратите внимание, что IP-адреса использовались не в процессе анализа, а только для проверки результатов.

Отдельно мы запустили еще один узел, который был слегка модифицирован для сбора IP-адресов всех подключенных пиров, когда они передают аттестации, и сбора их в базу данных IP-адресов и публичных ключей с помощью Elastic Stack. Модификация узла была довольно простой, поскольку клиент Lighthouse поддерживает мониторинг валидаторов в стандартной комплектации. (Эта функция будет важна и позже, когда мы будем обсуждать способы улучшения сбора данных).

В результате было получено очень МНОГО данных. Например, с 1 июня по 1 июля мы собрали 2 285 214 572 пары IP-адрес/публичный ключ, которые могут быть связаны с 1 253 уникальными IP-адресами.

Взаимосвязь между публичными ключами и IP-адресами

Как же мы из этого огромного количества данных вывели точную взаимосвязь между IP-адресами и публичными ключами? Помните, что если наш узел получил информацию об аттестации, связанной с публичным ключом, с определенного IP-адреса, это НЕ означает, что это IP-адрес узла-валидатора с данным публичным ключом. Это происходит потому, что некоторые узлы объединяют аттестации для более быстрого распространения по сети. На самом деле, наш узел даже не регистрировал, что это были объединенные аттестации, а регистрировал их так же, как и отдельные аттестации.

Итак, задача состоит в том, чтобы пробиться через весь этот шум.

Сначала мы выбираем несколько публичных ключей, чтобы попытаться установить взаимосвязь. Для этого эксперимента мы использовали публичные ключи, которые мы уже знали от наших тестеров. Очень важно понимать, что этот шаг правомерен, поскольку мы ни разу не использовали наше знание IP-адресов для установления взаимосвязи. Единственной причиной выбора именно этих публичных ключей, было то, что мы знали, что сможем подтвердить эти результаты (или опровергнуть). Мы также могли бы просто выбрать случайные публичные ключи и перебирать их один за другим, в конечном итоге попав на те, которые контролировались командой HOPR.

Даже если сузить круг до этих 11 публичных ключей, то мы все равно имеем очень много данных. С 21 апреля по 1 июля наш узел собрал 431 639 пар IP-адресов, связанных с 11 публичными ключами HOPR. За это время с 11 публичными ключами HOPR было связано 1613 уникальных IP-адресов. Но какие из них были верными?

Первое, что необходимо сделать, это разделить данные на определенные отрезки времени. Выбор временных рамок произволен, но мы выбрали один день, потому что нам показалось, что это даст управляемый объем данных. Например, если вы посмотрите только последние 15 минут аттестаций, мы можем не быть подключены к данному узлу HOPR. Следовательно, у вас не будет информации для сопоставления публичного ключа с правильным IP-адресом.

На рисунке ниже показано количество подтверждений по IP-адресам и публичным ключам узлов HOPR команды GBC в течение июня, с разделением подтверждений по дням.

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

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

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

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

По сути, взвешивание уменьшает вес дней, в которые данный узел HOPR не подключен, и переносит этот вес на дни, когда данный узел HOPR подключен.

Этот подход увеличил вероятность определения правильного IP-адреса с 62% до 89%. Он также сократил набор возможных IP-адресов, связанных с каждым узлом, до 1–3.

Таким образом, установление точной взаимосвязи между публичным ключом и IP-адресом требует сбора данных в течение довольно длительного периода времени. Но как долго? На рисунке показано, что для установления связи между всеми 11 узлами нам потребовалось около трех недель сбора необработанных аттестаций. Но это произошло потому, что у нас уже был набор публичных ключей, которые нас интересовали для доказательства нашей теории. Если бы мы просто хотели найти ЛЮБОЙ публичный ключ для атаки, и нас бы устроил более низкий процент вероятности определения правильного IP-адреса, то нам потребовалось бы гораздо меньше времени.

Существуют и другие методы, которые могут значительно сократить это время, например:

• Запуск нескольких узлов валидатора
• Отключение от узлов, чьи взаимосвязи уже установлены, чтобы сосредоточиться на остальных узлах

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

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

Возможность атаки

Конечно, после того как у вас есть взаимосвязь между IP-адресом и публичным ключом, вам еще нужно провести атаку. Насколько это осуществимо? Именно это сейчас пытаются выяснить наши партнеры по исследованиям из группы Arthur Gervaise’s в Имперском колледже Лондона. Мы ожидаем, что результаты их исследования будут опубликованы в ближайшие несколько месяцев, но уже сейчас мы можем сделать некоторые оценки.

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

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

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

Следующие шаги

Что же можно предпринять?

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

Мы не хотим публиковать информацию о членах нашей команды, но давайте просто предположим, что эта карта точно определяет IP-адреса узлов, но не их физическое местоположение…

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

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

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

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

Ответственное раскрытие информации

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

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

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

Sebastian Bürgel,
Основатель HOPR

Website: https://www.hoprnet.org
Twitter: https://twitter.com/hoprnet
Telegram: https://t.me/hoprnet
Discord: https://discord.gg/dEAWC4G
LinkedIn: https://www.linkedin.com/company/hoprnet

Forum: https://forum.hoprnet.org
Staking: https://stake.hoprnet.org
Bounties: https://bounties.hoprnet.org