Огляд та роздуми про акцію екстреної допомоги Web3

18 січня 2022 року наша система моніторингу аномальних транзакцій виявила атаку на проект AnySwap (, а саме Multichain ). Через вразливість функції anySwapOutUnderlyingWithPermit() токени, надані користувачем цьому проекту, можуть бути вкрадені зловмисниками.

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

Враховуючи, що атака все ще триває, команда BlockSec вирішила вжити заходів реагування на надзвичайні ситуації для захисту потенційних жертв. Ми зосередилися на рахунках, які були під впливом на Ethereum, і перевели відповідні кошти на спеціально створений мультипідписний рахунок білих капелюхів. Щоб забезпечити прозорість дій, ми плануємо оприлюднити хеш документа плану ( без змісту ) для громади, що дозволить відрізнити наші дії від дій нападників та не розкривати деталі. Операція порятунку розпочалася 21 січня 2022 року і закінчилася 11 березня.

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

Короткий підсумок

• Широке використання Flashbots призвело до жорсткої конкуренції між білими капелюшками та атакуючими, а також всередині кожної з цих груп, витрати на оплату також швидко зростали з часом.

• Flashbots не є універсальними, деякі зловмисники переходять на використання mempool, майстерно організовуючи атаки для успішного виконання атак.

• Деякі зловмисники уклали угоду з проєктом, повернувши частину доходу та залишивши частину як винагороду, що дозволило їм успішно "відмити" свої доходи. Цей підхід викликав суперечки в спільноті.

• Білий капелюх може діяти відкрито перед спільнотою без розкриття конфіденційної інформації, такий спосіб завоювання довіри є ефективним.

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

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

Огляд ситуації з атаками та порятунком

Загальний результат

Ми спостерігали в період з 18 січня 2022 року по 20 березня 2022 року. Загальна ситуація така:

• 9 рятувальних рахунків захистили 483.027693 ETH, з яких сплачено за послуги Flashbots 295.970554 ETH( складає 61.27%)
• 21 атакуючих рахунків отримали прибуток 1433.092224 ETH, сплативши комісії Flashbots 148.903707 ETH( становить 10.39%)

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

!

Тренди зміни витрат Flashbots

Білі капелюхи повинні змагатися з нападниками, надсилаючи Flashbots-транзакції для реалізації рятування, сплачені збори відображають рівень конкуренції. Ми підрахували частку витрат Flashbots на атаки та рятувальні транзакції за блоками транзакцій.

Спочатку деякі атаки на транзакції Flashbots мали плату 0, що свідчить про те, що зловмисники ще не використовували Flashbots. Пізніше частка плати швидко зросла, в деяких блоках досягнувши 80% і 91%. Це свідчить про те, що це перетворилося на гонку озброєнь за плату за право запису на Flashbots.

!

Ми реалізували рятувальні акції та стикнулися з викликами

Основні ідеї рятувальної операції

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

1. Ефективне позиціонування переказу на рахунок жертви транзакції ( переказу )
2. Коректно побудувати та реалізувати угоду порятунку ( угода порятунку )
3. Успішне випередження атаки з боку зловмисника ( або інших третіх осіб ) у торгах ( атакуючих торгів )

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

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

Конкуренція

Ми намагалися захистити 171 незалежний потенційний рахунок жертви. З них 10 своєчасно відкликали авторизацію для самозахисту, а серед решти 161 ми змогли врятувати лише 14. Ситуації невдачі стосуються 3 рахунків для порятунку та 16 рахунків нападників.

!

Уроки та досвід

Налаштування зборів Flashbots

Під час рятувальної операції нас 12 разів перемагали інші конкуренти, включаючи 2 рятувальні рахунки та 10 атакуючих рахунків.

Наша стратегія є досить обережною, ми схиляємось до встановлення нижчих витрат на Flashbots, щоб захистити інтереси жертв. Якщо не з'являться успішні атаки з використанням Flashbots, ми не будемо активно використовувати або підвищувати витрати. Однак така стратегія виявилася не надто ефективною, противники зазвичай є більш агресивними:

• Деякий атакуючий встановив частку витрат на 70%
• Один білий капелюх встановив співвідношення витрат на 79%, 80%
• Інший білий капелюшок встановив частку витрат на 81%
• Зловмисник потім підвищив частку витрат до 86%

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

!

Сортування транзакцій Mempool

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

Деякий зловмисник скористався цією стратегією, щоб успішно отримати 312 ETH, і при цьому не потрібно сплачувати комісії Flashbots. Наприклад:

• Блок 14051020: Транзакція жертви знаходиться на 65, транзакція атаки на 66
• Блок 14052155: Транзакція жертви знаходиться на 161, атакуюча транзакція знаходиться на 164

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

!

Інші роздуми

Визначення білого капелюха та атакуючого

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

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

Конкуренція білих капелюхів

Спільноті необхідно встановити механізм координації, щоб зменшити конкуренцію між білими капелюхами. Ця конкуренція не лише витрачає ресурси, але й підвищує витрати на порятунок. Наприклад, ми з іншими трьома організаціями білих капелюхів одночасно намагалися захистити 54 жертви (, що стосувалося 450 ETH). Без механізму координації білим капелюхам важко відмовитися або зупинити цю конкуренцію.

Поліпшення рятувальних дій

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

2. Усі сторони громади можуть співпрацювати для підвищення ефективності рятувальних операцій:

   • Flashbots/Майнери надають зелений коридор для надійних білих капелюхів
   • Проектна сторона несе витрати Flashbots
   • Проектна команда використовує зручніший механізм попередження користувачів
   • Команда проекту додала надзвичайні заходи в код

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

!