Автор: Артела Китайський блог, середній# Анотація

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

«Захист під час виконання» є важливим доповненням до безпеки DeFi. Він спрямований на «захист результатів виконання» та забезпечення відповідності виконання протоколу його очікуваному дизайну

Конструкція EVM не підтримує «захист під час виконання», оскільки смарт-контракт не може отримати доступ до повної контекстної інформації про стан виконання

Artela досліджує парадигму рівня виконання EVM+Extension, вдосконалює рівень виконання, щоб усунути атаки повторного входу

Artela реалізує в ланцюжку розширення «захист під час виконання» за допомогою аспектного програмування

Ми крок за кроком показуємо, як запобігти атакам повторного входу на контракт Curve через Aspect

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

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

Атака Curve Finance (липень 2023 р.) — Curve зазнала атаки повторного входу на суму 60 мільйонів доларів через помилку компіляції в її контрактній мові програмування Vyper.

Атака на протокол Origin (листопад 2022 р.) — Проект стейблкойнів Origin Dollar (OUSD) вартістю 7 мільйонів доларів США зазнав атаки повторного входу.

Атака на протокол Siren (вересень 2021 р.) — 3,5 мільйона доларів, пул AMM зазнає атаки повторного входу.

Атака Cream Finance (серпень 2021 р.) – 18,8 млн доларів, зловмисники використали вразливість повторного входу для вторинного запозичення.

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

Цей підхід, відомий як рішення «білої скриньки», має на меті уникнути вразливостей на рівні вихідного коду, щоб мінімізувати логічні помилки. Однак його головний виклик – нездатність захиститися від невідомих прихованих небезпек.

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

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

Нам потрібен захист під час виконання

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

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

Проблеми впровадження захисту під час виконання

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

Як подолати цей виклик? Ми вважаємо, що необхідні такі передумови:

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

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

Переконайтеся, що функціональні можливості модуля набувають чинності після виконання смарт-контракту та до подання стану.

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

Ідея Artela полягає в тому, що EVM + власне розширення, створюючи власний рівень розширення WASM EVM, щоб реалізувати вихід за межі EVM.

Введення в аспектне програмування

Ми запустили Aspect Programming, структуру програмування для блокчейну Artela, яка підтримує власне масштабування в блокчейні.

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

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

Як Aspect Programming реалізує захист під час виконання

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

Аспект реалізує ключові властивості для захисту під час виконання:

Можна активувати після виконання смарт-контракту та перед поданням стану: модулі аспектів можна налаштувати для активації після виконання смарт-контракту, але до подання стану.

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

Можливість системного виклику: Aspect може здійснювати системні виклики та за необхідності ініціювати відновлення транзакцій.

Зв’язування та авторизація за допомогою смарт-контрактів: смарт-контракти можна прив’язувати до Aspect і надавати Aspect дозвіл на участь в обробці транзакцій.

Реалізація Aspect для захисту від повторного входу

У цьому розділі ми обговорюємо, як реалізувати захист часу виконання Aspect у ланцюжку.

Фактичний аспект «Намір захисту контракту» можна розгорнути в точці з’єднання «preContractCall» і «postContractCall», щоб запобігти атакам повторного входу.

preContractCall: запускається перед виконанням виклику перехресного контракту

postContractCall: запускається після виконання виклику перехресного контракту

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

У точці «preContractCall» Aspect відстежує стек викликів контракту. Якщо в стеку викликів є дублікати викликів (це означає несподіваний повторний вхід у наш заблокований виклик), аспект відкочує виклик.

Розгорніть контракт Curve і запобігте атакам повторного входу

Ми написали імітаційний контракт Curve і створили атаку повторного входу, щоб відтворити цей процес більш зрозумілим способом. Код контракту такий:

Можна побачити, що як add_liquidity, так і remove_liquidity вищезазначеного контракту захищено одним блокуванням блокування повторного входу, що означає, що якщо захист повторного входу працює нормально, захищену функцію не можна повторно ввести шляхом зміни блокування (наприклад, у Remove _liquidity викликає add_liquidity).

Зкомпілюйте наведений вище контракт за допомогою компілятора vyper 0.2.15, 0.2.16 або 0.3.0 (у цих версіях є відомі проблеми із захистом від повторного входу).

Потім ми розгортаємо вищезгаданий контракт жертви та атакуємо його за допомогою такого контракту:

Щоб імітувати фактичну атаку, метод атаки цього контракту намагається повторно ввести add_liquidity з методу remove_liquidity через свою резервну функцію. Якщо повторне входження дійсно відбувається, у квитанції можна спостерігати, що подія AddLiquidity реєструється перед подією RemoveLiquidity.

Тепер давайте використаємо Aspect для захисту контракту під час атаки. Перш ніж робити наступне, виконайте такі кроки:

1. Розгорніть аспект

2. Зв'яжіть жертву з Aspect

Якщо ви не знайомі з операціями Aspect, ви можете спочатку переглянути наш посібник для розробників.

Зробивши вищезазначене, давайте спробуємо знову викликати метод атаки, щоб перевірити, чи буде операція успішною.

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

на закінчення

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

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

Ми роздвоїли контракт Curve і повністю змоделювали його недавню атаку повторного входу, а також відтворили весь процес більш зрозумілим способом. Використовуючи аспектне програмування як новий підхід до захисту on-chain під час виконання, ми крок за кроком показуємо, як захистити контракти жертв за допомогою аспектів. Наша мета — допомогти викорінити атаки повторного входу, від яких можуть постраждати протоколи DeFi, такі як Curve, тим самим підвищивши безпеку в усьому просторі DeFi.

Завдяки аспектному програмуванню розробники можуть не тільки досягти захисту on-chain під час виконання в просторі безпеки, але й увімкнути безпрецедентні інноваційні випадки використання, такі як наміри, JIT і on-chain автоматизація. Крім того, цей загальний фреймворк, заснований на Cosmos SDK, не тільки підтримуватиме блокчейн Artela, але й підтримуватиме інші блокчейни для створення власних розширень на основі їхніх власних рівнів виконання.