CC BY
228
ИНФОРМАТИКА, ВЫЧИСЛИТЕЛЬНАЯ ТЕХНИКА И УПРАВЛЕНИЕ
УДК 004.42.056 ББК З972.53
ВС. БОРОВИК, ММ. ЗЕНИН, Ю.А. ГАТЧИН, АН. ЮГАНСОН К ВОПРОСУ О БЕЗОПАСНОСТИ СМАРТ-КОНТРАКТОВ
Ключевые слова: блокчейн, уязвимости программного обеспечения, смарт-контракты, язык программирования Solidity.
Смарт-контракты предназначены для заключения и поддержания коммерческих контрактов в технологии блокчейн. Эта технология лежит в основе децентрализованных приложений. Наибольшую популярность на данный момент имеют приложения, написанные с помощью смарт-контрактов на платформе Ethereum. Смарт-контракты, как и обычные программы, подвержены различным уязвимостям. В данной работе описаны результаты исследования безопасности смарт-контрактов, написанных на языке Solidity, для блокчейна на платформе Ethereum. Рассмотрены наиболее популярные уязвимости, даны рекомендации по их устранению. Итогом работы стала классификация уязвимостей, основанная на оценке степени возможного ущерба, а также актуальности, сложности и вероятности реализации.
Постановка проблемы. На сегодняшний день широкое применение находят смарт-контракты. Они обрабатывают и передают значительные активы. Очень важно, чтобы данные контракты исполнялись правильно, а их реализация была защищена от атак, направленных на кражу или подделку активов. Данный вопрос рассматривается в отношении смарт-контрактов, написанных на языке программирования Solidity для плафтомы Ethereum - самой известной и используемой платформы для смарт-контрактов.
Разрабатываемая классификация уязвимостей необходима для формулировки задач, решение которых позволит обеспечить защиту информации, циркулирующей в смарт-контрактах. Обозначенные задачи должны решаться на этапах проектирования и построения систем защиты информации в смарт-контрактах [3].
Технология блокчейн и смарт-контракты. Блокчейн - распределённый цифровой реестр, обеспечивающий принцип неизменности данных, представляющий собой постоянно растущую последовательность блоков, которая распространяется между участниками с помощью пиринговых сетей [7]. В каждый блок добавляется хэш-сумма (рис. 1), которая высчитывается от всех транзакций, входящих в этот блок, и хэш-суммы предыдущего блока по алгоритму merkle tree [6]. Из-за того, что хэш-сумма текущего блока зависит от хэш-суммы предыдущего блока невозможно изменить данные внутри блокчейна (рис. 2). Чтобы никто не мог изменить и пересчитать хэш-сумму, которая будет правильной с точки зрения системы, блокчейн использует несколько способов защиты: Proof of Work (PoW, доказательство работы) и Proof of Stake (PoS, доказательство владения).
Смарт-контракт представляет собой фрагмент кода, хранящийся в блок-чейне. Он приводится в действие транзакциями и имеет возможность читать данные или писать их в блокчейн, а также позволяет создавать свои токены,
которые работают на блокчейне Ethereum. Код контракта пишется на языке программирования Solidity, после чего компилируется до байт-кода для виртуальной машины Ethereum (EVM). За все производимые контрактом вычисления его разработчик платит узлу какое-то количество внутренней валюты -газа. Количество газа зависит от сложности вычислений в смарт-контракте, чем сложнее вычисления, тем больше газа придется заплатить.
Рис. 1. Формирование цепи блоков
Злок 1 Блок 2
Хэш блока 0 Хэш блока 1
Транзакция Транзакция
Транзакция Транзакция
Nonce Nonce
Рис. 2. Связь между блоками
Классификация уязвимостей смарт-контрактов. Далее под уязвимостью будем понимать слабость программного (программно-технического) средства или информационной системы в целом, которая может быть использована для реализации угроз безопасности информации1. В свою очередь, угроза - совокупность условий и факторов, создающих потенциальную или реально существующую опасность нарушения безопасности информации2.
По области происхождения можно выделить следующие виды уязвимостей:
1) уязвимости кода.
2) уязвимости архитектуры.
Рассмотрим уязвимости, относящиеся к первой группе. 1. Уязвимость типа «Состояние гонки» (рис. 3). Уязвимость заключается в возможности повторного вызова внешнего кода, во время выполнения кода контракта. Это может привести к тому, что различные вызовы функции будут взаимодействовать деструктивными способами.
1 ГОСТ Р. 56546-2015. Защита информации. Уязвимости информационных систем. Классификация уязвимостей информационных систем. М.: Стандартинформ, 2015.
2 ГОСТ Р. 50922-2006. Защита информации. Основные термины и определения. М.: Стандар-тинформ, 2006.
4 uint amountToWithdraw = userBalances[msg.sender];
5 require(msg.sender.call,value(amountToWithdraw)()); !! 1
6» В строчке 1 вызывается внешний кодл который может быть вызван повторно
Рис. 3. Уязвимость типа «Состояние гонки»
2. Уязвимость зависимости от временной метки (рис. 4). При написании контракта нужно иметь в виду, что узел, предлагающий следующий блок, имеет возможность записывать временную метку в него, исходя из своих интересов. Таким образом, он может оказывать влияние на выполнение контракта, полагающегося на значение временной метки в своем коде.
1 uint someVariable = noiv +■ li
2 - if (row % 2 == 0) { // now устанавливается найнером
3 11 важный код
4 }
5 * if ((soineVariable - 100) I 2 = 0) { // someVariable зависит от row
6 У/ важный код
7 }
Рис. 4. Уязвимость зависимости от временной метки
3. Уязвимость переполнения типов данных (рис. 5). Переполнение типов данных опасно тем, что изменение значения может происходить по не предусмотренной разработчиком логике. Данная уязвимость может происходить как с верхней границей типа данных, так и с нижней.
1 mapping (address => uint256) public balanceOf;
2 // Небезопасный вариант
3- function transfer(address _tOj uint256 _value) {
4- /* Проверка доступности суммы для отправки */
5 require(balanceOf[msg,sender] >= _value);
!*■ Add and subtract new balances */
balanceOf[msg.sender] = _value;
S balanceOf[_to] += _value;
9 >
10 П Безопасный вариант
11- function transfer(address _tOj uint256 _value) {
12- /* Проверка доступности суммы для отправки и проверка на переполнение */
13 require(
14 balanceOf [msg. sender] >-= _value &S
15 balanceOf[_to] + _value >= balanceOf[_to]
16 };
17 - /' Изменить балансы */
IS balanceOf[msg.sender] = _value;
19 balanceOf[_to] += _value;
20 >
Рис. 5. Уязвимость переполнения типов данных
К уязвимостям архитектуры можно отнести:
1. DDOS атака с возможным возвратом средств (рис. 6). Для примера, рассмотрим следующий контракт аукциона:
1 т contract suction {
2 address highestBidder;
3 uint fiighestBid; 4т function bid() i
5 if (msg,value < highestEid) throw;
if (highestBidder L= 0) { 7т унесли этот вызов постоянна возврадвет ошибку.,
S никто не может сделать ставку*/
9 if (LhighestBidder.send(highestBid)) throw;
10 }
11 highestBidder = msg. sender;
12 highestBid = msg.value;
13 }
14 }
Рис. 6. Контракт, подверженный DDOS атаке с возвратом средств
Если при попытке контракта вернуть средства предыдущему «лидеру» аукциона, возвращается ошибка - контракт принимает свое начальное состояние, и смены «лидера» не происходит. Это означает, что злоумышленник может стать «лидером» навсегда, убедившись, что попытка возврата ему средств терпит неудачу. Один из способов решения данной проблемы заключается в введение реестра средств участников аукциона и их возврата только по требованию владельца (рис. 7). Таким образом злоумышленник не может повлиять на ход выполнения функции bid().
1- contract auction {
2 address highestBidder;
3 uint highestEid;
4 inapping(address => uint) refunds; 5" function bidQ external {
6 if (msg,value < highestEid) throw;
7" if (highestBidder != 3) {
5 ¡1 Записать средства, которые нужно вернуть пользователи 9 refunds[highestBidder] += highestBid;
10 }
11 highestBidder = msg,sender;
12 highestBid = msg.value;
13 }
14 -- function withdrawfiefund(} external {
15 uint refund - refunds[nisg.sender];
16 refunds[msg.sender] = 0;
17" if ( !msg.sender.send(refund)) {
IS" /*
19 Вернуть состояние в исходное,
20 если произошла ошибка при отправке средств
21 */
22 refunds[msg.sender] = refund;
23 }
24 }
Рис. 7. Контракт, не подверженный DDOS атаке с возвратом средств
2. DDOS атака с ограниченным лимитом газа (рис. 8). Помимо проблемы, описанной выше, также существует возможность атаки на использование всего доступного контракту газа. В предыдущем примере уязвимый контракт возвращал средства при возникновении ошибки, что также могло привести к исчерпанию доступного контракту газа. Чтобы избежать данной проблемы, следует проверять доступный лимит газа внутри контракта при выполнении внешних операций, как в примере ниже:
10" " while (i"< payees.length && msg.gas > 20S300) { //Проверка доступности газа
Рис. 8. Контракт, не подверженный DDOS атаке с ограниченным лимитом газа
3. Уязвимости мультиподписи (рис. 9). Мультиподпись - разновидность цифровой подписи, позволяющая группе пользователей подписать один документ. Обычно алгоритм мультиподписи создаёт совместную подпись, которая более компактна, чем набор подписей от всех её участников. На платформе Ethereum мультиподпись интерпретируется в виде смарт-контракта, в котором могут содержаться все вышеописанные, а также специфичные только для него уязвимости. Одной из таких уязвимостей является отсутствие проверки на повторную инициализацию кошелька, что позволяет любому пользователю вызвать функцию инициализации кошельки и стать владельцем, получив полный доступ ко всем средствам [5].
1" func^i^n ini^Wallet(address [ ] _awners, uirct _required, uint _daylimit) {
Рис. 9. Уязвимость функции создания кошелька с мультиподписью
Сравнительная характеристика уязвимостей смарт-контрактов. Для проведения сравнения уязвимостей смарт-контрактов использовались следующие критерии [2]:
- вероятность реализации (P);
- степень возможного ущерба (D);
- актуальность реализации (A);
- сложность реализации (C).
Под вероятностью реализации уязвимости смарт-контракта понимается определяемый экспертным путем показатель, характеризующий, насколько вероятным является реализация ]-й уязвимости. Вводятся три вербальные градации этого показателя:
- низкая вероятность (1) - отсутствуют объективные предпосылки к реализации ]-й уязвимости безопасности информации, отсутствует требуемая статистика по фактам реализации ]-й уязвимости, отсутствует мотивация для реализации]-й уязвимости;
- средняя вероятность (2) - существуют предпосылки к реализации ]-й уязвимости, зафиксированы случаи реализации ]-й уязвимости (возникновения инцидентов безопасности), существуют признаки наличия у нарушителя мотивации для реализации]-й уязвимости;
- высокая вероятность (3) - существуют объективные предпосылки к реализации ]-й уязвимости, существует достоверная статистика реализации ]'-й уязвимости (возникновения инцидентов безопасности), у нарушителя имеются мотивы для реализации]'-й уязвимости.
Степень возможного ущерба от реализации конкретной уязвимости определяется степенью негативных последствий от нарушения конфиденциальности, целостности или доступности смарт-контракта. Вводятся три вербальные градации этого показателя:
- низкая степень ущерба (1) - в результате нарушения одного из свойств безопасности информации (конфиденциальности, целостности, доступности) возможны незначительные негативные последствия, такие как временная недоступность контракта. Владелец контракта (обладатель информации) не может использовать хотя бы одну из возложенных на контракт функций;
- средняя степень ущерба (2) - в результате нарушения одного или нескольких свойств безопасности информации (конфиденциальности, целостности, доступности) возможны умеренные негативные последствия, такие как потеря средств, временная недоступность контракта. Владелец контракта (обладатель информации) несет финансовые убытки и не может использовать хотя бы одну из возложенных на контракт функций;
- высокая степень ущерба (3) - в результате нарушения одного или нескольких свойств безопасности информации (конфиденциальности, целостности, доступности) возможны существенные негативные последствия, например, потеря управления над контрактом. Владелец контракта (обладатель информации) не может использовать возложенные на контракт функции.
Определение актуальности уязвимости приводится на основе вероятности реализации и степени возможного ущерба с помощью таблицы (табл. 1).
Таблица 1
Определение актуальности уязвимости
Вероятность реализации угрозы Степень возможного уще] рба
низкая (1) средняя (2) высокая (3)
Низкая (1) неактуальная (0) неактуальная (0) актуальная (1)
Средняя (2) неактуальная (0) актуальная(1) актуальная (1)
Высокая (3) актуальная (1) актуальная(1) актуальная (1)
Определение сложности реализации производится на основе экспертной оценки требуемой квалификации для реализации уязвимости. Потенциал, требуемый нарушителю для реализации j-й уязвимости, может быть базовым (низким), базовым повышенным (средним) или высоким. Значение потенциала нарушителя для реализации j-й уязвимости определяется на основе данных, приведенных в банке данных угроз безопасности информации ФСТЭК России [1]. Вводятся три вербальные градации этого показателя:
- низкий потенциал (1) - специальных навыков не требуется;
- средний потенциал (2) - требуются базовые навыки программирования;
- высокий потенциал (3) - требуются глубокие знания.
В результате определения перечисленных показателей для исследуемых типов уязвимостей можно вычислить оценку критичности каждого типа уязвимости по следующей формуле:
P + D
st =-±с~. (1)
Данная оценка показывает, насколько критична та или иная уязвимость для владельца контракта. Полученный результат можно использовать в методике [4] для оценки технологической безопасности смарт-контрактов, написанных на языке Solidity для блокчейна на платформе Ethereum.
Сравнительная характеристика уязвимостей, полученная в результате оценки их критичности, приведена в табл. 2.
Таблица 2
Сравнительная характеристика уязвимостей смарт-контрактов
Тип уязвимости Вероятность реализации (Р) Степень возможного ущерба (Б,) Актуальность реализации (А) Сложность реализации (С) Итоговая оценка (Si)
Уязвимость «состояние гонки» Высокая (3) Низкая (1) Актуальная (1) Высокая (3) 1,33
Уязвимость зависимости от временных меток Низкая (1) Низкая (1) Неактуальная (0) Высокая (3) 0,67
Уязвимость переполнения типов данных Высокая (3) Средняя (2) Актуальная (1) Низкая (1) 5
Уязвимость ББОБ с возвратом средств Высокая (3) Высокая (3) Актуальная (1) Средняя (2) 3
Уязвимость ББОБ с ограниченным лимитом газа Высокая (3) Высокая (3) Актуальная (1) Средняя (2) 3
Уязвимости мультиподписи Средняя (2) Высокая (3) Актуальная (1) Высокая (3) 1,67
На основе табл. 2 можно сделать вывод, что уязвимость переполнения типов данных является наиболее критичной из-за низкой сложности реализации, высокой вероятности реализации и средней степени ущерба. При этом уязвимость зависимости от временных меток является наименее критичной,
так как данная уязвимость требует высокой квалификации у злоумышленников и наносит незначительный ущерб.
Выводы. В результате исследования была рассмотрена проблема обеспечения информационной безопасности смарт-контрактов в блокчейне на платформе Ethereum. Проанализированы основные типы уязвимостей, дана оценка критичности каждого типа уязвимости. Введенная классификация уязвимостей позволяет сформулировать задачу защиты информации, циркулирующей в смарт-контрактах. Данная задача состоит в нивелировании угроз безусловных и условных, создаваемых в том числе в результате выявления ошибок программирования, технологических уязвимостей. Решение данной задачи позволит разработать общий подход к построению системы защиты информации в смарт-контрактах.
Литература
1. Банк данных угроз безопасности информации [Электронный ресурс]. URL: http://bdu.fstec.ru.
2. Методика определения безопасности информации в информационных системах [Электронный ресурс]. URL: https://fstec.ru/component/attachments/download/812.
3. Щеглов К.А. Постановка и подходы к решению задачи защиты информации от несанкционированного доступа в общем виде // Вестник компьютерных и информационных технологий. 2016. № 1. С. 32-44.
4. Югансон А.Н., Заколдаев Д.А. Разработка методики для расчета оценки технологической безопасности программных средств // Вестник УрФО. Безопасность в информационной сфере. 2017. № 1(23). С. 20-23.
5. Atzei N., BartolettiM., Cimoli T. A survey of attacks on Ethereum smart contracts (SoK). Proc. of Int. Conf. on Principles of Security and Trust. Berlin, Heidelberg, Springer, 2017, pp. 164-186.
6. Becker G. Merkle signature schemes, merkle trees and their cryptanalysis. Ruhr-University Bochum, Tech. Rep., 2008. Available at: http://www.emsec.rub.de/media/crypto/attachments/fi-les/2011/04/becker_1.pdf.
7. Nakamoto S. Bitcoin: A peer-to-peer electronic cash system. 2008. Available at: https://bitcoin.org/bitcoin.pdf.
БОРОВИК ВЛАДИМИР СЕРГЕЕВИЧ - студент IV курса факультета безопасности информационных технологий, Санкт-Петербургский национальный исследовательский университет информационных технологий, механики и оптики, Россия, Санкт-Петербург (bobahbdb@gmail.com).
ЗЕНИН МИХАИЛ МАКСИМОВИЧ - студент IV курса факультета безопасности информационных технологий, Санкт-Петербургский национальный исследовательский университет информационных технологий, механики и оптики, Россия, Санкт-Петербург (mix.zenin.ifmo@yandex. ги).
ГАТЧИН ЮРИЙ АРМЕНАКОВИЧ - доктор технических наук, профессор кафедры проектирования и безопасности компьютерных систем, Санкт-Петербургский национальный исследовательский университет информационных технологий, механики и оптики, Россия, Санкт-Петербург (gatchin@mail.ifmo.ru).
ЮГАНСОН АНДРЕЙ НИКОЛАЕВИЧ - аспирант кафедры проектирования и безопасности компьютерных систем, Санкт-Петербургский национальный исследовательский университет информационных технологий, механики и оптики, Россия, Санкт-Петербург (a_yougunson@corp.ifmo.ru).
V. BOROVIK, M. ZENIN, Yu. GATCHIN, A. IUGANSON TO THE SECURITY ISSUE OF SMART CONTRACTS Key words: blockchain, security vulnerabilities, smart contracts, programming language Solidity.
Smart-contracts are computer programs that can handle and transfer assets of considerable value. Blockchain is a key technology for decentralized applications. Nowadays. Ethereum is the most popular blockchain platform for smart-contracts. However smart-contracts are as vulnerable as common applications. The results of the research for security of Solidity-based smart contracts on the Ethereum blockchain are presented in this article. The most typical vulnerabilities in smart contracts are described in this paper. As a result a vulnerability classification was created based on the threat level, applicability, complexity and probability of the vulnerabilities.
References
1. Bank dannykh ugroz bezopasnosti informatsii [Data Security Threats Database]. Available at: http://bdu.fstec.ru.
2. Metodika opredeleniya bezopasnosti informatsii v informatsionnykh sistemakh [The method of determining information security in information systems]. Available at: https://fstec.ru/compo-nent/attachments/download/812.
3. Shcheglov K.A. Postanovka i podkhody k resheniyu zadachi zashchity informatsii ot nesank-tsionirovannogo dostupa v obshchem vide [Formulation and solving approaches of information securing against unauthorized access task in general]. Vestnik komp'yuternykh i informatsionnykh tekhnologii, 2016, no. 1, pp. 32-44.
4. Iuganson A., Zakoldaev D. Razrabotka metodiki dlya rascheta otsenki tekhnologiche-skoi bezopasnosti programmnykh sredstv [A calculation methodology of assess for software tecurity], 2017, no. 1(23), pp. 20-23.
5. Atzei N., Bartoletti M., Cimoli T. A survey of attacks on Ethereum smart contracts (SoK). Proc. of Int. Conf. on Principles of Security and Trust. Berlin, Heidelberg, Springer, 2017, pp. 164-186.
6. Becker G. Merkle signature schemes, merkle trees and their cryptanalysis. Ruhr-University Bochum, Tech. Rep., 2008. Available at: http://www.emsec.rub.de/media/crypto/attachments/fi-les/2011/04/becker_1.pdf.
7. Nakamoto S. Bitcoin: A peer-to-peer electronic cash system. 2008. Available at: https://bitcoin.org/bitcoin.pdf.
BOROVIK VLADIMIR - 4th year Student, Faculty of Information Technology Security, Saint Petersburg National Research University of Information Technologies, Mechanics and Optics, Russia, St. Petersburg (bobahbdb@gmail.com).
ZENIN MIKHAIL - 4th year Student, Faculty of Information Technology Security, Saint Petersburg National Research University of Information Technologies, Mechanics and Optics, Russia, St. Petersburg (mix.zenin.ifmo@yandex.ru).
GATCHIN YURIY - Doctor of Technical Sciences, Professor, Department of Computer System Design and Security, Saint Petersburg National Research University of Information Technologies, Mechanics and Optics, Russia, St. Petersburg (gatchin@mail.ifmo.ru).
IUGANSON ANDREY - Post-Graduate Student, Department of Computer System Design and Security, Saint Petersburg National Research University of Information Technologies, Mechanics and Optics, Russia, St. Petersburg (a_yougunson@corp.ifmo.ru).
Ссылка на статью: Боровик В.С., Зенин М.М., Гатчин Ю.А., Югансон А.Н. К вопросу о безопасности смарт-контрактов // Вестник Чувашского университета. - 2018. - № 1. - С. 79-87.
