Інструмент для виявлення метаморфічних смарт-контрактів

Важливим припущенням безпеки Ethereum є те, що код смарт-контракту є незмінним і тому не може бути змінений після розгортання в блокчейні. На практиці деякі розумні контракти може зміни – навіть після їх розгортання. За допомогою кількох хитрих прийомів ви можете створити метаморфічні смарт-контракти, які «метаморфоза” у щось інше – і, зрозумівши, що робить їх можливими, ви можете їх виявити.

Метаморфічні смарт-контракти є змінними, тобто розробники можуть змінювати код у них. Ці смарт-контракти становлять серйозний ризик для користувачів web3, які довіряють коду, який, як вони очікують, працюватиме з абсолютною послідовністю, особливо тому, що зловмисники можуть використовувати цю здатність змінювати форму. Уявіть собі зловмисника, який використовує цю техніку, щоб «обійти» людей, які розміщують токени в смарт-контракті, який вони не розуміють як метаморфічний. Атаки, засновані на цьому та подібних передумовах, можуть спорядити шахраїв полювати на людей і загалом підірвати довіру до повної перспективи децентралізованих систем.

Щоб проаналізувати, чи містить смарт-контракт метаморфічні властивості, Я побудував простий Детектор метаморфічних контрактів (натхненний та побудований на оригінальній роботі Джейсон різьбяр, 0 років та інші). Будь-хто може використовувати цей інструмент, щоб перевірити, чи даний контракт демонструє червоні прапорці, які можуть вказувати на потенціал метаморфізму. Метод не є надійним: те, що смарт-контракт показує прапор, не означає, що він обов’язково метаморфічний; і те, що це не так, не означає, що це безпечно. Контролер лише пропонує швидку початкову оцінку контракту може бути бути метаморфічним за можливими показниками. 

Користувачі Web3 повинні ознайомитися із загрозами, пов’язаними з метаморфічними контрактами, щоб вони могли виявляти й уникати можливих атак. Гаманці та індексатори блокчейнів можуть допомогти, попереджаючи користувачів перед тим, як вони взаємодіють зі смарт-контрактом, який може містити метаморфічні властивості. Цей інструмент призначений як для того, щоб поінформувати людей про цю потенційну загрозу… так і для захисту від неї.

Виявлення метаморфічних смарт-контрактів

Команда Детектор метаморфічних контрактів Я створив аналіз шести властивостей, які можуть вказувати на те, чи є смарт-контракт метаморфічним.

1. 1. Чи використовувався відомий метаморфічний код для розгортання контракту? Якщо відомий метаморфічний байт-код – код нижчого рівня, зчитуваний віртуальною машиною, на який смарт-контракти Ethereum, зазвичай написані в Solidity, перетворюються після компіляції – з’являється в транзакції для розгортання певного смарт-контракту, це серйозна тривога. У наступних розділах ми обговоримо один такий приклад метаморфічного байт-коду, розробленого 0age. Важливе застереження: існує потенційно незліченна кількість варіацій метаморфічного байт-коду, що ускладнює виявлення всіх різновидів. Проте, скануючи відомі приклади, детектор усуває зловмисники, які просто копіюють і вставляють наявні приклади.
   2. Чи може код смарт-контракту самознищитися? Щоб замінити код у контракті – ключовий крок у створенні метаморфічного контракту – розробнику спочатку потрібно видалити існуючий код. Єдиний спосіб зробити це за допомогою Код операції SELFDESTRUCT, команда, яка робить саме те, що звучить – стирає весь код і сховище за вказаною адресою контракту. Наявність самознищувального коду в контракті не доводить, що він є метаморфічним; однак він пропонує підказку, що договір може бути бути метаморфічним, і варто знати, чи можуть контракти, на які ви покладаєтеся, самі себе зруйнувати.
   3. Чи викликає смарт-контракт код з іншого боку? Якщо відповідний смарт-контракт не може безпосередньо самознищитися, він все одно може стерти себе за допомогою Код операції DELEGATECALL. Цей код операції дозволяє смарт-контракту динамічно завантажувати та виконувати код, який живе в іншому смарт-контракті. Навіть якщо смарт-контракт не містить коду операції SELFDESTRUCT, він може використовувати DELEGATECALL для завантаження коду, що самознищується з іншого місця. Хоча функція DELEGATECALL безпосередньо не вказує на те, чи є смарт-контракт метаморфічним, це можлива підказка та потенційна проблема безпеки, про яку варто звернути увагу. Майте на увазі, що цей індикатор може викликати багато помилкових спрацьовувань. 
   4. Чи розгорнув цей контракт інший контракт? Метаморфічні контракти можуть бути розгорнуті тільки іншими розумними контрактами. Це пов’язано з тим, що метаморфічні контракти ввімкнені іншим кодом операції, який можна використовувати лише іншими смарт-контрактами, який називається CREATE2. (Ми обговоримо CREATE2 – як це працює і чому це важливо – докладніше в наступному розділі.) Ця риса є одним із найменш помітних показників можливого метаморфізму; це необхідна, але недостатня передумова. Сканування цієї ознаки, ймовірно, призведе до багатьох хибних спрацьовувань, але це цінна інформація, яку потрібно знати, оскільки вона може викликати підозри та дати привід для подальшої перевірки контракту, особливо якщо смарт-контракт містить код операції, описаний далі.
   5. Чи містить договір розгортання код операції CREATE2? Як згадувалося вище, розгортання через CREATE2 є важливою передумовою для метаморфізму. Якщо контракт програми розгортання містить код операції CREATE2, це може означати, що він використовував CREATE2 для розгортання відповідного контракту. Якщо розгортач справді використовував CREATE2 для розгортання зазначеного контракту, хоча це не означає, що контракт обов’язково є метаморфічним, це означає, що він може бути бути метаморфічним, і, можливо, буде доцільно діяти обережно та досліджувати далі. Знову ж таки, остерігайтеся помилкових спрацьовувань: CREATE2 має багато законне використання, включаючи підсилення Рішення для масштабування рівня «2». і спростити створення гаманців з розумними контрактами, які можуть покращити web3 адаптація користувача і ключові варіанти відновлення.
   6. Чи змінився код? Це найбільш очевидний сигнал, але він з’явиться лише після того, як метаморфічний контракт уже зміниться. Якщо хеш коду смарт-контракту – унікальний криптографічний ідентифікатор – відрізняється від того, який був під час початкового розгортання контракту, то, ймовірно, код було видалено, замінено або змінено. Якщо хеші більше не збігаються, це означає, що щось у коді змінилося, і контракт може бути метаморфічним. Цей прапор є найвірнішим індикатором метаморфізму, але він не допоможе передбачити або запобігти морфінгу, оскільки він лише перевіряє, чи він уже відбувся.

На додаток до створення простого інструменту командного рядка для Metamorphic Contract Detector, я створив кілька прикладів смарт-контрактів, які демонструють сценарій шахрайського метаморфічного контракту, який я описую в наступному розділі. Весь код доступний тут GitHub сховище. 

Як зловмисник може використовувати метаморфічні контракти, щоб викрасти кошти людей

Ось як хтось може використовувати метаморфічний смарт-контракт як частину шахрайства. 

По-перше, це етап налаштування. Зловмисник розгортає смарт-контракт за певною адресою в блокчейні, використовуючи два інструменти: метаморфічний байт-код і код операції CREATE2. (Пізніше ми розглянемо обидві ці концепції.) Потім метаморфічний байт-код виконує те, що випливає з назви, і «перетворюється». Тут він змінюється на a договір ставок де користувачі можуть ставити токени ERC-20. (Знову ж таки, ми обговоримо деталі цього трюку трансформації пізніше. Обіцяю!)

Далі йде наживка та перемикач. Нічого не підозрюючи користувачі ставлять свої токени в цей контракт, спокушені можливістю заробити дохід або інші переваги. Потім зловмисник видаляє весь код стекінгу та «стан» — сховище чи пам’ять блокчейну — за цією адресою смарт-контракту за допомогою Код операції SELFDESTRUCT обговорювалося в попередньому розділі. (Слід зазначити, що токени, які існують як частина окремого контракту ERC-20, зберігаються, на них не впливає контракт, який самознищив.)

Нарешті, килимок. Зловмисник повторно використовує той самий метаморфічний байт-код, який використовувався на етапі налаштування, щоб «повторно розгорнути» новий контракт. Цей новий контракт розгортається за тією ж адресою, яку нещодавно звільнив контракт, який саморуйнується. Однак цього разу байт-код «перетворюється» (ми знову пояснимо, як пізніше) у зловмисний контракт, який може викрасти всі токени, розміщені на адресі контракту. Афера завершена. 

Ризики, які становлять метаморфічні смарт-контракти, вже очевидні. Але ви можете все ще дивуватися, як цей трюк метаморфізму насправді працює? Щоб зрозуміти це, вам потрібно дослідити глибше, до рівня байт-коду. 

Як CREATE2 відкриває можливість метаморфізму 

CREATE2 це оновлення коду операції, представив Ethereum у лютому 2019 року, який пропонує новий спосіб розгортання смарт-контрактів. 

CREATE2 дає розробникам більше контролю над розгортанням своїх смарт-контрактів, ніж раніше. Оригінальний код операції CREATE ускладнює розробникам контроль адреси призначення для смарт-контракту, який планується розгорнути. За допомогою CREATE2 люди можуть контролювати та знати адресу конкретного смарт-контракту заздалегідь, перш ніж фактично розгорнути його в блокчейні. Це передбачення – плюс деякі хитрі трюки – ось що дозволяє людям створювати метаморфічні смарт-контракти. 

Як CREATE2 може передбачити майбутнє? Розрахунок коду операції є детермінованим: доки вхідні дані не змінюються, адреса, визначена CREATE2, не зміниться. (Навіть найменша зміна спричинить розгортання в іншому місці.)

Більш детально, CREATE2 — це функція, яка об’єднує та хешує кілька елементів. По-перше, він включає адресу розгортача (або відправника): ініціюючий смарт-контракт, який діє як батьківський для того, який буде створений. Далі він додає довільне число, надане відправником (або «сіль»), що дозволяє розробнику розгортати той самий код на різні адреси (шляхом зміни солі) і запобігає перезапису існуючих ідентичних контрактів. Нарешті, він використовує хеш keccak256 деякого байт-коду ініціалізації смарт-контракту («init»), який є зерном, яке перетворюється на новий смарт-контракт. Ця хешована комбінація визначає адресу Ethereum, а потім розгортає заданий байт-код на цю адресу. Так довго, як байт-код залишається незмінним, CREATE2 завжди розгортатиме заданий байт-код за тією самою адресою в блокчейні.

Ось як виглядає формула CREATE2. (Примітка: у прикладі нижче ви помітите ще один елемент, «0xFF». Це просто константа, яку використовує CREATE2 запобігати зіткненням з попереднім кодом операції CREATE.)

Тепер, коли ми маємо спосіб розгорнути код на детерміновану адресу, як це можливо зміна код за тією ж адресою? Спочатку це може здатися неможливим. Якщо ви хочете розгорнути новий код за допомогою CREATE2, байт-код має змінитися, і, отже, CREATE2 буде розгорнуто за іншою адресою. Але що, якби розробник створив байт-код таким чином, щоб він міг «перетворюватися» в інший код, коли CREATE2 розгортає смарт-контракт?

Як насправді працює метаморфічний контракт

Рецепт перетворення смарт-контракту на метаморфічний контракт вимагає всього трьох смарт-контрактів, кожен з яких відіграє унікальну роль.

Одним із цих необхідних компонентів є Метаморфічна контрактна фабрика, мозок операції. Ця «Фабрика» відповідає за розгортання метаморфічного контракту, а також іншого смарт-контракту під назвою «Контракт реалізації», названого так тому, що його код зрештою реалізується всередині метаморфічного контракту. Тонка хореографія між цими трьома контрактами призводить до метаморфізму, як показано на діаграмі нижче.

Давайте детально обговоримо кожен крок, 1-7, щоб висвітлити операції під час роботи.

Крок 1: розробник запускає все

Кодер розробляє код смарт-контракту – байт-код контракту реалізації – який зрештою потрапляє в метаморфічний контракт. Розробник надсилає цей код до Metamorphic Contract Factory, розумного контракту, основною метою якого є розгортання інших смарт-контрактів. Ця дія запускає весь процес створення метаморфічного контракту.

Усе, що далі є результатом цього початкового кроку. Дійсно, Кроки з 1 по 6 відбуваються в одній атомарній транзакції в блокчейні, тобто майже всі одночасно. Ці кроки можна повторювати знову і знову, до нескінченності, щоб замінити код у Метаморфічному контракті та підтримувати його постійну трансформацію.

Крок 2: Завод розгортає контракт на впровадження

Перший контракт, який Factory розгортає, — це контракт на впровадження, який містить код впровадження. (Креативно, ми знаємо.) Подумайте про Контракт реалізації як про завантажувальну платформу або шляхову точку, яка містить певний код перед тим, як відправити його до кінцевого пункту призначення, який у цьому випадку буде всередині Метаморфічного контракту. 

Крок 3: Фабрика зберігає адресу контракту про впровадження

Після розгортання в блокчейні Договір про впровадження обов’язково буде існувати за певною адресою блокчейну. Фабрика зберігає цю адресу контракту у власній пам’яті (для використання пізніше, на кроці 5). 

Крок 4: Фабрика розгортає Metamorphic Contract

Фабрика розгортає метаморфічний контракт за допомогою CREATE2 і метаморфічного байт-коду. Ви можете знайти технічну, глибоку інструкцію про те, як працює метаморфічний байт-код тут, але достатньо сказати, що коли метаморфічний байт-код виконується, він копіює код з іншого місця в ланцюжку – у цьому випадку з Контракту реалізації – у Метаморфічний Контракт. Як ми вже говорили в попередньому розділі, оскільки CREATE2 є детермінованим – доки використовуються той самий відправник, сіль і байт-код – тоді адреса Метаморфічного контракту залишається незмінною незалежно від того, скільки разів ці кроки повторюються.

Нижче наведено приклад того, як виглядає метаморфічний байт-код із метаморфічний репо за 0 років. Це лише один приклад метаморфічного байт-коду – існує потенційно незліченна кількість варіацій, що значно ускладнює виявлення метаморфічних контрактів.

Крок 5: Метаморфічний байт-код запитує адресу фабрики для реалізації контракту

Метаморфічний байт-код запитує у фабрики адресу контракту про впровадження (як зберігається на кроці 3). Немає значення, якщо адреса Контракту про впровадження зміниться, якщо метаморфічний байт-код, який запитує адресу, залишається незмінним. Дійсно, якщо розробник пізніше розгорне новий контракт на впровадження – наприклад, зловмисний, призначений для викрадення токенів – він обов’язково розгорнеться на іншій адресі блокчейну відповідно до кроку 2. Це не вплине на створення метаморфічного контракту.

Крок 6: Код контракту реалізації копіюється в метаморфічний контракт

Використовуючи адресу блокчейну, отриману на кроці 5, метаморфічний байт-код знаходить код у Контракті реалізації та копіює цей код у локальне сховище Метаморфічного контракту. Ось як Метаморфічний Контракт змінює форму: шляхом копіювання коду з Контракту реалізації. 

Крок 7: Промийте і повторіть

Розробник може повторювати кроки з 1 по 6 знову і знову та замінювати код у Метаморфічному контракті будь-яким завгодно за допомогою нового Договору реалізації. Все, що потрібно, це використати код операції SELFDESTRUCT або, більш підступно, коди операції DELEGATECALL, які зрештою призводять до SELFDESTRUCT, щоб видалити існуючий код у Метаморфічному контракті. Повторюючи цикл із новим байт-кодом Контракту реалізації, Метаморфічний Контракт, як за допомогою магії, морф!

Використовуючи цю техніку для створення метаморфічних контрактів, розумний розробник може постійно змінювати грунт під ногами користувачів web3. Знову розглянемо, наприклад, сценарій шахрайства. Розробник може спочатку розгорнути Контракт на реалізацію з кодом токенстейкінгу, який через окружний шлях, зображений на малюнку та розроблений у наведених вище кроках, завершується в Метаморфічному контракті. Пізніше шахрай може самостійно знищити цей код і замінити його, розгорнувши новий договір про реалізацію, що містить токен-крадіжка Код. 

Все, що буде розгорнуто в Контракті реалізації, зрештою потрапить у Метаморфічний контракт. Ось у чому суть фокусу. 

***

Метаморфічні смарт-контракти порушують неявний соціальний договір web3: те, що ви бачите, те й отримуєте. Подібно до того, як у грі «мушля» використовуються три рухомі чашки, щоб приховати м’яч, взаємодія трьох контрактів у створенні метаморфічного контракту ускладнює визначення справжньої функції контракту. Особливо влучним є порівняння гри в шкаралупу, оскільки шахраї впевненості часто використовують спритність рук і неправильне орієнтування, щоб гарантувати свою перемогу. У версії web3 автори метаморфічних контрактів можуть подібним чином змусити «кулю» – код реалізації, тобто – зникнути (читай: самознищитися), і вони можуть замінити його чим завгодно.

Існування метаморфічних контрактів означає, що користувачі web3 можуть укладати контракти, які можуть змінюватися за бажанням – ось чому цю загрозу так важливо розуміти та захищатися від неї. Мій детектор метаморфічних контрактів пропонує лише перший крок до ідентифікації метаморфічних контрактів за спритністю рук, яку вони використовують. Є кілька способів удосконалення детектора в майбутньому. Наприклад, шляхом рекурсивної перевірки Factory (або контракту розгортача), який створив Metamorphic Contract, можна побачити, чи Factory сама є метаморфічною. Ця функція була б корисним доповненням до оновленої версії 2 детектора.

Варто ще раз повторити: цей інструмент Детектор не надійний. Прапори, які він вловлює, не є яскравими ознаками метаморфічного потенціалу, але вони пропонують підказки. Ідентифікація цих прапорів є лише початком для більш ретельного дослідження. Ось чому ми розширили детектор для пошуку прапорів, які можуть легко генерувати помилкові спрацьовування, як-от наявність кодів операцій CREATE2 або DELEGATECALL. Якщо у вас є пропозиції щодо вдосконалення інструменту або ви бажаєте розвинути чи додати до цієї початкової роботи, зв’яжіться зі мною за .

Проаналізуйте розумні контракти на метаморфічні риси за допомогою інструменту «Детектор». і відвідати GitHub репо більше

Редактор: Роберт Гекетт @rhhackett

***

Подяка: я хочу ВЕЛИЧЕЗНО привітати та подякувати Роберту Гекетту, Едді Лаззаріну, Сему Регсдейлу, Ріязу Файзуллабхою, Ною Сітрону, Мейсону Холу та Деджуну Парку за цінні відгуки та поради щодо втілення цієї публікації та інструменту в життя. 

***

Погляди, висловлені тут, є поглядами окремих співробітників AH Capital Management, LLC («a16z»), які цитуються, і не є поглядами a16z або його філій. Певна інформація, що міститься тут, була отримана зі сторонніх джерел, зокрема від портфельних компаній фондів, якими керує a16z. Хоча отримано з джерел, які вважаються надійними, a16z не перевіряв таку інформацію незалежно та не робить жодних заяв щодо тривалої точності інформації чи її відповідності певній ситуації. Крім того, цей вміст може містити рекламу третіх сторін; a16z не переглядав такі оголошення та не схвалює будь-який рекламний вміст, що міститься в них.

Цей вміст надається лише в інформаційних цілях, і на нього не можна покладатися як на юридичну, ділову, інвестиційну чи податкову консультацію. Ви повинні проконсультуватися з власними радниками щодо цих питань. Посилання на будь-які цінні папери чи цифрові активи наведено лише з метою ілюстрації та не є інвестиційною рекомендацією чи пропозицією надати інвестиційні консультаційні послуги. Крім того, цей вміст не призначений для будь-яких інвесторів чи потенційних інвесторів і не призначений для використання ними, і за жодних обставин на нього не можна покладатися при прийнятті рішення інвестувати в будь-який фонд, яким керує a16z. (Пропозиція інвестувати у фонд a16z буде зроблена лише на підставі меморандуму про приватне розміщення, угоди про підписку та іншої відповідної документації будь-якого такого фонду, і її слід читати повністю.) Будь-які інвестиційні чи портфельні компанії, згадані, згадані або описані не є репрезентативними для всіх інвестицій у транспортні засоби, якими керує a16z, і не може бути гарантії, що інвестиції будуть прибутковими або що інші інвестиції, здійснені в майбутньому, матимуть подібні характеристики чи результати. Список інвестицій, здійснених фондами під управлінням Andreessen Horowitz (за винятком інвестицій, щодо яких емітент не надав дозволу a16z на оприлюднення, а також неоголошених інвестицій у публічні цифрові активи) доступний за адресою https://a16z.com/investments /.

Наведені в ньому діаграми та графіки призначені виключно для інформаційних цілей, і на них не слід покладатися під час прийняття інвестиційних рішень. Минулі результати не вказують на майбутні результати. Зміст відповідає лише вказаній даті. Будь-які прогнози, оцінки, прогнози, цілі, перспективи та/або думки, висловлені в цих матеріалах, можуть бути змінені без попередження та можуть відрізнятися або суперечити думкам, висловленим іншими. Додаткову важливу інформацію можна знайти на сторінці https://a16z.com/disclosures.