Експлойт, з яким Curve зіткнувся цього разу, може відкрити для хакерів нові ідеї

Від Jaleel, BlockBeats

Індустрія DeFi поринула в хаос після інциденту з використанням уразливості. Curve Finance, гігант індустрії DeFi, став об’єктом серйозної «атаки», і під загрозою опинилися численні пули стейблкойнів, такі як alETH/msETH/pETH. Згідно з неповною статистикою, подія використання вразливості спричинила загальну втрату в 52 мільйони доларів США в пулах Alchemix, JPEG'd, MetronomeDAO, deBridge, Ellipsis і CRV/ETH, і довіра всього ринку серйозно похитнулася.

Блокування повторного входу версій Vyper 0.2.15, 0.2.16 і 0.3.0 недійсні, і офіційний інтерфейс встановлення документів Vyper рекомендує неправильну версію. Інші учасники проекту, які використовують компілятор Vyper, також поспішили провести самоперевірку, намагаючись переконатися, що вони не стануть наступною жертвою. У міру того, як джерело інциденту використання вразливості поступово розкривається, ринок поступово усвідомлює, що ця криза означає не лише звичайний інцидент використання хакерів, але також розкриває потенційний величезний ризик усього основного стеку для всієї індустрії DeFi.

У порівнянні з минулим, хакерських інцидентів за попередній період стало все менше і менше, що невіддільно від процвітання ринку. Протягом літа DeFi та літа NFT щотижня запускалися нові угоди на мільярд доларів, порівняно з сьогоднішнім ринком, який дуже скорочується. У той же час ринкові можливості хакерів для пошуку експлойтів або створення великомасштабних атак поступово звужуються, а це означає, що хакерам потрібні нові, невикористані точки входу для дослідження.

Хакери, які повертаються до «перших принципів», знайшли ідеальну точку входу на компіляторі нижчого рівня, щоб з’їсти величезний і смачний «пиріг» на ринку DeFi. Компілятор нижчого рівня став більш «розумним» хакером. Вибір. BlockBeats опитав розробника смарт-контрактів Box (@BoxMrChen) і дослідника BTX Дерека (@begas_btxcap) про цей інцидент і пов’язані з ним проблеми.

Як відбувається подія Curve?

Стані (@StaniKulechov), засновник Aave та Lens, висловив свою точку зору щодо інциденту в соціальних мережах: «Це прикра невдача для Curve та DeFi. Хоча DeFi є відкритим простором, який може внести свій внесок, він повинен зробити це абсолютно правильно. це важко, і ставки високі. У випадку Curve вони зробили все правильно на рівні протоколу».

Експлойт, від якого постраждала Curve, є однією з найстаріших і, можливо, найпоширенішої форми атаки на смарт-контракти Ethereum, атаки повторного входу. Атаки повторного входу дозволяють зловмиснику неодноразово викликати функцію смарт-контракту, не чекаючи завершення попереднього виклику цієї функції. Таким чином вони можуть продовжувати використовувати лазівку для виведення коштів, доки не закінчаться кошти в контракті жертви.

Повторне блокування та принцип CEI

Наведіть простий приклад для ілюстрації повторних атак: у банку є загалом 100 000 готівки. Але в цьому банку є велика лазівка: щоразу, коли люди знімають гроші, співробітники банку не оновлюють баланс рахунку відразу, а чекають до кінця дня, щоб перевірити та оновити його. У цей час хтось виявив цю лазівку. Він відкрив рахунок у банку, спочатку вніс 1000 юанів, потім зняв 1000 юанів, а потім взяв 1000 юанів через 5 хвилин. Оскільки банк не оновлює баланс у режимі реального часу, система вважатиме, що на його рахунку все ще є 1000 юанів перед перевіркою та оновленням. Завдяки повторним операціям користувач нарешті забрав у банку всю готівку в розмірі 100 000 доларів США. Лише наприкінці дня банк виявив, що лазівкою скористалися.

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

Solidity встановлює «принцип CEI» (Check Effects Interactions) для програмування смарт-контрактів, який може добре захистити функції від атак повторного входу. Зміст принципів CEI включає:

1. Порядок виклику функціональних компонентів має бути таким: по-перше, інспекція, по-друге, вплив на змінні стану, і останнє, взаємодія із зовнішніми об’єктами.

2. Перед взаємодією із зовнішніми об'єктами всі змінні стану повинні бути оновлені. Це називається «оптимістична бухгалтерія», де ефекти записуються до того, як взаємодія фактично відбулася.

3. На початку функції необхідно перевірити, чи має об’єкт, що викликає, дозвіл на виклик функції.

4. Змінні стану слід оновлювати перед будь-якими зовнішніми викликами, щоб запобігти атакам повторного входу.

5. Навіть довірені зовнішні організації повинні слідувати шаблону CEI, оскільки вони можуть передати потік керування зловмисним третім особам.

Згідно з документацією, принципи CEI допомагають обмежити поверхню атаки контракту, зокрема запобігаючи атакам повторного входу. Принципи CEI можуть бути легко застосовані, головним чином у порядку функціональних кодів, без зміни логіки. Відомий експлойт The DAO, який призвів до розгалуження Ethereum, також проігнорував «принцип CEI», і зловмисник здійснив атаку повторного входу, що спричинило руйнівні наслідки.

Але пул Curve, який був атакований, не дотримувався цього принципу CEI, оскільки Curve використовував компілятор Vyper. Через вразливість коду Vyper компілятора блокування повторного входу не вдається, що робить атаку хакера повторного входу успішною.

Більшість людей знають Solidity, але Solidity — не єдина мова для створення смарт-контрактів, популярною альтернативою Solidity є Vyper. Хоча Vyper не такий потужний і популярний, як Solidity, він ідеально підходить для розробників, які знайомі з Python, оскільки Vyper може перекладати Python-подібний код на мову програмування смарт-контрактів Ethereum.

Згідно з інформацією github, розробник, який першим зробив внесок у базу коду github Vyper, також є розробником Curve. Неважко пояснити, чому Curve використовує Vyper замість Solidity.

![Хакери повертаються до «перших принципів», криза Curve — це не звичайна атака] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-c30cf03f91-dd1a6f-1c6801)

Чому блокування повторного входу Vyper не працює?

Тож у чому проблема Vyper у цій атаці? Чому блокування повторного доступу не працює? Це тому, що тестів немає? BlockBeats опитав розробника смарт-контрактів Box 826.eth (@BoxMrChen), за його словами, реентерабельне блокування Vyper було протестовано з випадками використання. Але причина невдачі полягає в тому, що тестовий приклад орієнтований на результат, тобто тестовий приклад теж неправильний.

Коротше кажучи, найбільша причина, чому блокування повторного входу Vyper дає збій, полягає в тому, що особа, яка написала тестовий приклад, написала тестовий приклад на основі результату, не замислюючись про те, чому слот пропустив 1 незрозумілим чином.

![Хакери повертаються до «перших принципів», криза Curve — це не звичайна атака] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-0527942e35-dd1a6f-1c6801)

У наступних параграфах коду Vyper, яким поділився Box, можна чітко побачити проблему. Коли ім’я блокування з’являється вдруге, номер пам’яті_slot буде перезаписано, тобто, у ret, слот для першого отримання блокування дорівнює 0, але після того, як функція знову використовує блокування, слот для замка додається один. Після компіляції використовується неправильний слот, через що блокування повторного входу не діє.

![Хакери повертаються до «перших принципів», криза Curve — це не звичайна атака] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-87ec9b545c-dd1a6f-1c6801)

Зліва – атакований код, а справа – відремонтований код

«Очікуються неправильні результати тесту, і, звісно, жодні помилки не можуть бути підтверджені. Щоб навести простий приклад, ми зараз виконуємо задачу обчислення, 1+ 1 = 2, але дана стандартна відповідь неправильна, кажучи, що 1+ 1 = 3 .І це однокласник, який ставив запитання, дав неправильну відповідь і відповів 1+ 1 = 3, але це було так само, як стандартна відповідь, надана заздалегідь, тому програма, природно, не мала можливості визначити, що результат тесту був неправильно", - сказав Бокс в інтерв'ю BlockBeats.

Висіть два роки "Дамоклів меч"

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

Щоб отримати поглиблене розуміння редактора Vyper, BlockBeats опитав дослідника BTX Дерека (@begas_btxcap), який сказав, що для розробників, які знайомі з Python, Vyper є більш ідеальним вибором, ніж Solidity, із більш зручним інтерфейсом користувача. і швидше навчатися. Але, очевидно, деякі версії коду редактора Vyper не були перевірені надійною третьою стороною. Навіть певну аудиторську роботу можуть виконувати самі розробники. «Такого не станеться в традиційній ІТ-індустрії, тому що після появи нової мови незліченна кількість аудиторських компаній шукатиме ваші лазівки».

Не кажучи вже про те, що дозволити багу відкрито існувати протягом двох років.

Дописувач Vyper fubuloubu також сказав: компілятор не такий перевірений чи перевірений, як усі думають. Більшість компіляторів мають значні та часті зміни, що робить аудит недоліком. Навіть із повним аудитом кодової бази він застаріє, чим більше версій буде додано після цього. Аудит компілятора не є гарною ідеєю, тому що має сенс перевірити кінцевий продукт (тобто необроблений код EVM), створений кінцевим користувачем за допомогою інструменту.

Усе це вказує на останню проблему: мотивацію. Тим не менш, ніхто не має стимулу знаходити критичні помилки в компіляторах, особливо в старих версіях. fubuloubu раніше робив пропозицію, яка допоможе покращити Vyper шляхом додавання програми баунті, спільно спонсорованої користувачами, але вона не пройшла.

Хакери повертаються до «перших принципів»

Це ще один живий приклад безпечних контрактів практик розробки для розробників протоколів і проектів. Але найважливіше те, що інцидент із Curve попередив усіх нас про те, що безпека основного компілятора була серйозно проігнорована, і хакери, які повернулися до «перших принципів», знайшли ідеальний компілятор на нижчому компіляторі.

Після цього Стані (@StaniKulechov), засновник Aave та Lens, також опублікував велику статтю в соціальних мережах, щоб висловити свої почуття: «Атака на Curve означає, що ризик DeFi завжди включав увесь базовий стек, мову програмування, EVM і т.д. Це застерігає нас бути більш обережними та делікатними, особливо під час використання спеціальних EVM та ланцюжків додатків у майбутньому.

![Хакери повертаються до «перших принципів», криза Curve — це не звичайна атака] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-3324fcfbcd-dd1a6f-1c6801)

Атаки з нижчого рівня

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

«Наразі лише два компілятори є найкращими, база коду Vyper менша, легша для читання та має менше змін для аналізу своєї історії, тому, ймовірно, хакери починають тут, база коду Solidity трохи більша», — fubuloubu навіть підозрює, що стан- підтримані хакери можуть бути залучені до цієї атаки Curve: «Потрібні будуть тижні або місяці, щоб знайти вразливість, і, враховуючи вкладені ресурси, це може бути здійснено невеликою групою або командою».

Безпека Solidity, яка є найпоширенішою мовою компіляції в індустрії шифрування, ще більше стурбована користувачами. Зрештою, якщо цього разу компілятор Solidity має проблему збою блокування повторного входу, то історія всієї індустрії DeFi може мати бути переписаним.

Відповідно до сповіщень безпеки, які регулярно випускаються командою розробників Solidity, у багатьох різних версіях компілятора Solidity були вразливості системи безпеки.

Остання помилка компілятора була зареєстрована 26 червня під час дослідження звіту про безпеку, пов’язаного з використанням помилки abi. Старий генератор коду не обчислював складні вирази, як-от призначення, виклики функцій або умови, до .selector яких зверталися. Це спричиняє побічні ефекти, коли такі вирази не виконуються, тому контракти, скомпільовані за допомогою старого конвеєра, можуть поводитися некоректно.

Ми також можемо побачити файл у репозиторії Github Solidity, який містить список деяких відомих помилок, пов’язаних із безпекою компілятора Solidity. Список повертається до версії 0.3.0, помилки, які існували лише до цієї версії, не перераховані. Тут є інший файл bugs_by_version.json. Цей файл можна використовувати для запиту про помилки, на які впливає певна версія компілятора.

На щастя, саме завдяки широкому застосуванню мови Solidity та допомозі Фонду Ethereum багато існуючих проблем були виявлені проектами та протоколами під час процесу розгортання. Таким чином, Solidity завершила модифікацію та вдосконалення на кілька кроків швидше, ніж Vyper.З цієї точки зору, це одна з причин, чому Solidity є більш стандартизованою та безпечнішою.

Щоб допомогти розробникам Solidity краще тестувати та запобігти подібним випадкам. Співзасновник UnitasProtocol SunSec (@ 1 nf 0 s 3 cpt) випустив посібник з тестування безпеки DeFiVulnLabs Solidity після атаки Curve, який підтримує 47 типів уразливостей, включаючи описи вразливостей, сценарії, засоби захисту, коди вразливостей, заходи пом’якшення та способи тестування .

Як максимально уникнути атак низького рівня?

У цьому випадку з Curve Бокс вважає, що просвітленням для всіх розробників є: не намагайтеся слідувати технологічним трендам і вибирати незрілі рішення; не затверджуйте свій власний код, не написавши тестових випадків (кілька версій Vyper, які мають проблеми, навіть тестові випадки неправильні); ніколи не затверджуйте свій власний код самостійно; для відкриття деяких багатств можуть знадобитися роки; відсутність можливості оновлення означає зарозумілість щодо себе та зневагу до інших.

Зазвичай розробники не думають про жодні підводні камені, а вибирають версію для компіляції навмання, що може ігнорувати ризики, пов’язані з відмінностями між версіями. Навіть незначні оновлення версій можуть внести критичні зміни, що особливо важливо при розробці децентралізованих програм.

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

Крім того, модульні тести для завершення коду. Більшість помилок на рівні компілятора призведуть до непослідовних результатів виконання коду, які важко знайти лише за допомогою перегляду коду, але можуть бути виявлені під час тестування. Покращення покриття коду може допомогти уникнути таких проблем. І намагайтеся уникати використання складних мовних функцій, таких як вбудоване складання та кодування та декодування багатовимірних масивів, якщо немає явної потреби. Більшість уразливостей мови Solidity історично були пов’язані з цими розширеними функціями. Розробникам слід уникати використання експериментальних мовних функцій заради демонстрації без особливої потреби.

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

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