Zero-day уязвимости: что это и как защититься (чек-лист)

Zero-day (уязвимость нулевого дня) — это ранее неизвестная ошибка в ПО или железе, для которой ещё нет исправления (патча), но уже может существовать или действительно используется рабочий эксплойт. Такие уязвимости особенно опасны: защитные средства не знают сигнатур, а окно реагирования минимально.

Зачем это важно

Zero-day дают злоумышленнику преимущество «скрытности» и высокую вероятность успешной атаки.

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

Даже аккуратные пользователи уязвимы из-за промежутка между раскрытием и установкой патча (patch gap) и из-за цепочек поставок (обновления SDK, расширений браузера, CI/CD), см. Supply-chain атаки.

Ключевые понятия и «жизненный цикл»

Уязвимость — ошибка в логике, управлении памятью, проверках прав и т. п. (в браузере, ОС, драйвере, криптобиблиотеке, кошельке).

Эксплойт — практическая техника/код для эксплуатации уязвимости (RCE, LPE, sandbox escape и др.).

Нулевой день — момент до публичного раскрытия и выпуска патча; далее уязвимость становится n-day (известной).

Рынок эксплойтов — серые/чёрные брокеры, частные исследования, баг-баунти. Ответственная модель раскрытия — уведомление вендора и ожидание патча.

Жизненный цикл атаки (упрощённо):

Поиск уязвимости → приватная разработка эксплойта → ограниченное применение «в тишине» → индикаторы замечены → выпуск патча → массовые попытки эксплуатации уже известной n-day против не обновившихся систем.

Как это работает (по шагам)

Вектор входа. Фишинг-линк, уязвимое вложение, вредоносное расширение, баг в обработчике контента, открытые отладочные интерфейсы (см. JDWP), уязвимый RPC/JSON-API.

Первичное выполнение. Например, RCE в браузере/мессенджере/почтовом клиенте или LPE для повышения привилегий.

Закрепление и обход защит. Боковое перемещение, кража сессий, внедрение в автообновления, отключение EDR/антивирусов.

Достижение цели. Для крипто: кража ключей из горячих процессов/плагинов, подмена адресов/UI, несанкционированные транзакции, компрометация билда кошелька, атака на валидатора/нод.

Сокрытие следов. Чистка логов, минимизация артефактов, короткие «точечные» операции до начала массового детекта.

Типовые сценарии для криптопроектов

Горячие кошельки и расширения браузера. Эксплойт в движке JS/WebAssembly или расширении даёт доступ к закрытым ключам и сессиям dApp. Снизить риск: хранить основные активы в аппаратном кошельке, горячие — минимально, включить 2FA там, где возможно.

Биржевой фронтенд/мобильное приложение. Zero-day в WebView/JS-движке или в цепочке обновлений — подмена UI и подписей. Помогает независимая верификация адресов, ограничение прав приложений, PoR-подходы к контролю резервов (Proof of Reserves (PoR) — как биржи «доказывают» резервы: Merkle-дерево и ограничения).

Инфраструктура нод/валидаторов. Уязвимости в RPC, пирах, клиентах и их зависимостях: последствия — двойные расходы ресурсов, цензура, кражи вознаграждений. Меры: изоляция, минимизация поверхности, быстрое патчирование, мониторинг отклонений.

DevOps и CI/CD. Компрометированный билд-сервер или зависимость превращают обновление в троянскую лошадь (см. Supply-chain атаки — как защитить криптопроекты).

Контуры защиты: что реально работает

Контур Что делать Комментарий
Архитектура Разделение холодных/горячих ключей (горячие vs аппаратные), лимиты на вывод, мультиподпись multisиг. Уменьшает ущерб при взломе клиента.
Доступы Принцип наименьших привилегий, отдельные учётки/роллинг-ключи, запрет удалённой отладки (см. JDWP (Java Debug Wire Protocol): что это и как защитить прод). Снижает эффект LPE/RCE.
Обновления Политика ускоренного патчинга критичных компонентов; staged-развёртывание с откатом. Сокращает patch gap.
Верификация Подписи релизов, reproducible builds, контроль целостности расширений/SDK. Против supply-chain и подмен.
Мониторинг Блок-лист подозрительных доменов, поведенческий детект, алерты по аномалиям транзакций. Раннее обнаружение инцидента.
Пользовательские меры Self-custody с аппаратным подписью, офлайн-хранение seed-фразы, проверка адресов на девайсе. Делает кражу ключа гораздо сложнее.

Плюсы / риски

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

Практика реагирования (чек-лист)

Зафиксируйте версию ОС/ПО, хеши бинарей, сессии браузера; отключите сеть на скомпрометированной машине.

Быстро обновите ОС/браузер/кошелёк/клиенты нод; проверьте целостность установочных пакетов и подписей.

Ревизуйте ключи: перевыпуск и перенос вредно-экспонированных; временно переведите средства на адреса с мультиподписью и аппаратным подтверждением.

Проверьте правила вывода и лимиты; включите/перепривяжите 2FA.

Просмотрите логи авторизации/транзакций; настройте оповещения об исходящих переводах.

Сообщите вендору/поддержке сервиса, при необходимости — в программу баг-баунти/VDP; документируйте таймлайн.

FAQ

Чем Zero-day отличается от n-day? Zero-day неизвестна публично и/или вендору; для n-day уже есть CVE/патч и её массово эксплуатируют против не обновившихся.

Как понять, что эксплойтится Zero-day? Косвенные признаки: атаки обходят антивирус/EDR, нет упоминаний в бюллетенях безопасности, артефакты указывают на новую технику. Полагайтесь на телеметрию и срочное патчирование.

Что делать обычному пользователю? Держать основные активы в аппаратном кошельке, обновлять ПО сразу, не хранить крупные суммы в браузерных расширениях/мобильных кошельках, проверять адрес на устройстве-подписанте, включать 2FA.

Zero-day — это только про браузеры? Нет. Это любые слои: ядро ОС, драйверы, криптобиблиотеки, кошельки, клиенты нод, CI/CD, API-шлюзы.

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

См. также

Supply-chain атаки — как защитить криптопроекты

Смарт-контракт — программируемые правила в блокчейне

Proof of Reserves — прозрачность резервов

Оракулы — как блокчейн получает внешние данные

Двухфакторная аутентификация (2FA)

Аппаратный кошелёк — безопасное self-custody

Горячий кошелёк — повышенные риски

Self-custody — хранение на собственных ключах

Мультиподпись — кворум ключей

Seed-фраза — резервный доступ

Task Runner