Эта статья является публичным раскрытием серии уязвимостей, связанных с исчерпанием ресурсов, которые исследовала группа студентов, состоящая из Санкета Канджалкара ( sanket1729 , smk7@illinois.edu ), Юньци Ли, Югуан Чен, Джозеф Куо и нашего советника Эндрю Миллера ( socrates1024 ) в Лаборатории децентрализованных систем @ UIUC. Эти уязвимости затронули в общей сложности более 26 криптовалют Proof-of-Stake и позволили сетевому злоумышленнику с очень небольшим количеством ставок прервать работу любого из узлов сети, на которых работает соответствующее программное обеспечение. Мы начали скоординированное раскрытие информации в октябре 2018 года, чтобы уведомить группы разработчиков об уязвимых криптовалютах перед этим публичным выпуском. Большинство из них (взвешенных по рыночному капиталу) уже развернули меры по смягчению.

Криптовалюты Proof-of-Stake (PoS), особенно те, которые основаны на PoSv3 на основе цепочки ( Proof-of-Stake версия 3 ), аналогичны биткойнам в том, что они используют модель UTXO и правила консенсуса с самой длинной цепью. Ключевое отличие состоит в том, что они заменяют Proof-of-Work на подтверждение владения монетами. Потенциальные преимущества подхода PoS варьируются от снижения воздействия на окружающую среду до повышения безопасности против 51% атак. Многие криптовалюты на самом деле являются ветвями (или, по крайней мере, потомками) кодовой базы Биткойна, с привитой функциональностью PoS. Однако некоторые идеи проекта небезопасно копируются, что приводит к новым уязвимостям, которых не было в родительской кодовой базе.

Мы называем найденные уязвимости «поддельными ставками». По сути, они работают, потому что реализации PoSv3 не проводят адекватную проверку сетевых данных перед выделением ценных ресурсов (диск и ОЗУ). Следствием этого является то, что злоумышленник без особой заинтересованности (а в некоторых случаях и вовсе) может вызвать сбой узла-жертвы, заполнив его диск или ОЗУ фиктивными данными. Мы считаем, что все валюты, основанные на модели UTXO и самой длинной цепочке Proof-of-Stake, уязвимы для этих атак «поддельного кола». Список криптовалют, которые мы исследовали и полагаем, были затронуты, показан в конце статьи.

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

Фон:

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

Доказательство добычи:

Как и при майнинге Proof-of-Work, майнинг в PoS состоит из сравнения хеша заголовка блока с целью сложности. Цель PoS высокого уровня состоит в том, чтобы гарантировать, что шансы каждого участника на майнинг следующего блока пропорциональны количеству монет, которые они контролируют. Для этого в PoS на основе цепочки хэш зависит не только от заголовка блока, но и от количества монет, включенных в специальную транзакцию «получения монет», вставленную заинтересованным лицом в блок. Точные детали PoS майнинга могут быть немного сложными, и подробное объяснение можно найти в блоге Earlz. Для этого поста важно то, что проверка PoS зависит от 1) транзакции получения монеты и 2) UTXO, потраченной транзакцией получения монеты.

Роль Proof-of-Work в защите ресурсов проверки блоков:

Хорошо известно, что Proof-of-Work (PoW) играет важную роль в достижении биткойн-консенсуса. Но Proof-of-Work также играет вторую, несколько менее значимую роль, которая защищает доступ к ограниченным ресурсам узла, таким как диск, полоса пропускания, память и процессор. В криптовалютной сети без прав доступа одноранговым узлам нельзя доверять. Таким образом, для предотвращения атак исчерпания ресурсов узлы Биткойн сначала проверяют PoW на наличие принятых блоков, прежде чем выделять больше ресурсов, таких как хранение блока в ОЗУ или на диске. Однако оказывается, что проверка Proof-of-Stake намного сложнее и контекстно-зависима, чем проверка Proof-of-Work. В результате многие реализации PoS на основе цепочек экономили на соответствующей проверке.

Чтобы понять, как это приводит к уязвимости, связанной с исчерпанием ресурсов, мы должны немного рассказать о том, как блоки хранятся перед проверкой. Узел должен не только отслеживать самую длинную цепочку в текущий момент времени, но также и дерево цепочек вилок (любая из них может оказаться самой длинной цепью, и в этом случае узел должен «перезапустить», чтобы переключиться на него ). Это может произойти, например, во время неудачного обновления, атаки с двойным расходом (атака ETC до 51% ) или временного сетевого раздела.

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

1. «Откатить» текущий вид (установлен UTXO) до точки перед началом форка, или
2. хранить копии набора UTXO для всех предыдущих блоков.

Кодовая база Биткойна не поддерживает Вариант 2, и даже если бы он это сделал, это привело бы к дополнительным затратам на хранение (производительность узла Биткойн зависит от агрессивного удаления ненужных данных). Вариант 1 – это именно то, как база данных биткойнов в настоящее время обрабатывает реорг. Однако это может быть очень дорого, поэтому откат и полная проверка отложены до последнего возможного момента, когда Proof-of-Work в форке уже больше, чем текущая основная цепь. Таким образом, вместо того, чтобы одноранговый узел впервые получил блок или заголовок, который не является частью самой длинной цепочки, полная проверка пропускается, и блок сохраняется в локальном хранилище.

Перед сохранением блока на диск кодовая база Биткойн выполняет некоторую предварительную проверку на основе PoW (но игнорирует транзакции). Эта предварительная проверка зависит только от предыдущего заголовка блока и текущего заголовка, поэтому узел может сделать это очень быстро. И это эффективная защита, потому что генерация действительного PoW, который его проходит, очень дорогая. Например, хотя можно обмануть узел Биткойн, чтобы он хранил недопустимый блок на диске, монтировать атаку на исчерпание ресурсов таким способом непозволительно дорого.

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

Уязвимость № 1: «Я не могу поверить, что это не кол»

Когда мы впервые исследовали эту проблему, мы обнаружили, что пять криптовалют, Qtum, Particl, Navcoin, HTMLcoin и Emercoin, продемонстрировали довольно тривиальную форму этой уязвимости: а именно, они вообще не проверяют какую-либо монетную транзакцию перед фиксацией блока в ОЗУ или диск. Общим для этих пяти криптовалют является то, что они приняли функцию биткойнов «сначала заголовки», в которой распространение блоков было разделено на два отдельных сообщения: блок и заголовок. Узлы запрашивают блокировку только после того, как заголовок прошел проверку PoW И это самая длинная (или длинная) цепочка. Поскольку транзакция сбора монет присутствует только в блоке, но не в заголовке, узел не может самостоятельно проверить заголовок. Вместо этого он непосредственно сохраняет заголовок в структуре данных в памяти (mapBlockIndex). В результате любой сетевой злоумышленник, даже не имея никакой ставки, может заполнить ОЗУ узла-жертвы.

Второй вариант этой атаки может быть выполнен для тех же кодовых баз, хотя он работает немного по-другому и нацелен на другой ресурс, диск жертвы, а не ОЗУ. Можно предположить, что атака с использованием диска более вредна для жертвы: если ОЗУ заполнено и узел выходит из строя, его можно просто перезапустить. Однако, если диск заполнен, потребуется ручное вмешательство (например, для запуска внешнего сценария для очистки устаревших блоков с диска).

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

Эксплуатация любой из этих уязвимостей может быть осуществлена ​​без участия в криптовалюте. Версия атаки в ОЗУ особенно тривиальна, но по техническим причинам дисковая версия атаки требует немного большей осторожности ( хотя все равно никакой ставки не требуется) . Детали объяснены в коротком документе, который будет представлен на Финансовой Криптографии 2019 .

Уязвимость # 2 и атака на потраченный кол

Прослеживая происхождение этих кодовых баз, мы заметили, что уязвимость # 1 была первоначально введена при объединении функции Bitcoin «header-first» в кодовую базу PoSv3. Атака не работает на более ранних версиях (например, Peercoin), поскольку перед сохранением блоков на диске есть две дополнительные предварительные проверки:

1. Проверьте, существует ли расходуемый выход в главной цепи.
2. Проверьте, соответствует ли хеш ядра PoS цели сложности.

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

Проблема А : Проверка 1 гарантирует, что монета существует, но НЕ, что она не потрачена. Это понимание сразу же приводит к уязвимости, которую мы обсудим далее.

Проблема B : Даже если мы проверяем блок на развилке основной цепочки, транзакция состязания проверяется по TxDB для самой главной цепочки.

Основываясь на проблеме А, мы также нашли способ обмануть эти проверки, используя более тонкую атаку, которую мы называем « атака с использованием кола ». Чтобы обойти проверку 1, мы используем вывод, который виден узлом, но уже потрачен , Как правило, чтобы обойти Проверка 2, нам нужно было бы добыть действительный блок, который проходит цель сложности, которая в свою очередь потребовала бы большого количества ставки. Однако, как выясняется, мы можем злоупотреблять неполной проверкой, чтобы генерировать произвольное количество видимой ставки, используя технику, которую мы называем « усиление ставки ».

Усиление кола

Чтобы выполнить атаку, начиная с небольшого количества ставок, атакующий должен увеличить их количество кажущейся ставки. Под очевидной ставкой понимаются итоговые результаты ставок кандидатов, даже те, которые уже потрачены. Если злоумышленник начинает с UTXO суммы k, то злоумышленник может создать несколько транзакций, тратя монеты обратно злоумышленнику, как показано на рисунке ниже. Для размещения может быть разрешено только UTXO (n + 1 ), но благодаря проверке 2, приведенной выше, мы можем делать ставки со всеми UTXO от 1 до n + 1 , увеличивая тем самым кажущуюся ставку на n * k . Это увеличивает шансы найти блок PoS, так как злоумышленник может продолжать делать это, чтобы увеличить свою очевидную ставку. Это показано как « шаг амплификации кола » на левой стороне иллюстрации ниже.

Например, даже имея 0,01% акций в системе, злоумышленнику требуется только 5000 транзакций для майнинга блоков с 50% очевидной мощности пакета. После того, как злоумышленник собрал большое количество видимых ставок, он затем приступил к добыче блоков PoS в прошлом, используя недавно собранные выходные данные очевидных ставок. Наконец, злоумышленник заполняет диск равноправного узла недействительными блоками, как показано в правой части иллюстрации выше. Злоумышленник может, например, купить несколько монет на бирже, увеличить ставку за счет собственных расходов, как мы описали, а затем продать эти монеты обратно на биржу, выполнив атаку в любой более поздний срок. Злоумышленнику придется заплатить только за транзакции.

Скоординированное раскрытие уязвимостей

Сначала мы исследовали уязвимость # 1 в контексте криптовалют Particl и Qtum. Чтобы определить степень этой уязвимости, мы собрали список известных криптовалют с сайта coinmarketcap.com (9 августа 2018 г.), отсортированный по рыночной капитализации, и фильтруется по согласованному типу PoS. Мы смотрели только на криптовалюты, чья кодовая база была разветвлена ​​от (потомка) биткойна, то есть в C ++. В общей сложности мы исследовали 26 криптовалют и обнаружили, что были затронуты только пять криптовалют (Qtum, Navcoin, HTMLcoin, Emercoin и Particl), но наша атака, похоже, не сработала на остальных. Чтобы подтвердить уязвимость, мы реализовали атаки в каждой из пяти затронутых кодовых баз. Мы использовали существующие тестовые наборы в программном обеспечении Биткойн, в частности режим regtest , который позволяет имитировать временные метки и легко создаваемые блоки, и тестовый узел на основе Python (на основе биткойна TestFramework ), который можно расширять с помощью поведения злоумышленника. Мы использовали контейнеры Docker для упаковки этих тестов, их зависимостей и конкретного хэша фиксации, включенного в набор для воспроизводимости, который мы могли бы легко поделиться со всеми пятью затронутыми группами разработчиков в рамках нашего раскрытия уязвимости.

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

Одним из усложняющих факторов является то, что большинство этих кодовых баз не имели режима регестрации, поэтому мы не могли легко продемонстрировать атаку или предоставить набор воспроизводимости для каждого из них. Поэтому мы только продемонстрировали кодовую базу C ++ stratisX. Основываясь на сходстве кодовых баз, мы сообщили всем пятнадцати командам, что, по нашему мнению, это повлияет. Пять групп признали эту уязвимость, три все еще проводят расследование, три опровергли ее (указали на изменения в реализации, которые оказали смягчающее воздействие), а четыре группы не дали ответа. Для четырех команд, которые не ответили, мы связались с ними по каналам, которые мы могли найти на их веб-сайтах. ⁶ Наш комплект по воспроизведению Github для обеих уязвимостей можно найти здесь, а наш краткий документ об уязвимости # 1 можно найти здесь . Мы также зарезервировали CVE для уязвимостей, которые скоро должны быть опубликованы.

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

В некоторых других криптовалютах добавлена ​​частичная проверка вплоть до фиксированной длины. Er Если одноранговый узел получает блок, который разветвляется из главной цепи после этой длины, то блок просто отбрасывается. Этот подход также используется, например, в кодовой базе ABC BCH (Bitcoin Cash), в которой используется скользящая контрольная точка из 10 блоков. Недостаток этого подхода заключается в том, что он вводит возможность «разделения цепей». Разделение цепей происходит, когда честные узлы оказываются на разных расходящихся ветвях блокчейна. Это может произойти, например, если плохое сетевое соединение приводит к тому, что узлы не синхронизируются друг с другом в течение достаточно длительного времени для создания конфликтующих контрольных точек. Даже если узлы восстановят соединение, они не смогут достичь общего представления о цепочке. Мы отмечаем, что риск разделения цепей присутствует даже без этого снижения. Вспоминая озабоченность B из более ранней версии, поскольку транзакция сбора монет проверяется с использованием выходных данных транзакции в текущей цепочке, возможно, что узел не сможет переключиться на фактическую основную цепочку, если он временно окажется на вилке.

Риск разделения цепей также вводит новые векторы атаки для враждебных майнеров. Злоумышленник может попытаться секретно добыть длинную цепочку, а затем опубликовать ее в подмножестве узлов, чтобы вызвать разрыв цепочки. Узлы в IBD (Initial Block Download) или узлы, которые только что перезапустились после длительного периода автономной работы, особенно уязвимы для этой атаки. Такие атаки могут сочетаться с атаками затмения, чтобы привести честные узлы в цепочку, контролируемую атакующим.

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

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

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

Последние мысли

Хотя атаки по принципу «поддельной ставки» в принципе просты, они подчеркивают сложную задачу проектирования: некоторые идеи, имеющие смысл в Proof-of-Work, не передаются надежно в Proof-of-Stake. Учитывая высокую степень совместного использования кода Bitcoin Core как «восходящего потока» среди криптовалюты PoSv3, мы считаем, что это заслуживает еще большей проверки. При исследовании этих уязвимостей мы обнаружили несколько примеров в различных кодовых базах незавершенного производства (или закомментированного кода), которые направлены на различные меры по снижению риска и специальные защиты. Для нас это говорит о том, что разработчики PoS осознают, что компромиссы и требования в этой области дизайна еще не до конца поняты. Проблема в том, что, с одной стороны, мы хотим как можно скорее отклонить недопустимые блоки, но, с другой стороны, мы не хотим застрять в разрыве цепочки или откладывать обработку того, что на самом деле является главной цепочкой. Системный способ решения этой проблемы остается открытой проблемой для будущей работы.

Хотя мы видели недавние примеры (например, CVE 2018–17144 в BTC), затрагивающие, по крайней мере, две кодовые базы, насколько нам известно, это первое скоординированное раскрытие уязвимости безопасности в таком большом количестве (более 20) независимых криптовалют. Учитывая количество форков и повторного использования кода в криптовалютах, мы ожидаем появления таких уязвимостей в будущем. Мы обнаружили, что между этими основами кода было мало единообразия в процессе обеспечения безопасности. Например, для большинства из них не было выделенного контакта по безопасности. Внедрение лучших практик для скоординированных раскрытий может принести пользу всей экосистеме.

[1] Идея этой уязвимости возникла летом 2018 года, когда Эндрю Миллер работал с разработчиками Unit-E. Мы благодарим Маттео Сумбераза и Джила Данцигера за полезные обсуждения и Фонд DTR ( https://dtr.org/ ) за исследовательский грант.

[2] Emercoin внедрил эвристику для обнаружения уязвимостей. https://github.com/emercoin/emercoin/commit/ec32762b99cc68fb9abb2909dda96bc7a13bd819

[3] Скользящие контрольные точки в Qtum https://github.com/qtumproject/qtum/commit/8d208d0bee8449c1e4a3904ff3fc97ed26156648

[4] Примеры специальных проверок для PoS можно найти здесь: https://github.com/peercoin/peercoin/blob/ebb4003ce8367501020181f7e734d52c4b1ab5ea/src/main.cpp#L2564

[5] Мы обратились к некоторым монетам по электронной почте, указав их веб-страницу или функцию «отправить заметку»

[6, *] Мы пытались связаться с PIVX несколько раз, начиная с ноября, через [ контактную форму на их веб-сайте ]. Только во время написания этого поста мы поняли, что [ PIVX также запустил проект по хакеронам ]. Мы отмечаем, что даже на сегодняшней странице [ страница с сообщениями об ошибках на самом сайте PIVX ] вообще не упоминается проект хакерона.

[**] StratisX перешел на реализацию C # со своей уязвимой базы кода C ++.