Согласно данным платформы Beosin Alert, в августе 2026 года общие потери от различных инцидентов безопасности составили около 76,15 млн долларов США, произошло 29 серьезных инцидентов безопасности, основной причиной которых были уязвимости в смарт-контрактах. Среди них 18 инцидентов были связаны с уязвимостями в смарт-контрактах/сети, 2 инцидента — с утечкой приватных ключей; безопасность смарт-контрактов и управление приватными ключами остаются слабыми местами в безопасности Web3.
Топ-10 потерь за август
13 августа личный адрес пользователя 0x13e3....179e из-заутечки приватного ключабыл ограблен, и из него были похищены криптоактивы WBTC, cbBTC, LDO, USDS, CRV и другие, общая сумма убытков составила около 25,6 млн долларов США — это самое крупное реальное финансовое потери в истории кибератак. 30 августаCronos на сетевом протоколе займа Tectonic произошла хакерская атака из-за уязвимости в смарт-контракте, ожидаемый ущерб составляет около 74 млн долларов США. В результате атаки сеть Cronos приняла экстренные меры — приостановила работу сети и откатила транзакции; в итоге хакеру удалось успешно перевести около 6 млн долларов США через межсетевой обмен наEthereumсеть.
Кроме того, из-за уязвимости в блокчейне Harmony было дополнительно отчеканено около 4 миллиардов токенов ONE, номинальный ущерб превысил 4 миллиона долларов США, но в конечном итоге фальшивые токены были удалены путем отката транзакций, поэтому они не учитываются в убытках.
Типы атакуемых проектов и потери по каждой цепочке
В этом месяце атакам подверглись различные типы объектов: публичные блокчейны, протоколы кредитования, кошельки, смарт-контракты токенов, мосты между блокчейнами и обычные пользователи. Наибольшие потери зафиксированы у проектов DeFi — они составили 33,09 миллиона долларов США; потери личных адресов из-за утечки приватных ключей или фишинга составили около 28,4 миллиона долларов США. Наибольшее количество атак пришлось на смарт-контракты токенов — всего 10 случаев; на втором месте — смарт-контракты DeFi, подвергшиеся атакам 9 раз.
В мае наиболее потерпевшей блокчейн-сетью стала Ethereum, с убытками более 48,58 млн долларов США и 15 инцидентами безопасности; в настоящее время большинство DeFi-протоколов и фишинговых атак на крупных держателей по-прежнему нацелены на Ethereum. Второй по количеству инцидентов блокчейн — BNB Chain, однако основными целями атак являются токен-контракты, и убытки здесь незначительны. Кроме того, инциденты безопасности также происходили в таких блокчейнах, как Cronos, Base, Harmony, Bitcoin и Solana, что свидетельствует о многоплатформенном характере атак.
Анализ основных инцидентов безопасности
1. Tectonic и Moonwell: манипуляция ценами
Tectonic и Moonwell — это протоколы кредитования на цепочке, которые были атакованы из-за манипуляций ценой с низкой ликвидностью токенов, используемых в качестве залога, что позволило получить чрезмерные займы на завышенную стоимость активов. При атаке на Tectonic злоумышленник поднял цену токена управления Tectonic $TONIC в 100 раз и получил кредитный лимит в размере около 74 миллионов долларов США, после чего заимствовал активы, такие как USDT. После инцидента сеть Cronos экстренно приостановила создание блоков, и злоумышленник перевел около 6 миллионов долларов США на Ethereum до приостановки сети. Затем сеть Cronos выполнила откат, чтобы компенсировать потери.
Хакерский адрес получения средств с Ethereum: 0xc404160B79BD8905061a1cAecBeCa2EEab3f72DD и направления движения украденных средств:
Сейчас около 2659 ETH все еще хранятся на 0xc4041, после перевода 140,1 ETH на 0x6df89c42f0abdfaa2b5b77edcdafbc945ed6ee6c они продолжили быть распределены на несколько новых адресов.
Moonwell потерял около 8,7 млн долларов США, поскольку злоумышленник манипулировал ценой токена MAMO с низкой ликвидностью, чтобы занять cbBTC:
Эти две атаки не были основаны на уязвимостях смарт-контрактов, а вызваны тем, что протокол неправильно рассчитал стоимость залога, определяя его цену на основе слабой ликвидности спот-рынка. Чтобы предотвратить подобные атаки, протокол может получать данные из нескольких источников через несколько оракулов и дополнительно анализировать резкие колебания цен.
2. Harmony: Атака повторного воспроизведения
Harmony — это Layer 1 с поддержкой шардинга, работающая с четырьмя шардами и использующая асинхронный межшардовый механизм на основе квитанций для передачи активов между ними. Исходный шард генерирует криптографические квитанции для исходящих транзакций, а целевой шард проверяет, соответствует ли эта квитанция и её доказательство Меркла подписанному заголовку исходного блока, прежде чем зафиксировать транзакцию; каждая квитанция может быть использована только один раз.
Уязвимость, использованная в этой атаке, существует в устаревшей части системы фрагментации Harmony. Ранее Harmony проверяла, был ли фрагментированный чек уже использован, просматривая два поля: CXMerkleProof.ShardID и BlockNum.
Поскольку эти два поля находятся за пределами подписанного заголовка блока, злоумышленник может изменить их, не нарушая работу существующих функций. В ходе этой атаки злоумышленник получил кросс-шардный чек и изменил в нем ShardID и BlockNum, чтобы проверяющая программа распознала его как совершенно новый чек. Целевой шард принял измененный чек и зафиксировал его повторно, в то время как исходный шард не списал соответствующие активы.
Это очень типичная атака повторного воспроизведения. Для любого поля, используемого в качестве «маркера одноразового использования», необходимо, чтобы оно было частью подписанной заголовочной информации. При проверке квитанции идентификатор фрагмента и номер блока следует считывать непосредственно из подписанного заголовка блока, а не полагаться на неаутентифицированные поля в структуре доказательства.
3. Term Finance: Атака на управление
Term Finance — это DeFi-протокол для кредитования по фиксированной ставке, где каждый волют (Vault) представляет собой ERC-4626 Vault на основе кода Yearn V3. Управление волютами Term Finance осуществляется не через одобрительное голосование, а через голосование против. Когда куратор предлагает предложение по изменению параметров, система открывает окно, в течение которого держатели LP-токенов могут выразить возражения. При этом порог для голосования по управлению имеет серьезную уязвимость:
● Отсутствие абсолютного порога голосов или капитала: условия прохождения предложения isSupportThresholdReached() и isMinParticipationReached() проверяют только относительные доли, а не абсолютное количество голосов. Это означает, что предложение может быть одобрено при наличии относительного большинства, независимо от общего числа участников или общего объема капитала, за который были поданы эти голоса.
● Очень низкая вовлеченность: практически ни один депозитор не заключил в токен управления (gtmvETH) доли в казначействе (tmvETH) для участия в голосовании. Это привело к чрезвычайно низкому общему предложению токенов управления для соответствующего казначейства.
Злоумышленник использовал вышеуказанный дефект проектирования для осуществления атаки на управление сейфом с крайне низкими затратами:
(1) Получение права голоса: атакующий обменял около 0,5 ETH на около 0,485 доли в хранилище tmvETH и заключил их 1:1 в виде 0,485 токенов управления gtmvETH, получив право голоса.
(2) Внесение злонамеренного предложения: при создании предложения контракт зафиксировал общее количество управляющих токенов всего в 0,535 gtmvETH. Это означает, что持有的 0,485 gtmvETH составляют 90,66% от общего объема.
(3) Голосование и выполнение: атакующий, будучи единственным голосующим, подал голос «за». Поскольку противных голосов не было, его поддержка значительно превысила порог в 50%; одновременно его личный вес голоса превысил минимальный порог участия (minVotingPower), рассчитанный на основе крайне низкой общей эмиссии.
(4) Извлечение активов: После принятия предложения было выполнено вредоносное действие по извлечению активов (WETH) из хранилища
Злоумышленники с помощью аналогичной методики взломали 6 хранилищ Term Finance, причинив ущерб на сумму около 8,5 млн долларов США.
Эта атака также является типичным примером атаки на управление протоколом в цепочке. Для управления в цепочке проекту следует установить следующие контрольные точки для предотвращения:
● Установите абсолютное количество голосов или минимальный капитал: предложения по управлению не могут одобряться исключительно на основе относительных пропорций. Должен быть установлен жесткий порог на основе абсолютного количества, например, требование, чтобы голоса «за» достигали определенной суммы (например, 1 млн долларов США) или количества независимых адресов.
● Настройте для таймлока опекуна или путь отмены: хотя выполнение управления обычно имеет задержку, это лишь предоставляет определенное время для реакции. Проект должен обеспечить эффективный механизм опекуна (Guardian) или путь отмены предложения в течение периода задержки. Если в течение периода задержки будет обнаружено вредоносное предложение, опекун может немедленно вмешаться и отменить его.
● Мониторинг участия в управлении: протокол должен обеспечивать постоянный мониторинг уровня участия в управлении каждым казначейством. При обнаружении аномально низкого уровня общего предложения токенов управления или участия в голосовании в каком-либо казначействе следует своевременно отправлять оповещения и даже автоматически запускать защитные меры.
Тренды угроз безопасности Web3
Самые глубокие тенденции в области безопасности Web3 в 2026 году — это систематическое расширение поверхности атак. Уязвимости возникают одновременно на уровне кода, повседневной операционной деятельности и взаимодействий, и одних лишь нескольких аудитов безопасности или инструментов недостаточно для покрытия уязвимостей в операционной безопасности, блокчейн-управлении и бизнес-логике. Это создает новые вызовы для проектов Web3 в построении систем защиты.
Кроме того, атаки на DeFi-контракты и личных пользователей происходят часто. Уязвимости контрактов или авторизации легко могут быть использованы злоумышленниками; разработчики или операторы контрактов должны повторно проверить безопасность контрактов, а для контрактов, обрабатывающих ключевые бизнес-процессы, следует проводить многократные и многосторонние аудиты безопасности. Для личных пользователей рекомендуется регулярно проверять и отменять авторизации контрактов, которые больше не используются, с помощью блокчейн-браузеров или инструментов отзыва авторизации, а также лучше изучать распространенные и новые методы фишинга, чтобы повысить уровень осведомленности о безопасности.
Этот текст подготовлен командой безопасности Beosin на основе системы предупреждений безопасности Beosin Alert, данных в блокчейне и публичного анализа после инцидента от команды проекта. Если у вас есть какие-либо вопросы, пожалуйста, свяжитесь с нами для обратной связи.