~$4M потеряно: эксплойты Taiko и SecondFi

За прошедшую неделю (2026/06/22 - 2026/06/28) было выявлено 2 значимых инцидента безопасности, повлёкших подтверждённые потери в размере около $4,1 млн.

Дата	Инцидент	Тип	Оценочные потери
2026/06/22	Taiko	Компрометация ключа и ненадлежащая валидация	~$1,7 млн
2026/06/23	SecondFi	Уязвимость криптографической реализации	~$2,4 млн

Taiko: Злоумышленник совместил раскрытый ключ подписи SGX-анклава с неполной политикой аттестации, чтобы зарегистрировать вредоносный прувер в качестве авторизованного экземпляра, продемонстрировав, что одной лишь корректной аттестации недостаточно без комплексного применения атрибутов.
SecondFi: Уязвимость криптографической реализации позволила злоумышленникам восстановить ключи подписи на уровне адресов, используя только публичные данные транзакций, продемонстрировав, как, казалось бы, незначительное отклонение от спецификации Ed25519 может привести к полной компрометации ключа.

Главное событие недели: инцидент с Taiko

Инцидент с Taiko выделен, поскольку атака совмещала два независимых сбоя безопасности (раскрытый ключ подписи анклава и неполная политика аттестации) для компрометации системы верификации доказательств на основе SGX. Инцидент демонстрирует, что каждый уровень цепочки доверия TEE должен независимо применять свои свойства безопасности; корректная цепочка подписей аттестации не компенсирует непроверенные атрибуты среды выполнения.

22 июня 2026 года поток верификации доказательств на основе SGX в Taiko был взломан в сети Ethereum, что привело к потерям в размере около $1,7 млн [1]. Злоумышленник использовал раскрытый приватный ключ подписи анклава, который был зафиксирован в публичном репозитории GitHub, для подписи SIGSTRUCT прувер-анклава, запущенного в режиме DEBUG. Поскольку контракт аттестации в сети не отклонял анклавы в режиме DEBUG, злоумышленник зарегистрировался в качестве авторизованного экземпляра, отправил поддельные данные доказательства и вынудил L1-контракты принять несуществующее состояние L2 и освободить средства из моста.

Предыстория

Taiko — это роллап Ethereum Layer-2 с мостом, который опирается на систему доказательств для принятия решений о том, следует ли принимать то или иное состояние L2 или кросс-чейн сообщение. В рамках этой системы доказательств Taiko использует SGX-пруверы: off-chain программы, выполняющиеся внутри SGX-анклавов на физических машинах, которые подписывают результаты доказательств ключами, защищёнными анклавом.

Off-chain (физическая машина)               On-chain (Ethereum)
┌─────────────────────────┐                ┌────────────────────────────────────┐
│  SGX Prover Enclave     │                │  SgxVerifier                       │
│  - генерирует доказат.  │── DCAP quote ─→│  ├─ registerInstance()             │
│  - хранит ключ экземпл. │                │  │  └─ AutomataDcapV3Attestation   │
│                         │── подп. доказ.→│  └─ verifyProof()                  │
└─────────────────────────┘                └────────────────────────────────────┘

Обзор SGX и DCAP

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

Приватный ключ подписи анклава подписывает SGX SIGSTRUCT, который содержит метаданные анклава, такие как MRENCLAVE, ISVPRODID, ISVSVN и ATTRIBUTES. Эта подпись не проверяется on-chain контрактом; она проверяется аппаратным обеспечением SGX в фазе EINIT при инициализации анклава. Процессор проверяет корректность подписи SIGSTRUCT и соответствие MRENCLAVE внутри неё измерению фактически загруженного анклава. Только после успешной верификации анклав может быть инициализирован и создавать последующие отчёты и цитаты.

Цитата Intel SGX DCAP v3 — это пакет удалённой аттестации, состоящий из трёх частей:

header: метаданные, такие как версия цитаты, тип ключа аттестации, SVN QE/PCE и поставщик.
localEnclaveReport: идентификатор аттестованного анклава приложения, включая MRENCLAVE, MRSIGNER, ATTRIBUTES, ISVPRODID, ISVSVN и reportData. reportData — 64-байтовое значение, записываемое анклавом при генерации отчёта. Taiko хранит адрес экземпляра прувера в первых 20 байтах reportData.
v3AuthData: доказательство подлинности цитаты, включающее подпись цитаты, ключ аттестации, отчёт QE, подпись отчёта QE и цепочку сертификатов PCK.

On-chain аттестация

Контракт on-chain аттестации (AutomataDcapV3Attestation, отвечающий за удалённую аттестацию) проверяет подлинность цитаты через цепочку сертификатов Intel DCAP. Хотя открытые ключи эмитентов в цепочке сертификатов предоставляются как часть внешне представленной цитаты, контракт верифицирует цепочку пошагово и требует, чтобы хэш открытого ключа финального эмитента совпадал с хэшем открытого ключа Intel SGX Root CA, зафиксированным в контракте [2]. Посредством этой цепочки контракт подтверждает, что localEnclaveReport, охваченный подписью цитаты, не был произвольно изменён в calldata.

Регистрация прувера Taiko

Экземпляр SGX-прувера должен быть предварительно зарегистрирован через SgxVerifier.registerInstance(). В процессе регистрации вызывающая сторона отправляет DCAP-цитату. SgxVerifier делегирует валидацию цитаты AutomataDcapV3Attestation.verifyParsedQuote(). При успешном прохождении цитаты SgxVerifier считывает первые 20 байт localEnclaveReport.reportData как адрес экземпляра и добавляет его в авторизованный набор экземпляров.

Поток верификации подписи можно упростить до трёх уровней:

Процессор SGX проверяет подпись SIGSTRUCT в процессе EINIT, подтверждая MRENCLAVE анклава и идентификатор подписанта.
Цепочка сертификатов DCAP и отчёт QE аутентифицируют ключ подписи цитаты. Затем AutomataDcapV3Attestation использует этот ключ для верификации подписи цитаты и установления доверия к localEnclaveReport.
Верификатор доказательств Taiko использует зарегистрированный адрес экземпляра для верификации последующих подписей доказательств и принятия решения о принятии соответствующего состояния L2 или кросс-чейн сообщения.

Анализ уязвимости

Первопричина данного инцидента — сочетание операционного сбоя и уязвимости на уровне контракта. Оба фактора были необходимы для успешной атаки.

Операционный сбой: раскрытый ключ подписи анклава. Приватный ключ подписи анклава, используемый Taiko/Raiko для подписи SGX SIGSTRUCT, был зафиксирован в публичном репозитории GitHub. MRSIGNER — хэш соответствующего открытого ключа подписи. Любой, кто получит этот приватный ключ, может подписать SIGSTRUCT анклава прувера, в результате чего MRSIGNER в итоговой цитате будет совпадать со списком разрешений Taiko.

Уязвимость контракта: отсутствие проверки ATTRIBUTES. При совпадении MRSIGNER (прохождение списка разрешений через раскрытый ключ) злоумышленник мог запустить тот же одобренный анклав в режиме DEBUG, не изменяя MRENCLAVE (флаг DEBUG не является частью MRENCLAVE). Политика аттестации должна была обнаружить это, однако AutomataDcapV3Attestation (0x5e46...dd72) не проверяла localEnclaveReport.attributes анклава приложения. Анклав в режиме DEBUG позволяет хосту или отладчику читать или изменять память анклава, а значит, ключ подписи экземпляра, который должен был быть защищён анклавом SGX, более не является безопасным.

В совокупности эти два условия означают, что любая сторона может запустить тот же код анклава прувера в режиме DEBUG (производя тот же MRENCLAVE, что и легитимная сборка) и, используя раскрытый ключ подписи, подписать SIGSTRUCT, который заставляет MRSIGNER совпасть со списком разрешений Taiko. Итоговая цитата удовлетворяет спискам разрешений как для MRENCLAVE, так и для MRSIGNER, при этом содержа непроверенный атрибут DEBUG. Поскольку AutomataDcapV3Attestation не отклоняет атрибут DEBUG, такая цитата проходит verifyParsedQuote(), после чего SgxVerifier регистрирует адрес экземпляра в авторизованном наборе.

Анклав в режиме DEBUG не защищает свою память от хоста или отладчика. Следовательно, приватный ключ экземпляра, сгенерированный внутри анклава, может быть извлечён. Имея этот ключ, его обладатель может подписывать произвольные данные доказательств, которые L1-контракты будут принимать, что открывает возможность для подделки переходов состояния L2 и несанкционированного освобождения средств из хранилища моста (0x9962...15ab).

Анализ атаки

Злоумышленник отправил несколько транзакций. Следующий анализ основан на двух показательных транзакциях: первая зарегистрировала злоумышленника в качестве авторизованного экземпляра (0x2f44dc...277260), вторая выполнила поддельное доказательство для кражи активов (0x017292...ae35ee).

Шаг 1: Используйте раскрытый ключ подписи анклава для подписи SIGSTRUCT, чтобы MRSIGNER цитаты совпадал со списком разрешений.
Шаг 2: Запустите анклав с атрибутом DEBUG. DEBUG не изменяет MRENCLAVE, однако отражается в localEnclaveReport.attributes.
Шаг 3: Вызовите registerInstance() и отправьте реальную SGX-цитату. Цитата имела attributes = 0x07..., включающие бит DEBUG (0x02), однако AutomataDcapV3Attestation не проверяла это поле, поэтому verifyParsedQuote() вернул true.

Шаг 4: Извлеките приватный ключ экземпляра из памяти SGX-анклава (возможно, поскольку режим DEBUG отключает защиту памяти) и используйте его для подписи вредоносных данных доказательства.
Шаг 5: Отправьте сфабрикованное доказательство, чтобы заставить L1-контракты принять несуществующее состояние L2 и похитить активы из хранилища.

Заключение

Полная политика аттестации SGX должна как минимум:

Отклонять SGX_FLAGS_DEBUG в производственных средах.
Проверять MRENCLAVE, MRSIGNER, ISVPRODID и ISVSVN.

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

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

Ссылки

[1] Оповещение Phalcon: обнаружение эксплойта моста Taiko
[2] Руководство разработчика Intel SGX

Другие инциденты недели

Инцидент с SecondFi

23 июня 2026 года SecondFi (ранее Yoroi), кошелёк Cardano, разработанный EMURGO, раскрыл критическую уязвимость в своей реализации подписи Ed25519 [1]. Реализация подписи в кошельке вычисляла нонс подписи только из публичного сообщения транзакции, опуская обязательный секретный входной параметр. Это свело цифровую подпись к задаче с одним уравнением, позволив злоумышленникам восстановить приватные ключи на уровне адресов из публичных on-chain данных. Два отдельных злоумышленника воспользовались уязвимостью, опустошив около $2,4 млн (16 млн ADA) из 374 кошельков [2].

Предыстория

SecondFi — самостоятельный кошелёк для блокчейна Cardano, переименованный из Yoroi в апреле 2026 года. Изначально разработанный EMURGO, одной из трёх основополагающих организаций Cardano, Yoroi ранее обслуживал более одного миллиона пользователей.

Ed25519 — это схема цифровой подписи, используемая Cardano для авторизации транзакций. Подписант владеет скалярным значением подписи $k_{L}$ (приватным ключом для конкретного адреса) и секретным префиксом нонса $k_{R}$ , связанным с тем же ключевым материалом. Для заданного сообщения $M$ (полезной нагрузки транзакции) нонс подписи вычисляется как $r = \operatorname{SHA-512}(k_R \mathbin\Vert M) \bmod L$ . Поскольку $k_{R}$ является секретным, $r$ остаётся неизвестным наблюдателям, даже несмотря на то, что $M$ становится публичным после трансляции.

Точка нонса $R = r \cdot B$ (где $B$ — фиксированная базовая точка Ed25519) и скалярное значение подписи $s \equiv r + H \cdot k_L \pmod{L}$ (где $H = \operatorname{SHA-512}(R \mathbin\Vert A \mathbin\Vert M) \bmod L$ связывает нонс, открытый ключ и сообщение) образуют итоговую подпись $(R, s)$ . Безопасность схемы зависит от непредсказуемости $r$ : если наблюдатель может вычислить $r$ , уравнение подписи превращается в линейное уравнение с одним неизвестным, разрешимое относительно $k_{L}$ .

Анализ уязвимости

Данная уязвимость находится в программном обеспечении кошелька SecondFi, а не в смарт-контракте.

Объединив существующий анализ [2] с собственным расследованием, мы обнаружили, что затронуты версии с v10.0.3 по v10.0.6 (действовавшие с 8 июня 2026 года; исправлено в v10.0.6.2). Уязвимая реализация вычисляла нонс подписи как:

r = \operatorname{SHA-512}(M) \bmod L

вместо корректного:

r = \operatorname{SHA-512}(k_R \mathbin\Vert M) \bmod L

Это устранило единственный секретный входной параметр ( $k_{R}$ ) из процесса получения нонса. Поскольку $M$ является публичным, любой может пересчитать $r$ для любой транзакции, подписанной затронутым адресом.

При известном $r$ уравнение подписи $s \equiv r + H \cdot k_L \pmod{L}$ становится разрешимым:

k_L \equiv (s - r) \cdot H^{-1} \pmod{L}

Все значения в правой части либо являются публичными, либо вычисляются из on-chain подписи и данных транзакции. Это не обратная функция хэша и не решение задачи дискретного логарифма из $A = k_L \cdot B$ ; уязвимая реализация напрямую раскрывала $r$ , сводя восстановление ключа к прямым модульным вычислениям.

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

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

Анализ атаки

Данная атака не следует типичной последовательности on-chain эксплойта с отслеживаемыми взаимодействиями со смарт-контрактами. Поскольку уязвимость раскрывает детерминированную зависимость между публичными данными и ключом подписи, восстановление ключа выполняется в офлайн-режиме.

Шаг 1: Определите целевые адреса, подписавшие транзакции с использованием SecondFi v10.0.3 — v10.0.6.
Шаг 2: Для каждой цели извлеките публичные компоненты подписи транзакции ( $R$ , $s$ ) и восстановите сообщение $M$ из полезной нагрузки on-chain транзакции.
Шаг 3: Вычислите нонс подписи $r = \operatorname{SHA-512}(M) \bmod L$ , используя тот факт, что уязвимая реализация подписи опускала секретный префикс нонса $k_{R}$ .
Шаг 4: Вычислите скалярное значение задачи $H = \operatorname{SHA-512}(R \mathbin\Vert A \mathbin\Vert M) \bmod L$ .
Шаг 5: Вычислите скалярное значение подписи: $k_L \equiv (s - r) \cdot H^{-1} \pmod{L}$ .
Шаг 6: Используйте восстановленный $k_{L}$ для подписи произвольных транзакций со скомпрометированного адреса и перевода средств на кошельки, контролируемые злоумышленником.

Два отдельных злоумышленника независимо воспользовались данной уязвимостью. Один скомпрометировал 171 кошелёк в двух волнах, тогда как второй опустошил 203 кошелька в отдельной атаке, совокупно извлекув около 16 млн ADA (~$2,4 млн) [2]. Впоследствии EMURGO спасла ещё 129 млн ADA до того, как злоумышленники успели до них добраться.

Заключение

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

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

Ссылки

[1] Раскрытие информации SecondFi после инцидента
[2] Tibane Labs: криминалистический анализ SecondFi Cardano

О BlockSec

BlockSec — поставщик комплексных решений в области безопасности блокчейна и соответствия требованиям в сфере криптовалют. Мы создаём продукты и сервисы, которые помогают клиентам проводить аудит кода (включая смарт-контракты, блокчейн и кошельки), перехватывать атаки в режиме реального времени, анализировать инциденты, отслеживать незаконные средства и выполнять обязательства в области ПОД/ФТ на протяжении всего жизненного цикла протоколов и платформ.

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