Double Entry Point

На каникулах прочитал об одном интересном эксплойте, который случился с Balancer в 2022 году. Саму статью можно прочитать тут, а я дам краткий пересказ уязвимости.

Balancer позволяет пользователям брать быстрые займы без залога, если они будут возвращены в той же транзакции. Именно в функции flashloan и крылся интересный баг.

Кратко говоря, функция узнавала изначальный баланс имеющихся токенов для займа, высчитывала процент займа и пересылала средства пользователю. Также там была fallback функция receiveFlashLoan(), которая должна была быть определена в контракте пользователя для возврата займа.

После того, как займ возвращался обратно от пользователя, высчитывалась разница в изначальном и конечном балансах, и эта разница пересылалась в другой контракт Balancer, который использовался как сейф.

Так в чем же здесь может быть проблема?

А в том, что контракт функционировал через прокси.

Мы же помним, что в правильном варианте работы логики прокси контрактов, пользователь взаимодействует именно с прокси, который позже переводит все действия в контракт исполнения? Т.е., упрощенно говоря, мы вызываем какую-либо функцию в прокси контракте, она делегирует исполнения в третий контракт.

Так вот, в случае с Balancer пользователь мог взаимодействовать как с прокси контрактов, так и с третьим контрактом напрямую! Это-то и создавало баг double entry point.

В примере эксплойта, который приводится в статье, хакер мог запросить займ токенов из обоих контрактов: прокси и исполнения. Причем в первом случае он брал займ на 100% возможную сумму токенов, а во втором - 0. Это создавало некий баг в конечный расчетах, что приводило к тому, что весь займ токенов переводился в контракт Сейфа, и никто потом больше не мог брать займ под этот токен.

Да, хакер не получал ничего, но и работа сервиса стопорилась.

Мне просто понравился этот баг, и теперь при аудите контрактов, где используется прокси и erc20, я всегда проверяю и эту возможность.

#security #doubleentrypoint