Из сети Zilliqa увели 683 130 969,66 токена ZIL с 6772 адресов. Причина, установленная разбором инцидента, обидна до неприличия: приложение при формировании подписи копировало не те 32 байта — оставляло восемь байт нулевого дополнения и выбрасывало восемь байт настоящей случайности. Каждая подпись после этого протекала, и примерно пяти подписей хватало, чтобы восстановить приватный ключ на обычном компьютере.

Коротко: что произошло

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

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

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

Масштаб инцидента

Подписи в EVM-режиме и официальные библиотеки разработчика уязвимости не содержали.

Почему опасен не алгоритм, а код вокруг него

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

Сама криптография здесь не подвела. Подвело копирование байтов — восемь позиций сдвига в буфере. Между «схема стойкая» и «реализация стойкая» лежит расстояние, которое пользователю не видно вообще никак.

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

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

Что из этого следует держателю

Первое: «холодное хранение» защищает от кражи ключа, но не от его вычисления по вашим же подписям. Это разные угрозы, и вторая не отменяется покупкой устройства.

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

Третье: концентрация выводов показательна — 80,6% украденного ушло на один адрес биржи. Общие правила самостоятельного хранения разобраны в материале про свои ключи, а про то, что обновление прошивки не всегда спасает, мы писали, когда разбирали случай Coldcard.

Чего в источниках нет

Не приводится долларовая оценка ущерба: сумма названа в токенах, курс на моменты списаний не раскрыт.

Не сообщается, будут ли пострадавшим возмещать потери и за чей счёт.

Не названа и биржа, на адрес которой пришлось 80,6% выведенного, а также не указано, заморожены ли эти средства.

Частые вопросы

Сколько украдено?

683 130 969,66 ZIL с 6772 адресов. Из них 550 558 587,25 токена — 80,6% — ушло на один адрес биржи.

В чём была ошибка?

При копировании в буфер брались не те 32 байта: оставались восемь байт нулевого дополнения и терялись восемь байт настоящей случайности.

Почему это позволяет украсть ключ?

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

Какие версии затронуты?

Все выпущенные с 2019 по 2026 год, но только путь подписи «родных» транзакций. EVM-режим и официальные библиотеки не задеты.

Когда это прекратилось?

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

Защищает ли аппаратный кошелёк от такого?

Не в этом случае. Устройство защищает хранение ключа, а утечка происходила через подписи, которые формировало приложение.

Источники

Материал подготовлен на основе разбора инцидента самой Zilliqa, публикации CryptoSlate и сообщения The Crypto Times о раскрытии уязвимости.