Честно говоря, когда в прошлом месяце вышли данные по безопасности в криптосфере, я пересмотрел их несколько раз, прежде чем убедиться, что мне не мерещится.
В августе весь сектор из-за различных атак и мошенничества потерял более 200 миллионов долларов. Сама по себе эта цифра уже достаточно бросается в глаза, но ещё сильнее меня настораживает другое: у атакующих полностью изменился подход.
Они больше не зациклены на поиске уязвимостей в коде смарт-контрактов, а начали искать лазейки в рыночных механизмах, правилах управления и даже в процессах продления доменов.
1. Манипуляция ценой: не трогать ваш код, а напрямую играть с логикой ценообразования
Самая крупная потеря в августе пришлась на один кредитный протокол, который пострадал от «хрестоматийной» ценовой манипуляции. За какие-то 20 минут злоумышленник поднял цену одного токена управления примерно в 100 раз, а затем сразу же использовал эти «раздутые» токены в качестве залога и вывел крупную сумму реальных активов.
Вся операция не использовала ни одной уязвимости смарт-контракта. Код работал нормально, логика тоже была без ошибок; проблема была в оракуле или в чрезмерной зависимости источника цены от крайне неликвидного спотового рынка. Когда право определять цену залога оказывается у пулов, которыми можно манипулировать небольшим объёмом средств, протокол превращается в легальный банкомат.
Похожие методы как минимум дважды применялись в августе. Другой кредитный протокол тоже потерял почти 10 миллионов долларов из-за того, что напрямую считывал цену залога из слабой спотовой ликвидности и был обчищен тем же способом.
Это показывает один очень жёсткий факт: во многих DeFi-протоколах слабое место безопасности находится не на уровне контракта, а на уровне экономической модели. Ваш код может пройти проверку у топовой аудиторской компании, но ваша схема ценообразования может исходить из идеального мира, где «рынок не поддаётся манипуляциям». В криптомире это просто не работает.
Если вы занимаетесь кредитными протоколами, платформами маржинальной торговли или любыми продуктами, которым требуется ценообразование активов в реальном времени, многoисточниковый оракул + механизм аварийного отсечения аномалий должны закладываться в архитектуру с первого дня, а не вспоминаться и допиливаться перед запуском. Если говорить конкретно, цену залога нельзя смотреть только по спотовому пулу одной DEX: нужно вводить взвешенное по времени среднее, агрегацию из нескольких источников и мониторинг отклонения цены. Когда цена какого-либо актива за короткое время колеблется выше порога, система должна автоматически приостанавливать новые займы или запускать защиту от ликвидаций. Инженерная реализация этих модулей совсем не проста: она затрагивает синхронизацию данных ончейн и офчейн, отказоустойчивость сети оракулов и автоматизацию процессов экстренного управления.
II. Атаки на управление: более скрытый «бэкдор», чем баги в коде
В августе был ещё один особенно показательный инцидент. Казну одного протокола кредитования с фиксированной ставкой опустошили, убыток составил 8,5 миллиона долларов. Злоумышленник не писал никакой атакующий контракт; он просто купил на рынке большинство голосов токенов управления, а затем напрямую проголосовал за перевод денег из казны на свой адрес.
Это злоупотребление полномочиями управления, а не уязвимость кода. Команда использовала архитектуру Yearn V3 для казны, но параметры управления были слишком мягкими, что позволило атакующему сравнительно недорого купить достаточно голосов, чтобы изменить протокол.
Опасность этой атаки в том, что она полностью обходила зону видимости традиционного аудита безопасности. Аудиторские компании проверяют код смарт-контрактов, но не будут проверять распределение ваших токенов управления и дизайн порогов голосования. Однако если с этим возникнет проблема, разрушительный эффект будет не меньше, чем у любой уязвимости повторного входа.
Многие проекты при построении DAO-управления понимают «децентрализацию» как «низкий порог для голосования», и в итоге открывают злоумышленникам дверь. Корректный дизайн управления должен включать задержку голосования (после прохождения предложения оно не исполняется сразу, а у сообщества есть время отреагировать), аварийный переключатель паузы (мультисиг или технический комитет может заморозить протокол в экстремальных случаях), а также локап или вестинг для токенов управления. Эти механизмы не означают «недостаточную децентрализацию» — они означают ответственное отношение к протоколу и активам пользователей. Если вы планируете модуль управления для проекта, не стоит проектировать управление как отдельный политический эксперимент; его нужно включать в общую архитектуру безопасности.
III. Зависимости upstream: одна уязвимость — шесть цепочек под ударом
В августе был ещё один случай, который должен насторожить всех разработчиков. В одном EVM-модуле, повторно используемом несколькими цепочками, была обнаружена уязвимость целочисленного underflow. В результате злоумышленник использовал её и за одну неделю последовательно взломал шесть разных блокчейн-сетей, а общий ущерб превысил 5 миллионов долларов.
Самое неловкое в том, что патч для уязвимости уже был выпущен, но атака произошла примерно через 20 часов после публикации патча. Некоторые цепочки даже жаловались, что не получили предварительного уведомления.
Этот случай выявил две глубокие проблемы:
Во-первых, риск «копипаста». Многие цепочки, чтобы быстро совместиться с экосистемой EVM, просто повторно используют зрелые open-source-модули. Само по себе это не проблема, но если в upstream-компоненте появляется уязвимость, все проекты, которые на него опираются, автоматически попадают под удар. Вам кажется, что вы стоите на плечах гиганта, а на деле вы привязаны к нему одной и той же верёвкой.
Во-вторых, временной лаг в реагировании на патчи. В мире Web2 для критических уязвимостей существуют процессы ответственного раскрытия и координации. Но в Web3 у многих проектов нет зрелого SOP для реагирования на уязвимости. Патч уже выпущен, но downstream-проекты об этом не знают, не обновились или при обновлении не провели тесты на совместимость — и это даёт атакующему «окно возможностей».
Если вы делаете Layer2, appchain или любой проект, зависящий от сторонних open-source-компонентов, безопасность цепочки поставок должна быть поставлена по важности на один уровень с аудитом смарт-контрактов. Рекомендуется внедрить механизм мониторинга изменений в upstream-компонентах и проводить независимый аудит ключевых зависимостей после fork, а не просто напрямую подключать последнюю версию. Одновременно нужно разработать чёткий план реагирования на уязвимости: кто отвечает за мониторинг security-уведомлений? Какие тесты должен пройти процесс обновления? Как срочно поставить патч без остановки сервиса? Если эти процессы не были отрепетированы заранее, когда придёт реальный инцидент, вы почти наверняка будете действовать наспех и хаотично.
IV. Человеческое звено: утечки подписей и фишинг — «новые варианты»
Помимо продвинутых ончейн-сценариев, в августе были и более «приземлённые», но крайне разрушительные атаки.
Веб-приложение одного RWA-проекта было взломано, и злоумышленник получил не уязвимость смарт-контракта, а ключи подписи, хранившиеся на платформе. В результате пострадали пользователи и резервные хранилища сразу на пяти цепочках. Этот случай показывает, что уровень безопасности фронтенда и сервера напрямую определяет верхнюю границу безопасности ончейн-активов. Как бы красиво вы ни написали контракт, если управление ключами на сервере фронтенда устроено хаотично, злоумышленник легко обойдёт все ончейн-барьеры.
Фишинговые атаки тоже эволюционируют. В августе появилось несколько новых схем:
Угон просроченного домена: официальный домен известного инструмента для приватности не был продлён из-за того, что команда попала под санкции, и его перехватили хакеры, развернув подделку почти один в один. Некоторые пользователи заходили через старые закладки в браузере, и за 12 часов у них поэтапно увели более тысячи ETH.
Фишинг через рекламу в поисковике: пользователь искал в Google торговую платформу, кликнул по рекламе на первом месте, а это оказался поддельный сайт; как только он подключил кошелёк, средства были украдены.
Отравление адреса: жертва скопировала из заражённой истории переводов адрес, который «выглядел почти так же», и в итоге 2 миллиона долларов ушли прямо злоумышленнику.
Общее у этих атак одно: им не нужно взламывать ни один смарт-контракт — достаточно взломать внимание или привычку пользователя.
V. Подход к защите: от «одного аудита» к «непрерывной эксплуатации»
После того как я посмотрел на все августовские кейсы, хочу дать несколько практичных рекомендаций командам, которые делают проекты или управляют активами.
Для разработчиков протоколов:
Механизм ценообразования должен исходить из того, что рынок может быть подвержен манипуляциям. Особенно это важно для кредитных протоколов: оракулы залога должны проходить перекрёстную проверку по нескольким источникам, а для активов с низкой ликвидностью должен быть аварийный отсекатель при ценовом отклонении.
Параметры управления нужно строить с «запасом безопасности». Порог голосования, задержка исполнения, право на экстренную паузу — это не противоположность децентрализации, а предохранители протокола.
За зависимостями upstream должен кто-то следить. Обновления ключевых open-source-компонентов, уведомления о безопасности и выпуск патчей нужно включить в повседневный операционный процесс, а не полагаться на то, что какой-то инженер время от времени листает Twitter.
Для обычных пользователей:
Не ищите официальный сайт через поисковик. Сохраните адреса нужных протоколов в закладки и регулярно проверяйте срок действия домена (да, это немного параноидально, но хотя бы перед крупными операциями перепроверяйте).
При копировании адреса всегда смотрите на все символы. Не проверяйте только первые четыре и последние четыре — отравление адреса как раз и эксплуатирует человеческую лень.
Регулярно чистите разрешения кошелька. После многих взаимодействий с DApp у него остаются права распоряжаться вашими активами — если они больше не нужны, отзовите их.
Активы высокой ценности храните отдельно. Для повседневных взаимодействий используйте один кошелёк, для крупных сбережений — другой, который редко подключается к DApp, а ещё лучше — аппаратный кошелёк.
Безопасность в Web3-индустрии никогда не была разовой покупкой. Данные за август показывают, что атакующие переходят от «opportunistic» (opportunistic) к «преднамеренному планированию» — они сначала изучают вашу структуру управления, ваши источники ценообразования, ваши зависимости upstream и бьют по самому слабому месту. Если ваша команда по-прежнему приравнивает безопасность к «найти аудиторскую компанию перед запуском и получить отчёт», то, возможно, пора серьёзно повышать уровень безопасности. Начиная с аудита экономической модели и дизайна управления и заканчивая мониторингом компонентов upstream и круглосуточным аварийным отсечением аномалий, всё это требует постоянных инженерных вложений. Если внутренних ресурсов не хватает, часто выгоднее передать эти модули команде с практическим опытом mainnet-инцидентов, чем потом тушить пожар после взлома.
Заключение:
Учеба ценой в 200 миллионов долларов в августе дала очень трезвое понимание: поверхность атак в криптомире уже вышла далеко за пределы кода и расширилась до уровня экономики, управления, цепочки поставок и человеческого фактора.
⚠️ 【免责声明】：本文公开安全事件数据与行业观察整理，仅供安全意识普及与技术交流，不构成任何投资或操作建议, 从业者及用户请务必严格遵守所在司法管辖区的合规合规要求。
🌹 Если вам понравился этот подробный разбор, ставьте лайк, подписывайтесь, оставляйте комментарии и делитесь! Ваша поддержка — главный двигатель нашей дальнейшей работы。#web3 #黑客 #区块链