Автоматизація виявлення вразливостей у смарт-контрактах

Размещено на http://www.allbest.ru/

Автоматизація виявлення вразливостей у смарт-контрактах

Використання блокчейну для побудови , представлене смарт-контрактами, активно розвивається в останні роки. Однак часті випадки вразливості смарт-контрактів становлять серйозний ризик для безпеки екосистеми блокчейн [3]. Оскільки поточні інструменти символьного виконання часто потрапляють у «вибух станів» та не точно описують вразливий стан, це призводить до неефективного виявлення, ця робота розширює структуру інструменту Mythril, щоб оптимізувати його продуктивність. По - перше, це дозволяє виявляти потенційно вразливі області коду за допомогою статичного аналізу та визначати критичні шляхи, які можуть мати дефекти безпеки. Потім, з огляду на проблему, що традиційні алгоритми пошуку не можуть активно знаходити та досліджувати критичні шляхи, ця робота представляє стратегію багатоцільового орієнтованого пошуку шляхів, засновану на пріоритеті шляху. Ця стратегія керує динамічним символьним виконанням, щоб швидко охопити критичні шляхи, уникаючи сліпого обходу шляхів виконання програми. Нарешті, вона описує правила безпеки та пропонує відповідні логіки виявлення для різних категорій уразливості. У роботі аналізується 46 вразливих та 52 виправлених смарт-контракти. блокчейн логіка смарт контракт

Приклад оптимізації виявлення на вразливості повторного входу

1) Опис. Коли контракт A викликає інший контракт B, A чекає завершення виконання виклику, перш ніж перейти до наступної інструкції за звичайних умов. Але якщо контракт, що викликається, B перериває цей виклик, викликаючи резервну функцію A, змушуючи контракт A працювати у невідповідному внутрішньому стані, що, очевидно, порушує наміри розробника і може призвести до несподіваної поведінки [1].

2) Логіка виявлення. Згідно з описом уразливості вище, перевірка оновлень стану є ключем до виявлення вразливостей повторного входу. Mythril використовує таку стратегію: виявити всі виклики повідомлень, які надсилаються на вказану користувачем адресу, і доставляють газ. Функції send() і transfer() Solidity встановлюють газ на 2300, і це налаштування може запобігти атакам повторного входу. Якщо виявлено зовнішній виклик на ненадійну адресу, аналізується граф потоку керування (ГПК) [2], щоб визначити, чи може відбутися зміна стану після повернення з виклику. Якщо виявлено оновлення стану, видається попередження. Однак ця стратегія занадто консервативна. Він позначає будь-яке оновлення стану після зовнішнього виклику як уразливість, незалежно від того, чи насправді оновлення стану викликає небезпеку. Тому генерується багато помилкових спрацьовувань. Наприклад, функції можуть бути захищені мьютексом, що не дасть виконати їх тіло, проте засіб його не бачить, оскільки не досліджує оновлений стан.

Для покращення більш розумною логікою виявлення, варто перевірити, чи може оновлений стан вплинути на рішення потоку керування (рис. 1). Оскільки спільні змінні між контрактами завжди зберігаються в сховищі, а змінна зберігання є єдиною внутрішньою змінною стану, яка може вплинути на потік керування при повторному введенні контракту, для виявлення потрібно лише звернути увагу на змінні в акаунті. Тому використовується методика аналізу плям. Змінні пам'яті позначаються як потенційно вразливі і відстежуються. Якщо рішення потоку керування в інструкції умовного переходу JMPI залежить від деяких змінних пам'яті, то зловмисник може маніпулювати напрямком розгалуження. Потім записується набір змінних пам'яті, що використовуються для керування рішенням потоку, і призначається тег VAR_FLAG=1. Якщо попередній виклик контракту намагається оновити змінну зі значенням тегу 1, видається попередження про вразливість повторного входу.

Рис. 1. Логіка виявлення повторного входу

Проведено порівняння ефективності інструментів (табл. 1). Розроблене рішення позначене як «mythril+». Засоби символьного виконання потребують суттєво більше часу, затратними є як фаза обходу ГПК (збір шляхів), так і фаза розв'язування обмежень.

Таблиця 1