---
title: "Крипто и хакинг — кошмары Black Hat"
description: "Хакерские инциденты в криптосфере — мосты, ключи, социальная инженерия и эксплойты механизмов управления — и медленные, дорогостоящие меры защиты, которые внедряют серьезные команды."
language: ru
published: 2026-04-08
author: Netts
topic: "Insights"
canonical: https://netts.io/blog/crypto-and-hacking-black-hat-nightmares?lang=ru
languages: [en, ru, es, zh, th, fr, uk, tr, hi, fa, ar, ha, pt, vi, ko, ja, id, de, tl]
translation_outdated: false
---
# Крипто и хакинг — кошмары Black Hat

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

Криптовалюты часто представляют как оплот криптографии, децентрализованного консенсуса и неизменяемых реестров. Но правда об этой цифровой «земле обетованной» гораздо сложнее и опаснее. Традиционные СМИ обычно рассказывают о взломах в криптосфере через призму социальной инженерии, фишинговых кампаний или простого мошенничества, когда ничего не подозревающего пользователя заставляют ввести адрес биржи или приватный ключ на вредоносном сайте.

Но в этой статье мы полностью проигнорируем ошибки, вызванные человеческим фактором. Мы поговорим о «чистом» хакинге. Это территория нарушенной кибербезопасности и кода с глубокими изъянами, которые приводят к катастрофическим последствиям. Это мир грез «черных шляп», где код превращается в оружие против своих создателей, выводя сотни миллионов долларов за считанные минуты без единого выстрела; заставляя нас сталкиваться с крайними проявлениями логических ошибок, багами компиляторов и архитектурными просчетами.

## Откуда берутся эксплойты смарт-контрактов

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

Контракт привлек Ether на миллионы долларов от инвесторов, которые рассчитывали голосовать по предложениям и получать вознаграждения. Однако разработчики не обеспечили безопасность процесса вывода средств, допустив уязвимость под названием reentrancy (повторный вход).

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

Злоумышленник понимает, что он также может развернуть вредоносный смарт-контракт с функцией fallback.

Функция fallback вызывалась каждый раз, когда The DAO отправлял средства на этот вредоносный контракт. Функция fallback не просто принимала средства, она сразу же снова вызывала функцию вывода средств The DAO. Это еще раз инициировало функцию fallback, которую The DAO исполнял, так как баланс хакера еще не был обновлен на момент первого вывода средств.

Этот процесс повторялся снова и снова, выводя миллионы долларов из The DAO до того, как сеть смогла отреагировать.

## Последствия и хардфорк

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

Это спорное решение вызвало окончательный раскол, приведший к появлению Ethereum и Ethereum Classic. Сегодня эта конкретная уязвимость хорошо известна и в основном устраняется с помощью паттерна Checks-Effects-Interactions.

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

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

## Эра неинициализированной логики и вызовов delegatecall

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

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

![Крипто и хакинг — кошмары Black Hat](https://netts.io/blog/images/body/b7dc4431528a66c92d05f1f6a167125cf15ddc18-611.webp)

Данный класс уязвимости возник из-за неправильного понимания функции delegatecall и неинициализированных переменных состояния. Функция delegatecall позволяет контракту выполнять функцию из другого контракта, но при этом предоставляет этой функции доступ к хранилищу (storage) вызывающего контракта. В контракте-библиотеке Parity находилась функция для инициализации владельцев кошелька.

Но сам контракт-библиотека на самом деле никогда не был инициализирован. Хакер обнаружил, что может вызвать функцию инициализации напрямую в контракте библиотеки и объявить себя его владельцем. Получив права владения библиотекой, он вызвал функцию для её самоуничтожения.

## Заморозка мультисиг-кошельков

Мультисиг-кошельки, зависевшие от этой библиотеки, мгновенно стали неработоспособными после её уничтожения. Вся логика, необходимая для обработки транзакций, вывода средств или даже простого запроса баланса, была безвозвратно утеряна. В ходе этого процесса из-за грубой архитектурной ошибки сотни миллионов долларов в Ether не были украдены, а оказались физически заморожены.

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

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

## Криптографический мираж кроссчейн-мостов

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

Из-за огромного объема хранящихся в них активов они стали настоящей приманкой («медовыми ловушками») для «черных» хакеров.

Взлом моста Wormhole — это пугающее напоминание о том, как одна незначительная деталь, упущенная при реализации, может привести к полному отказу сложной криптографической проверки. Wormhole позволял переводить активы между сетями Solana и Ethereum. Этот процесс подразумевал наличие группы «хранителей» (guardians), которые отслеживали событие в одной сети и подписывали сообщение для его подтверждения. Затем эти подписи проверялись в целевой сети перед минтингом соответствующих токенов в виде новых активов.

Уязвимость заключалась в механизме проверки подписи в смарт-контракте в сети Solana. Криптографическая проверка выполнялась встроенной программой Solana, которую вызывал контракт. Однако разработчики Wormhole не проверили, что вызываемая программа действительно является официальной системной программой. Хакер создал программу, которая всегда возвращала сообщение об успешном выполнении, независимо от входных данных.

![Крипто и хакинг — кошмары Black Hat](https://netts.io/blog/images/body/f07a7543274d3ad3921a8ab12dc584db6accfbb1-1352.webp)

Затем смарт-контракту Wormhole было дано указание использовать это поддельное приложение для валидации. Опираясь на ложное предположение о валидности подписей, контракт выпустил «обернутый» Ethereum в сети Solana на сотни миллионов долларов, при этом на другой стороне не было заблокировано ни одного реального Ethereum. Затем хакер перевел эти только что выпущенные, ничем не обеспеченные токены обратно в сеть Ethereum, опустошив протокол и выведя реальные активы.

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

Последствия были огромными: потребовалось вмешательство спонсоров проекта для спасения протокола, чтобы предотвратить системный крах DeFi-экосистемы Solana.

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

## Взлом моста Nomad

Если Wormhole был скоординированной атакой в определенном направлении, то взлом моста Nomad доказал, насколько легко одна простая логическая ошибка может погрузить протокол в хаос, превратив его в арену для всеобщего грабежа. Для реализации кроссчейн-передачи сообщений Nomad использовал модель оптимистичного роллапа, которая опиралась на дерево Меркла для подтверждения валидности сообщений. Разработчики допустили критическую ошибку при инициализации доверенного корня во время развертывания обновления протокола.

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

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

Сотни различных участников вывели из моста Nomad почти двести миллионов долларов всего за несколько часов.

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

Этой конкретной ошибки было элементарно избежать при тщательном тестировании, однако более широкий класс ошибок инициализации до сих пор активно поражает системы.

## Ошибки компилятора и рыночные манипуляции

Один из самых пугающих типов «чистого» взлома — это когда ошибка кроется не в коде разработчика, а в инструментах, которые использовались для его компиляции. Нам напомнили об этом во время эксплойта Curve Finance, который вызвал потрясения в самих основах DeFi. Большая часть основных контрактов Curve — ведущей DEX для стейблкоинов — была написана на Vyper, Python-подобном языке смарт-контрактов, в котором упор делается на безопасность и простоту.

![Крипто и хакинг — кошмары Black Hat](https://netts.io/blog/images/body/fb1a3072c294e46c9b814e24b51fab2185107cad-533.webp)

К счастью, разработчики Curve внедрили в свои смарт-контракты защиту от повторного входа (reentrancy guards), защитив их именно от того типа атак, который в свое время разорил The DAO. Но в одной конкретной старой версии компилятора Vyper эта ошибка была скрыта.

Компилятор успешно перевел человекочитаемый код Vyper в машиночитаемый байт-код, предназначенный для исполнения в виртуальной машине Ethereum, однако он не справился с корректным распределением блокировки повторного входа (reentrancy lock) между несколькими функциями.

Код был безопасным, разработчики написали его именно так, как требовалось, но компилятор фактически «ударил их в спину», создав байт-код с уязвимостями. Это привело к тому, что злоумышленник заметил и понял: некоторые пулы ликвидности Curve подвержены межфункциональному повторному входу. Он воспользовался этим, чтобы вывести из пулов десятки миллионов долларов.

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

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

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

Флэш-займы, обычно предназначенные для арбитража или ликвидаций, предоставили «черным» хакерам необходимую ликвидность для эксплуатации глубоких логических уязвимостей в механике рынка. Рассматривая взлом Euler Finance в качестве примера: Euler представлял собой лендинговый протокол для внесения депозитов и получения прибыли. Пользователи также могли передавать свои депонированные активы в резервы протокола с помощью функции под названием donateToReserves.

Однако разработчики упустили очень важную проверку состояния (health check) в этой функции. Они не проверили, останется ли аккаунт, с которого донор выводит средства, платежеспособным после пожертвования. Злоумышленник взял крупную сумму активов через флэш-займ и внес их в Euler. Затем он вызвал функцию donateToReserves, чтобы пожертвовать часть своего депозита.

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

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

Это имело серьезные последствия: работа протокола была прервана, а на переговоры по возврату части капитала ушли месяцы.

Подобные логические эксплойты, при которых сложные финансовые механизмы взаимодействуют друг с другом непредусмотренным образом, представляют собой наиболее распространенную и опасную форму «чистого» хакинга на сегодняшний день. Сложность протоколов будет расти, и подобные логические просчеты, скорее всего, будут практически неизбежно повторяться.

## Непрекращающаяся борьба между кодом и последствиями

Если оглянуться на историю этих масштабных взломов, можно легко заметить определенную закономерность. Эти уязвимости редко являются результатом сбоя базовых механизмов консенсуса блокчейна. Нет, это ошибки человеческой логики, заложенной в неизменяемый код. Будь то некорректное обновление состояния, неучтенный путь выполнения кода для прокси, пропущенная криптографическая проверка, ошибка компилятора или отсутствие проверки финансового инварианта — первопричиной всегда является ошибка в самом проектировании смарт-контракта.

Для устранения этих рисков в индустрии сформирована комплексная система защиты. Она включает в себя:

1. Аудиты кода сторонними специалистами из независимых компаний по кибербезопасности. 2. Инструменты формальной верификации, которые математически доказывают, что код работает именно так, как было задумано. 3. Крупные программы вознаграждения за найденные ошибки (bug bounty), в рамках которых «белым» хакерам платят за обнаружение дефектов раньше злоумышленников. 4. Использование временных блокировок и управления административными ключами с мультиподписью (multi-sig) для замедления развертывания вредоносных обновлений. 5. Использование протоколов децентрализованного страхования для обеспечения покрытия на случай взлома.

Тем не менее, «черный» хакинг по-прежнему существует, даже несмотря на то, что меры защиты стали более совершенными. Отправной точкой разработки программного обеспечения является тот факт, что сложность создает возможности для возникновения ошибок.

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

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

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

![Крипто и хакинг — кошмары Black Hat](https://netts.io/blog/images/body/34152a20b98c0c43676268dfd3c3a61089671d6b-1203.webp)

Для активного участника экосистемы поиск дешевого способа перевода USDT имеет решающее значение. Именно здесь специализированные инструменты дают вам преимущества. Сервис netts: Калькулятор переводов USDT создан именно для того, чтобы оптимизировать эти процессы.

При переводе Tether в сети TRON расходуются ваши ресурсы Энергии и Пропускной способности. Если они у вас отсутствуют, сеть сжигает ваши TRX в счет комиссии за перевод USDT.

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