Аналіз поширених методів атак у сфері Web3 за першу половину 2022 року

У першій половині 2022 року ситуація з безпекою в галузі Web3 залишалася серйозною. У цій статті буде глибоко проаналізовано поширені способи атак у цей період, розглянуто їх частоту та заходи запобігання.

Огляд збитків, спричинених вразливостями

Згідно з даними платформи моніторингу безпеки блокчейну, у першій половині 2022 року сталося 42 основних випадків атак на вразливості контрактів, що становить близько 53% від усіх атак. Загальні збитки від цих атак сягнули 644 мільйонів доларів.

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

Аналіз подій великих втрат

Подія атаки на міст Wormhole між ланцюгами

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

Подія атаки Fei Protocol

30 квітня 2022 року пул Rari Fuse під егідою Fei Protocol зазнав атаки через миттєвий кредит і повторний вхід, що призвело до збитків у 80,34 мільйона доларів. Ця атака завдала смертельного удару проекту, в результаті чого 20 серпня проект оголосив про закриття.

Зловмисники в основному використали вразливість повторного входу, що існує в контракті cEther реалізації Rari Capital. Процес атаки виглядає наступним чином:

1. Зловмисник отримуєflash-кредит від Balancer.
2. Використання коштів швидкого кредиту для заставного кредитування в Rari Capital, одночасно використовуючи вразливість повторного входу.
3. Використовуючи функцію атаки зворотного виклику, витягніть всі токени з ураженого пулу.
4. Повернення миттєвого кредиту, перенесення отриманого від атаки.

Типові уразливості під час аудиту

1. Атака повторного входу ERC721/ERC1155:
   • Використання функції сповіщення про переказ у стандарті для атаки повторного введення
   • Бізнес-функція не дотримувалася строго режиму перевірки - дії - взаємодії

2. Логічна помилка:
   • Неповне врахування особливих обставин, таких як самопереказ, що призводить до безпідставного збільшення токенів
   • Дизайн функцій недостатньо розроблений, наприклад, відсутні механізми вилучення або ліквідації

3. Відсутність автентифікації:
   • Ключові функції (такі як карбування, налаштування персонажів) не мають контролю доступу

4. Маніпуляція цінами:
   • Неправильне використання або відсутність оракула
   • Використовуйте пропорцію залишку токенів у контракті безпосередньо як цінову основу

Використання вразливостей у реальних атаках

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

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