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

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

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

7. Неопределенность изменения стоимости активов

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

Пример 7.1: Давайте проанализируем следующую модель работы умного контракта. Коммерческая компания оказывает услуги по страхованию грузоперевозок. Из-за сильной волатильности курса Ethereum и необходимости работы с подрядчиками, компания принимает решение хеджировать полученный Ether к доллару США. Таким образом, заранее зная точную цену, по которой получен Ether, участники сделки страхуют свои риски от вероятного колебания курса на криптовалютном рынке и изменения рыночной цены услуги по страхованию. Если что-то случится с товаром во время грузоперевозки, то страховая компания обязуется возместить нанесенный ущерб в Ether, но с привязкой к захеджированному ранее курсу.

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

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

8. Задержки при получении информации

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

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

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

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

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

9. Несоответствие полученных данных

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

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

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

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

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

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

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

Пример 10.1: Если логика умного контракта, к которому происходит обращение, будет изменена или умный контракт будет уничтожен, например, использовав операцию selfdestruct, то в таком случае работоспособность программы будет поставлена под угрозу. Реализация данного недостатка была продемонстрирована 8 ноября 2017, в результате чего было заблокировано более 500 000 Ether.

Способ устранения: Не стоит полностью полагаться на сторонний контракт, которым вы не управляете. Следует также заметить, что даже если код контракта не содержит вызов метода selfdestruct, то он все равно может выполнить эту операцию с использованием delegatecall или callcode.

11. Сложности прогнозирования и влияния на входные данные

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

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

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

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

12. Раскрытие и влияние собственных данных на результат работы

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

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

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

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

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

Благодарности за рецензию и пометки: Артур Пинчук, Роман Гребнев, Александр Бажанов, Максим Лазаревич, Константин Туровец, Павел Бука, Маргарита Жакович.

Подписывайтесь на новости Forklog в Facebook!