Взлом DAO без взлома кода: как ограбить казну, выиграв выборы

В апреле 2022 года Beanstalk потерял около 181 миллиона долларов в результате атаки на систему управления (governance exploit).

Самым странным было не то, что нападавший как-то обошел систему прав доступа протокола.

Система прав доступа ответила: да.

Контракт управления Beanstalk проверил, поддерживает ли предложение достаточная сила голоса. Злоумышленник временно получил необходимую силу голоса. Порог был достигнут. Предложение исполнилось.

Код не забыл проверить авторизацию.

Проблема заключалась в том, что именно система соглашалась принять в качестве авторизации.

Управление — это больше, чем просто голосование

Легко представить управление в DAO как крипто-версию выборов: держатели токенов обсуждают предложения, голосуют, и большинство побеждает.

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

Это делает управление частью периметра безопасности.

Токен голосования — это не буквально пароль, но экономически он может вести себя как учетная запись доступа. Достаточная сила голоса может дать право указывать протоколу, что делать дальше.

И как только полномочия становятся передаваемым финансовым активом, возникает новый вопрос безопасности:

Насколько дорого обойдется получение достаточных полномочий?

Флэш-кредит дает капитал, а не полномочия

Именно здесь в истории появляются флэш-кредиты (flash loans).

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

Это может звучать почти сверхъестественно: одолжить сотни миллионов, использовать их, вернуть и остаться без долгов.

Но сам по себе флэш-кредит не может захватить DAO.

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

Хорошо спроектированная система голосования может спросить:

Какова была сила голоса у этого адреса до начала предложения?

Уязвимая система фактически спрашивает:

Какая сила голоса у этого адреса прямо сейчас?

Эта разница может быть огромной.

Beanstalk: Заимствование квалифицированного большинства

Beanstalk сделал эту разницу мучительно очевидной.

До атаки 17 апреля 2022 года злоумышленник подготовил предложения по управлению и выждал требуемый протоколом период ожидания. Затем в одной транзакции нападавший взял в заем более 1 миллиарда долларов в активах из пулов ликвидности DeFi и конвертировал эти временные средства в позиции, генерирующие право голоса Beanstalk, известные как Stalk ^[1].

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

Затем злоумышленник использовал эти полномочия для выполнения вредоносного предложения через собственную систему управления протокола.

После того как предложение перевело активы протокола, временные позиции были закрыты, а флэш-кредиты возвращены — всё внутри одной и той же атомарной транзакции.

Анализ безопасности оценил общий убыток протокола примерно в 181–182 миллиона долларов, тогда как Beanstalk описал около 77 миллионов долларов пользовательских активов, не относящихся к Beanstalk, как украденные. Это разные цифры, измеряющие разные части ущерба.

Главная суть не в точной сумме.

Она в пути авторизации:

взять капитал в заем
      ↓
конвертировать капитал в силу голоса
      ↓
преодолеть порог управления
      ↓
авторизовать предложение
      ↓
выполнить
      ↓
вернуть заемный капитал

Нападавшему не требовалось постоянно владеть контрольным пакетом Beanstalk.

На время одной транзакции временного капитала оказалось достаточно, чтобы стать временным авторитетом.

Недостающим элементом безопасности было время

Случай Beanstalk раскрывает парадоксальный факт о безопасности:

задержка может служить защитой.

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

Современные фреймворки управления поэтому используют такие механизмы, как исторические снимки голосов (snapshots) и временные блокировки исполнения (timelocks) ^[2].

Снимок может измерять силу голоса на более раннем блоке, а не в момент отдачи голоса. Заимствование токенов и их возврат внутри одной транзакции в таком случае не создает волшебным образом исторической силы голоса.

Таймлок решает другую проблему. Даже после того как предложение прошло, исполнение откладывается.

Эта задержка дает пользователям, делегатам, командам безопасности и хранителям протокола время заметить одобренное решение и отреагировать до того, как команда станет необратимой.

В обычном софте задержка часто воспринимается как трение.

В управлении трение может быть функциями безопасности.

Build Finance: Без кредитов на миллиард

Beanstalk может заставить думать, что атаки на управление требуют экзотической финансовой инженерии.

Build Finance показал куда более простой вариант.

В феврале 2022 года злоумышленник накопил достаточно токенов управления BUILD, чтобы предложить передать себе контроль над важными частями протокола ^[3].

Первая попытка была замечена и отбита.

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

Оно прошло.

Как только предложение передало атакующему контроль над инфраструктурой чеканки и управления, нападавший создал новые токены BUILD, продал их в доступную ликвидность, получил доступ к активам казны и нанес убытки примерно на 470 000 долларов.

Никакого гигантского флэш-кредита не потребовалось.

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

Насколько децентрализовано решение?

Здесь подсчет держателей токенов может вводить в заблуждение.

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

Файхтингер и коллеги изучили 21 систему ончейн-управления и обнаружили, что в 17 из них менее десяти держателей токенов или делегатов было достаточно для контроля более половины голосовой силы ^[4].

Это не значит, что каждое из этих DAO контролировалось злоумышленниками.

Это означает, что важная метрика управления — это не просто:

Сколько держателей существует?

А скорее:

Сколько независимых участников требуется для определения исхода?

Это могут быть совершенно разные цифры.

Тогда у голосов появляется цена

Есть еще одно следствие превращения управления в токенизированный актив.

Если голосование определяет, куда текут деньги, сама сила голоса становится экономически ценной.

Система измерителей Curve (gauge system) сделала это особенно очевидным. Держатели силы голоса могут влиять на то, куда направляются эмиссии токенов, а такие платформы, как Votium, возникли для координации стимулов вокруг этих голосов ^[5].

Это не то же самое, что враждебный захват казны.

Система специально устроена так, чтобы экономические участники соревновались за влияние на управление.

Но это делает более широкую мысль предельно понятной:

власть управления имеет рыночную цену.

Как только голос начинает управлять денежными потоками, протоколы могут рассчитать, сколько этот голос стоит. Другие участники могут сделать то же самое.

Сколько стоит стать DAO?

Это меняет взгляд на безопасность управления.

Главный вопрос не просто в том, может ли нападавший найти баг.

Он в том, является ли получение контроля экономически практичным.

Концептуально стоимость зависит от нескольких вещей:

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

Это не буквальная формула. Это способ увидеть периметр атаки.

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

Иными словами, у безопасности DAO есть экономическое измерение.

Протоколу нужно сделать враждебные полномочия достаточно дорогими для получения и достаточно медленными для обнаружения.

Больше трения — больше безопасности

Очевидным ответом кажется: заставить всех голосовать за всё.

Это не очень хорошо масштабируется.

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

Поэтому зрелые системы управления часто добавляют структуры, которые звучат менее «чисто децентрализованно»:

• делегатов, специализирующихся на управлении;
• пороги предложений, предотвращающие спам;
• исторические снимки голосов (snapshots);
• таймлоки перед исполнением;
• хранителей или советы с ограниченными экстренными полномочиями;
• окна вето для явно опасных изменений.

Каждый из этих механизмов вносит трение или элемент доверия.

Это создает реальное инженерное напряжение.

Уберите слишком много тормозов — и враждебные полномочия могут сработать быстрее, чем сообщество успеет отреагировать.

Добавьте слишком много хранителей — и система станет выглядеть менее автономной.

Не существует идеальной настройки, которая заставит этот компромисс исчезнуть.

Право указывать коду, что делать

Смарт-контракт отлично умеет отвечать на механические вопросы.

Достигло ли предложение нужного порога?

Закончился ли период голосования?

Истек ли таймлок?

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

Это свойства системы управления вокруг контракта.

Вот почему безопасный код — это лишь часть безопасности DAO.

Казна может быть защищена безупречными проверками прав доступа.

Но кто-то все равно должен решать, кому разрешено им соответствовать.

Иногда взлому подвергается не сам код. Взламывается право указывать коду, что делать.