В этом блоге мы хотим рассмотреть весь процесс взлома Poly Network и обсудить извлеченные уроки.
Мы узнали, что Poly Network была взломана 10 августа 2021 года (в этом блоге мы используем часовой пояс +8). Однако не было никаких зацепок о том, как произошел взлом и в чем его первопричина. Как команда исследователей безопасности, мы начали свое расследование.
Шаг 1: Поиск транзакции атаки
Мы воспроизвели транзакцию атаки 0xd8c1f7424593ddba11a0e072b61082bf3d931583cb75f7843fc2a8685d20033a в нашей системе виртуализации транзакций (https://tx.blocksecteam.com).
След (trace) довольно простой, что отличает его от других атак, манипулирующих ценой. Обычно они содержат очень сложные вызовы функций (см. взлом Popsicle).
Шаг 2: Анализ кода контракта
Получив след атаки, нам нужно было изучить исходный код контракта. Удивительно, но у Poly Network НЕ было верифицированного исходного кода на Etherscan. Однако нам удалось найти опубликованный исходный код на GitHub.
Изучив исходный код, мы не обнаружили никаких очевидных уязвимостей. Мы также сравнили след атаки со следом легитимной транзакции и обнаружили, что они похожи.
Шаг 3: Восстановление критических состояний
Затем мы восстановили критические состояния во время атаки. Поскольку атака была запущена вызовом VerifyHeaderAndExecuteTxEvent, мы восстановили несколько критических значений переменных, которыми поделились в нашем первом анализе [1].
В процессе этого мы обнаружили, что существует только один хранитель (см. рисунок выше). Поскольку значение было получено из следа атаки, а транзакция атаки прошла все проверки подписей, мы подумали, что потенциальной причиной может быть утечка закрытого ключа или ошибка в процессе подписи на сервере [1].
Однако здесь мы допустили ошибку. Анализ атаки похож на очистку луковицы. Вы снимаете слой за слоем, пока не найдете настоящую «коренную» причину. В то время мы не стали углубляться дальше, чтобы проверить, был ли изменен хранитель!
Шаг 4: Новая зацепка
Спустя несколько часов Келвин и SlowMist предоставили новые зацепки в Twitter, показав, что хранитель был изменен. Процесс изменения использует коллизию хеша для вызова мощной функции — «умный» взлом.
Теперь мы поняли, что наш первый анализ был неполным. Основываясь на последней информации, мы воспроизвели транзакцию, которая изменила хранителя. След по-прежнему был очень простым.
Но помните, что во время этой транзакции было четыре хранителя (вместо одного). Все эти ключи такие же, как и в других легитимных транзакциях, что означает, что ключи подлинные. Возникает вопрос: почему транзакция, которая меняет хранителя, вообще могла быть добавлена в цепочку и исполнена?
Шаг 5: Поиск исходной транзакции
Затем мы попытались найти исходную транзакцию, так как Poly Network — это кросс-чейн мост. Где-то должна существовать исходная транзакция. Мы сделали это, декодировав критическую переменную (как показано на рисунке ниже). Она показывает хеш транзакции в исходной сети и в сети Poly.
Есть один нюанс, о котором больше нигде не упоминалось. Значение хеша транзакции в переменной имеет другое представление по сравнению с официальным значением в сети Poly. Например, хеш транзакции Poly chain на рисунке — 0x80cc978479eb082e1e656993c63dee7a5d08a00dc2b2aab88bc0e465cfa0721a. Но в обозревателе Poly chain значение хеша — 1a72a0cf65e4c08bb8aab2c20da0085d7aee3dc69369651e2e08eb798497cc80 (видите разницу?). Мы поделились своими выводами в Telegram-группе EthereumSecurity 11 августа в 16:55.
Шаг 6: Поиск первопричины
Но мы по-прежнему не могли ответить на вопрос: «почему транзакция по смене хранителя» могла быть упакована в блок? Чтобы ответить на этот вопрос, мы начали с сети Ontology и нашли поток транзакций:
Транзакция Ontology -> Релеер Ontology -> Цепочка Poly -> Релеер Ethereum -> Ethereum
Затем мы прочитали исходный код цепочки Ontology и релееров. Через пару часов мы обнаружили, что релеер Ontology не имеет достаточной проверки для кросс-чейн транзакций. Это позволило вредоносной транзакции попасть в цепочку Poly. После этого система была взломана.
После внутреннего обсуждения и проверки мы опубликовали свои выводы 12 августа в 02:41 в Twitter и на Medium [3].
Уроки
-
Безопасность как принцип проектирования. Безопасность должна присутствовать на всех этапах работы DeFi-проекта. Пользователи доверяют проекту свои деньги. В свою очередь, проект должен оправдывать это доверие. К сожалению, мы увидели пренебрежение безопасностью со стороны Poly Network. Например, отсутствие проверки — это «старая добрая» уязвимость безопасности, о которой я рассказывал на занятиях для студентов.
-
Отсутствие верифицированного исходного кода для такого DeFi-проекта с TVL более 600 млн долларов. Основа децентрализованной инфраструктуры — это доверие, а фундамент доверия — прозрачность. К сожалению, пользователи готовы вкладывать свои деньги в проект-«черный ящик», что меня удивляет и беспокоит. Как повысить уровень осведомленности пользователей о безопасности — вероятно, требует поиска нового решения.
Ссылки
[1]https://blocksecteam.medium.com/the-initial-analysis-of-the-polynetwork-hack-270ac6072e2a
[2]https://twitter.com/kelvinfichter/status/1425290462076747777
[3]https://blocksecteam.medium.com/the-further-analysis-of-the-poly-network-attack-6c459199c057
Авторы: Юфэн Ху, Сивэй У, Лэй У, Яджин Чжоу @ BlockSecTeam
