Взлом BNB Chain: как это было?

Пользователь под ником samczsun, работающий ресерчером в известном фонде Paradigm, рассказал в своем треде как происходил взлом BNB Chain (повествования будет от лица автора):

Злоумышленник украл 2 миллиона BNB с Binance Bridge. Вот как все произошло.

Все началось с того, что мне прислали адрес с миллионами долларов. Либо их получили большим “выдергиванием ковра” (рагпул), либо огромным взломом.

Потребовалось несколько секунд, чтобы понять, что хакер “действительно” вложил 200 млн в Venus. Осталось выяснить, где он их взял.

Дело в том, что ему удалось “убедить” Binance Bridge, дважды отправить ему по 1 млн BNB.

Либо это был жирный дроп от Binance, либо он нашел критическую уязвимость.

Я начал со сравнения его транзакций и обычных переводов средств. Первое, что мне удалось заметить — высота блоков, которую он использовал. Она всегда была одинаковой — 110217401. Высоты, используемые для законных выводов средств, были намного больше.

Также “доказательство” транзакции было значительно короче чем у обычных транзакций.

Это заставило меня поверить, что хакеру удалось подделать доказательство для конкретного блока — 110217401, поэтому пришлось выяснить как они вообще работают.

На Binance существует специальный контракт предварительной компиляции, используемый для проверки деревьев IAVL. Если вы ничего не знаете о деревьях IAVL, не волнуйтесь.

В основном, когда вы проверяете дерево IAVL, вы указываете список “операций”. Binance Bridge обычно ожидает два из них: операцию “iavl:v” и операцию “мультистор”. Вот их реализации:

• https://github.com/cosmos/iavl/blob/de0740903a67b624d887f9055d4c60175dcfa758/proof_iavl_value.go#L61-L82
• https://github.com/bnb-chain/bsc/blob/46d185b4cfed54436f526b24c47b15ed58a5e1bb/core/vm/lightclient/multistoreproof.go#L106-L125

Чтобы подделать доказательство, нам нужно, чтобы обе операции были успешными, и нам нужно, чтобы последняя операция (мультистор) возвращала фиксированное значение (хэш указанного блока: 110217401).

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

Входное значение операции “multistore” является выходным значением операции “iavl:v”. Это означает, что мы хотим как-то контролировать здесь корневую переменную, но при этом пройти проверку значения.

Так как же вычисляется корневой хэш? Что ж, бывает в этом монстре функция под названием COMPUTEHASH. На очень-очень высоком уровне, хэш рекурсивно проходит по каждому пути и листу и выполняет кучу хеширования, и на самом деле, детали результата не имеют значения.

Глядя на то, как доказательство изложено в легитимной транзакции, мы видим, что оно имеет очень длинный путь, без внутренних узлов и только с одним конечным. Этот листовой узел содержит хэш нашей вредоносной полезной нагрузки! Если мы не можем изменить этот конечный узел, нам нужно добавить новый.

Конечно, если мы добавим новый конечный узел, нам также потребуется добавить новый внутренний узел, чтобы они соответствовали друг другу.

Теперь нам осталось столкнуться с последним препятствием – заставить COMPUTEHASH возвращать нужный нам корневой хэш. Обратите внимание, что в конечном итоге нам понадобится путь, содержащий ненулевой правильный хэш. Когда мы находим подходящий, мы утверждаем, что он соответствует промежуточному корневому хэшу.

Давайте просто немного отредактируем код, чтобы понять, какой хэш нам нужен, и…

Осталось собрать все воедино. Мы возьмем законное доказательство и изменим его так, чтобы:

• мы добавили новый лист для forged payload;
• мы добавили пустой внутренний узел, чтобы удовлетворить доказательств;
• мы настроили наш лист, чтобы получить правильный корневой хэш.

(Стоит отметить, что это был не тот метод, который использовал злоумышленник. Однако остальная часть эксплойта идентична)

Таким образом, ошибка была в том, как Binance Bridge проверял доказательства, которые могли позволить злоумышленникам подделывать произвольные сообщения. К счастью, злоумышленник подделал всего два сообщения, но ущерб мог быть намного больше.

После этого, хакер перевел 1 млн BNB на лендинговую платформу Venus, под залог которых ему удалось взять $150 млн в различных стейблкоинах. После этого средства были распределены в различные сети.

Сейчас BNB Chain возобновила свою работу, а валидаторы провели обновления кода. Во время публикации информации об обновлении, разработчики сообщали, что оно призвано заблокировать аккаунт хакера и остановить транзакции между BNB Beacon Chain и BNB Chain.