Топ самых громких реентранси атак в истории блокчейна

Reentrancy attack — это вид атаки на смарт-контракты, при которой злоумышленник может многократно вызывать функции контракта, изменяя его состояние и извлекая средства. Этот тип атаки стал известен после инцидента с The DAO и продолжает быть угрозой для многих проектов в блокчейне.

1) The DAO:

Взлом The DAO стал одним из самых известных инцидентов в истории криптовалют, подчеркнув уязвимости, связанные с реентранси атаками в смарт-контрактах. The DAO был децентрализованной автономной организацией на Ethereum, предназначенной для инвестиций в проекты через смарт-контракты. Атака произошла из-за уязвимости в коде смарт-контракта, позволявшей атакующему многократно извлекать средства из DAO перед обновлением баланса, что привело к значительным финансовым потерям. Злоумышленник использовал рекурсивные вызовы функции splitDAO, чтобы извлечь средства из DAO

Реентранси атака в Solidity происходит, когда атакующий может вызвать функцию контракта повторно, до того как первый вызов функции завершен, что позволяет атакующему извлекать средства или изменять состояние контракта. В случае с DAO, атакующий использовал эту уязвимость для многократного изъятия Ether из фонда. Этот инцидент подчеркнул необходимость тщательного аудита и тестирования смарт-контрактов, чтобы предотвратить подобные атаки в будущем. Это, возможно, самый известный инцидент, связанный с reentrancy attack, результатом которой стала потеря более 3,6 миллионов ETH.

2) Parity Wallet:

В июле 2017 года произошел один из самых значительных взломов в истории Ethereum — взлом мультисиг-кошелька Parity. Атака привела к потере более 150,000 ETH, что на тот момент составляло около 30 миллионов долларов США. Уязвимость была обнаружена в версии мультисиг-кошелька Parity 1.5+, что позволило злоумышленнику украсть значительные средства из трех известных мультисиг-контрактов, используемых для хранения средств от прошлых продаж токенов.

Атака была осуществлена путем отправки двух транзакций на каждый из затронутых контрактов: первая транзакция позволила атакующему получить исключительное владение мультисигом, а вторая — переместить все его средства. Злоумышленник использовал функцию initWallet для изменения владельцев контракта, установив себя единственным владельцем, что позволило ему выполнить вторую транзакцию и перевести все средства на контролируемый им аккаунт. Это стало возможным из-за того, что функция initWallet не имела проверок, предотвращающих ее вызов после инициализации контракта, что и было использовано злоумышленником для изменения состояния контракта и последующего вывода средств.

Хотя этот инцидент часто ассоциируется с ошибкой в мульти-сигнатурном кошельке, его можно рассматривать в контексте reentrancy из-за многократного вызова функции initWallet.

3) Uniswap/Lendf.Me:

В апреле 2020 года произошли два крупных взлома в экосистеме DeFi: Uniswap и Lendf.Me, приведшие к общим потерям более 25 миллионов долларов. Атаки были осуществлены с использованием реентранси атаки, эксплуатируя уязвимости в логике контрактов.

На Uniswap атака началась с того, что злоумышленник использовал токен imBTC, который поддерживает функцию ERC777, позволяющую вызывать обратные вызовы при транзакциях. Это дало возможность атакующему инициировать реентранси атаку. Злоумышленник сначала обменивал ETH на imBTC и обратно через Uniswap, вызывая реентранси в функции tokenFallback. Это позволило атакующему многократно извлекать ETH из пула Uniswap, используя одни и те же imBTC.

В случае с Lendf.Me, платформой для заимствования и кредитования, атакующий использовал ту же уязвимость ERC777 токена для инициации реентранси атаки. Злоумышленник депонировал imBTC в качестве залога и одновременно занимал другие активы, повторно вызывая функцию заимствования в процессе транзакции. Это привело к тому, что атакующий смог вывести значительно больше средств, чем было заложено, эффективно опустошая пулы ликвидности на платформе.

4) Bancor:

Взлом Bancor произошел из-за уязвимости в их смарт-контракте, который позволял злоумышленникам вызывать функцию withdraw повторно, что является классическим примером reentrancy атаки. В данном случае, хакеры смогли манипулировать логикой контракта, чтобы извлечь средства, не подлежащие выводу в обычных условиях.

Уязвимость была связана с тем, как контракт обрабатывал внешние вызовы. В идеале, после выполнения действия, такого как вывод средств, состояние контракта должно обновляться до того, как будут выполнены какие-либо внешние вызовы, чтобы предотвратить повторное использование той же логики. Однако, в контракте Bancor, состояние обновлялось после внешнего вызова, что позволило атакующему повторно вызвать функцию withdraw, эксплуатируя состояние до его обновления.

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

В ходе атаки хакеры получили доступ к кошельку, который использовался для обновления умных контрактов Bancor. С этим доступом они смогли украсть 24 984 ETH (около 12,5 миллионов долларов на тот момент), 229 356 645 NPXS (около 1 миллиона долларов) и 3,2 миллиона долларов в Bancor Network Tokens (BNT). Злоумышленники использовали уязвимость в логике контракта, которая позволяла им передавать токены без соответствующих проверок безопасности. После обнаружения взлома Bancor заморозил передачу украденных BNT, используя механизм, встроенный в протокол токена, что вызвало дискуссии в сообществе о децентрализации и контрольных механизмах в DeFi.

Заключение

Эти примеры реентранси атак подчеркивают критическую важность тщательного аудита и тестирования смарт-контрактов перед их развертыванием. Уязвимости в коде могут привести к значительным финансовым потерям и подорвать доверие к проекту. Аудит смарт-контрактов не только выявляет потенциальные уязвимости, но и способствует оптимизации кода, повышая его безопасность и эффективность. Тестирование кода должно быть всесторонним, включая проверку на различные виды атак и эксплуатацию известных уязвимостей. В конечном итоге, внимание к деталям в процессе разработки и аудита может значительно снизить риски и способствовать созданию более надежных и безопасных децентрализованных приложений.