Хронологія та рефлексії злому Vyper

«Trust but verify» (довіряй, але перевіряй), не роби «постфактум». Найсерйозніша помилка - це чорний колір під світлом.

Через незмінність контракту проект неявно покладатиметься на код, написаний багато років тому. Коли ми виправляємо помилки, нам потрібно приділяти більше уваги його потенційному впливу.

Цього разу сталося так.

хронологія

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

13:10 UTC pETH/ETH 11 мільйонів доларів [1] дренаж.

13:19 UTC Міхал опублікував на ETHSecurity повідомлення про раптове падіння ціни pETH.

Ігор першим помітив недобре. Завдяки йому ми почали досліджувати далі.

Але як робот повторно вводить add_liquidity() у виклику remove_liquidity()?

14:01 UTC Сформовано групу для вирішення проблеми.

14:07 UTC Ми використовуємо наш улюблений декомпілятор [2] Декомпілювали контракт JPEGd і помітили, що слоти захисту від повторного входу дещо інші.

// Запис таблиці відправлення для add_liquidity(uint256 [2] ,uint256) label_0057: якщо (зберігання [0x00] ) { revert(memory[0x00:0x00]); } зберігання [0x00] = 0x01; // Запис таблиці відправлення для remove_liquidity(uint256,uint256 [2] ) label_1AF3: якщо (зберігання [0x02] ) { revert(memory[0x00:0x00]); } зберігання [0x02] = 0x01;

14:27 UTC Ми підтвердили цю проблему за допомогою простого локального тестового контракту.

@зовнішній @nonreentrant("блокування") def test(addr: адреса) -> bool: повертає True @зовнішній @nonreentrant("блокування") def test2(addr: адреса) -> bool: повернути False

Це не просто чергова помилка повторного входу.

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

14:37 UTC Wavey допоміг визначити вразливий комміт і вражену версію. Ми з Чарльзом також підтвердили це, вручну перевіривши вихід компілятора Vyper.

Це змагання з хакерами.

На щастя, люди також плутають це з повторним входом лише для читання. Уривок із каналу сповіщень безпеки Web3 - Alchemix і Metronome DAO також зламано через помилку повторного входу лише для читання [3]

Майкл також виявив потенційні вразливості в пулах alETH і msETH, на яких працює версія 0.2.15.

14:50 UTC msETH/ETH вичерпано [4] .

15:34 UTC alETH/ETH вичерпано [5] .

15:43 UTC Ми знайшли вразливість у CRV/ETH, скомпільованому за допомогою Vyper версії 0.3.0 [6] . Дуже важливо, щоб ми якомога довше зберігали конфіденційність уражених контрактів.

16:11 UTC Ми починаємо працювати над уразливими місцями білого капелюха.

На жаль, занадто багато організацій проводять незалежні дослідження одночасно, і про це ходить маса чуток. О 16:44 UTC ми вирішили зробити публічну заяву щодо ураженої версії [7] .

Станом на 18:32 UTC у нас був перевірений експлойт, який можна було використати для потенційного порятунку. Bpak Chainlight також працює над уразливістю в той же час і поділився нею о 19:06 UTC.

Через п'ять хвилин, о 19:11 UTC, хтось викрав кошти [8] .

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

І все ж таки є багато роботи.

21:26 UTC Еддісон запропонував амбітний план зберегти залишки активів у пулі CRVETH.

Якщо ви надсилаєте 30 тис. crv до пулу crv/eth, Ви можете оновити плату адміністратора потім встановіть ставку crv/eth близько 0,15 eth за crv В основному можна видобути всі сотні K crv у пулі

21:52 UTC bpak зробив робочий доказ концепції, який може заощадити 3100 ETH.

Через десять хвилин, о 22:02 UTC, ми знову зазнали поразки. Дивно, але CRV керує витратними роботами [9] Кошти вилучено, басейн осушено [10] .

звинувачувати

звинуватити (Balme) - сильне слово. Показувати пальцями марно. Я вважаю, що корисно подумати про те, що можна зробити краще.

Конкурс

Зусилля «Білого капелюха» були розгромлені менш ніж за півгодини. Іноді кожна секунда на рахунку.

Можливо, ці атаки можна було здійснити за кращої підготовки та ресурсів. Водночас це виглядає як палиця з двома кінцями. Чи це справді гарна ідея зібрати разом інформацію про те, як виконати хак? Кому довіряти?

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

Розкриття інформації

Я і аудитор, і хакер у білому капелюсі.

Індустрія аудиту має унікальну видавничу культуру. Нам платять за наше технічне лідерство та глибоке розуміння вразливостей. Один із способів продемонструвати своє лідерство та глибину – опублікувати [11] «Совок» про хакерство. Дослідники коштують дорого, а окупність інвестицій — це реклама.

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

Якби це було додаткові півгодини, можна було б заощадити 18 мільйонів доларів.

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

Наступний крок

Я не погоджуюся з «нам потрібна формальна перевірка, щоб вирішити цю проблему» тощо. Цю помилку можна виявити за допомогою модульного тестування. Формальна перевірка дуже корисна для багатьох типів помилок, але я не вірю, що вона настільки ж корисна для відносно простих компіляторів, які не оптимізуються.

Зверніть увагу, що цю помилку було виправлено в листопаді 2021 року [12] .

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

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