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

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

Представитель компании BugBounty.Center Григорий Васильков — платформы по предоставлению возможности аудита безопасности для сторонних компаний в сфере блокчейн-технологий и умных контрактов — специально для ForkLog проанализировал основные риски для блокчейн-компаний, связанные с безопасностью. Всего будет опубликовано три материала на эту становящуюся все более актуальной тему. С первым материалом вы можете ознакомиться здесь.

1. Несостоятельность экономической модели приложения

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

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

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

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

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

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

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

2. Невозможность прогнозирования внешних по отношению к экономике приложения факторов

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

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

Разработчику следует уделить внимание как минимум следующим аспектам:

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

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

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

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

3. Отсутствие стимулов обращения пользователей к смарт-контрактам, транзакционные издержки

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

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

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

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

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

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

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

где b — количество всех бонусных баллов, u — пользователь, x — бонусные баллы для каждого пользователя, то в таком случае потенциальная прибыль от стоимости баллов может быть гораздо ниже, чем издержки за транзакцию. Для этого злоумышленнику достаточно будет сгенерировать некоторое количество Ethereum-адресов и записать их в умный контракт. В текущей логике реализации приложения имеется еще и технический недостаток, такой как выход за пределы лимита газа в блоке.

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

4. Работа с непроверенными данными

Описание: Пожалуй, важнейшим применением смарт-контрактов может стать зарождающаяся уже сегодня инфраструктура Интернета вещей. Экономика будущего — это глобальная сеть умных вещей, общающихся друг с другом с помощью смарт-контрактов. Благодаря смарт-контрактам и “оракулам” (механизмам, позволяющим смарт-контрактам обмениваться информацией с внешним миром), умные автомобили смогут самостоятельно парковаться и заправляться, умные дома — осуществлять финансовые операции с арендаторами, а дроны — доставлять покупки и разносить пиццу.

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

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

Пример 4.1: В этом примере умный контракт обращается к внешнему источнику api.fixer.io для получения текущего курса фунта стерлинга GBP по отношению к евро EUR. Если сайт api.fixer.io будет взломан и данные подменены, то полученные результаты будут неверные.

Для сокрытия компрометации ресурса api.fixer.io злоумышленник может изменять отношения курса EUR/GBP только в момент обращения умного контракта к оракулу, считывая данную транзакцию из Memory Pool.

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

Надежность информации о стоимости курса фунта достигается переходом источника сведений в блокчейн. То же самое в случае любых других регулярных сведений.

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

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

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

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

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

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

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

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

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

Давайте рассмотрим потенциальные экономико-технические недостатки более детально. Для мотивации игроков введем денежный приз равный 2 Ether, который достанется победителю. Для того чтобы принять участие в игре, каждый пользователь должен внести взнос равный 1 Ether.

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

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

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

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

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

6. Возможность манипуляции порядком исполнения транзакций

Описание: Большинство транзакций, использующихся в умных контрактах, представляют собой открытые данные. Данные этих транзакций видны не только майнерам, но и любому пользователю Ethereum сети, который может обратиться к Memory Pool. Майнер решает, вносить ли отправленную транзакцию в блок, рассчитывая различные метрики, такие как Gas Price и Gas Limit. Быстрота принятия решения о внесении транзакции в блок также зависит от того, попадет ли наша транзакция в Uncles, и от времени формирования нового блока. Сейчас время формирования блока занимает около 13 секунд. В пиковых загрузках сети Ethereum наблюдались ситуации, когда свыше 4000 транзакций больше минуты не могли попасть в блок.

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

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

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

Применяя данный термин к блокчейн системам, можно с высокой долей вероятности предположить, что фронтраннингу подвержены все децентрализованные обменники и децентрализованные биржи. В этом случае злоумышленник может анализировать Memory Pool на наличие транзакций, отправленных на умный контракт биржи. Если заявка на покупку или продажу токенов будет соответствовать определённым критериям, то в таком случае злоумышленник может попытаться заставить майнера взять его транзакцию раньше, например, используя более высокую стоимость Gas Price, что в свою очередь приведет к получению прибыли для злоумышленника и изменению биржевого стакана для пользователя.

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

Продолжение следует.