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

Отже, ось що трапилося 22 березня. Resolv, протокол DeFi, який пройшов 18 перевірок безпеки, був зламаний. Але не через помилку в смарт-контракті. Замість цього, зловмисники отримали доступ до їхнього середовища AWS KMS, де протокол зберігав свої привілейовані ключі підпису. Звідти атака була майже надзвичайно простою: вони створили 80 мільйонів нестабільних USR-стейбкоїнів без забезпечення і вивели близько 25 мільйонів доларів у цінності, поки ніхто не зміг їх зупинити.

Механізми варто зрозуміти, оскільки вони виявляють фундаментальний недолік у дизайні. Процес створення USR Resolv не був повністю на ланцюгу. Коли користувачі хотіли створити USR, вони вносили USDC через requestSwap, тоді офф-чейн сервіс, контрольований приватним ключем, авторизовував фактичну кількість створення через completeSwap. Сам смарт-контракт не мав верхньої межі на створення — він лише перевіряв, чи підпис дійсний. Саме ця вразливість і є проблемою.

Зловмисники внесли, можливо, 100-200 тисяч доларів у USDC у кількох транзакціях. Потім вони використали зламаний ключ підпису для авторизації створення 50 мільйонів USR в одній транзакції, а потім ще 30 мільйонів — в іншій. Дві транзакції, 80 мільйонів токенів, майже без реального забезпечення. Звідти вони конвертували у wstUSR (стейкінговий дериватив), обміняли на інші стабільні монети, перекинули на ETH і зникли з приблизно 24 мільйонами доларів у ETH та деякими залишковими позиціями.

Що дивує — це вплив на ринок. USR обвалився на 80%, коли це сталося — до 0,20 долара, а потім відновився до приблизно 0,56 долара. Протокол був змушений негайно призупинити всі операції. І ось що справді виділяється: весь цей напад розгорнувся за кілька хвилин. До того, як хтось помітив, що щось не так, шкода вже була нанесена.

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

У статті згадується, як системи моніторингу могли б це зловити. Якби існувало правило, яке сповіщало б про перевищення нормального співвідношення створення токенів у 1.5 рази, ці дві величезні транзакції були б миттєво позначені. Або якби існувала автоматична функція паузи, прив’язана до незвичних подій створення, протокол міг би зупинити кровотечу до того, як 80 мільйонів токенів потрапили на ринок.

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