Статья Уязвимость нулевого дня в мессенджерах: ZDI-CAN-30207 в Telegram и методология охоты на zero-day баги

Март 2026 года. Исследователь публикует идентификатор ZDI-CAN-30207, заявляя о критической zero-click уязвимости в Telegram с оценкой CVSS 9.8 из 10. Telegram в ответ: угрозы нет, исследователь ошибается. На заборе тоже написано. Публичное раскрытие деталей отложено до июля, миллионы пользователей сидят в информационном вакууме, а исследователи безопасности - перед закрытой дверью. Эта статья - карта всего, что известно о ZDI-CAN-30207, и пошаговое руководство по поиску подобных уязвимостей в мессенджерах. Для тех, кто хочет найти следующий zero-day сам.

Карта темы: от конкретного бага до системной методологии​

• Что такое ZDI-CAN-30207 - хронология событий, подтверждённые факты и открытые вопросы
• Поверхность атаки мессенджеров - где прячутся баги в Telegram, Signal, WhatsApp
• Медиапарсеры как главный вектор - почему парсинг стикеров, изображений и видео порождает критические уязвимости
• Zero-click vs. one-click - разница между «жертва ничего не делала» и «жертва открыла файл»
• Реверс-инжиниринг десктопных клиентов - IDA Pro, Ghidra, x64dbg на практике
• Фаззинг медиаформатов - AFL++, libFuzzer, собственные harness-ы для Telegram-парсеров
• Процесс ZDI: от находки до disclosure - как устроен Zero Day Initiative изнутри
• Баг-баунти мессенджеров - программы, выплаты, подводные камни
• Защита и детекция - что делать пользователям и администраторам прямо сейчас

ZDI-CAN-30207: хронология, факты и зона неизвестности​

Что подтверждено​

26 марта 2026 года исследователь безопасности отправил в Zero Day Initiative отчёт об уязвимости нулевого дня в мессенджере Telegram. ZDI присвоила идентификатор ZDI-CAN-30207 - отчёт принят, уязвимость прошла первичную верификацию. Оценка критичности - 9.8 балла по шкале CVSS 3.1, категория Critical, выше некуда. Официального CVE-идентификатора и подтверждённого NVD score на момент публикации нет: CVSS становится официальным после присвоения CVE и анализа NVD/CNA, а не на этапе ZDI-CAN.

По информации SecurityAffairs и Dark Reading, уязвимость затрагивает Telegram на Android и Linux. Заявлена возможность полного захвата устройства. Характер связан с обработкой медиаконтента - предположительно, анимированных стикеров.

Публичное раскрытие технических деталей (disclosure) назначено на 24 июля 2026 года, если вендор не устранит проблему раньше.

Позиция Telegram​

Команда Telegram публично оспорила выводы исследователя. На Хабре заявили: «исследователь ошибочно утверждает, что для атаки можно использовать стикер с вредоносным кодом». Telegram указал на серверную фильтрацию: все анимированные стикеры проходят серверную обработку и конвертацию, что теоретически не даёт вредоносному контенту добраться до клиента.

Спорный момент. Серверная фильтрация действительно может нейтрализовать ряд атак на парсеры, но:

• Серверная конвертация сама может быть обойдена при определённых условиях
• Не все медиаформаты проходят одинаковую обработку
• Уязвимость может сидеть не в парсере формата, а в логике обработки метаданных после фильтрации

До публичного disclosure невозможно определить, кто прав. Типичная ситуация для сложных vulnerability disclosure кейсов - и лично я видел случаи, когда правы оказывались обе стороны, просто смотрели на разные участки кода.

Что остаётся неизвестным​

Не опубликованы: CVE-идентификатор (ZDI-CAN - внутренний номер ZDI, не CVE), PoC-эксплойт, технический root cause analysis, точный компонент уязвимого кода. Всё, что идёт ниже в разделах методологии - системный подход к поиску аналогичных уязвимостей, а не реконструкция конкретного эксплойта ZDI-CAN-30207.

Поверхность атаки мессенджеров: 7 зон, где живут zero-day баги​

Современный мессенджер - это браузер, медиаплеер, VoIP-клиент и файловый менеджер, запиханные в один APK или бинарник. «Просто чат» - это лет пятнадцать назад закончилось. Каждая функция расширяет поверхность атаки.

Полная карта attack surface типичного мессенджера:

Зона атаки	Компоненты	Типичные классы уязвимостей	Пример из истории
Медиапарсеры	libwebp, ffmpeg, Lottie, собственные кодеки	Heap overflow, OOB read/write, integer overflow	CVE-2023-4863 (libwebp)
Протокол доставки	MTProto (Telegram), Signal Protocol, кастомные	Crypto-атаки, replay, downgrade	Прошлые проблемы MTProto 1.0
Превью ссылок	HTML-рендерер, парсер OG-тегов	SSRF, XSS, утечка IP	WhatsApp link preview leaks
Звонки (VoIP)	WebRTC, кастомные RTP-стеки	Buffer overflow, RCE через RTP	Pegasus через WhatsApp VoIP
Файловый обмен	Обработчики .apk, .exe, .py, архивов	Path traversal, symlink attacks	Telegram EvilVideo (2024)
Уведомления	Push-сервисы, фоновая обработка сообщений	Zero-click триггеры	NSO ForcedEntry (iMessage)
Авторизация/сессии	SMS-коды, QR-логин, сессионные токены	Session hijacking, MITM	SIM-swap атаки на Telegram

Для исследователя первый шаг - определить, какие зоны актуальны для целевого мессенджера. Telegram Desktop на Linux - приоритетны медиапарсеры, обработка файлов и протокольный уровень. Мобильный клиент - добавляются VoIP и push-уведомления.

Начинаете исследование мессенджера - составьте таблицу зон по этой модели. Для каждой зоны определите: какие библиотеки используются (вытаскивается через анализ зависимостей бинарника), какой код написан in-house (чаще содержит баги), что проходит серверную обработку (сложнее эксплуатировать), что обрабатывается только на клиенте (проще).

Медиапарсеры: почему обработка стикеров, картинок и видео - золотое дно для RCE​

Исторически, большинство критических zero-day уязвимостей в мессенджерах приходится на медиапарсеры. Три причины - и все железобетонные.

Сложность форматов. Контейнеры и кодеки (WebP, Lottie/TGS, MP4, WebM, HEIC) - тысячи строк парсинга бинарных структур. Каждое поле с длиной, каждый offset - потенциальный integer overflow. Библиотека libwebp, которую тянут за собой практически все мессенджеры, в 2023 году получила CVE-2023-4863 (CWE-787: Out-of-bounds Write, CVSS 8.8 HIGH) - heap buffer overflow в Huffman-декодере WebP. По NVD, вектор атаки требует взаимодействия пользователя (UI:R - открытие crafted HTML-страницы), но в мессенджерах WebP-изображения рендерятся автоматически при получении. Барьер фактически исчезает. Официально затронутые продукты по NVD - Google Chrome, Fedora, Debian; Signal, Telegram и другие мессенджеры зацепило опосредованно, через зависимость от libwebp.

Zero-click потенциал. Мессенджер обрабатывает стикер или изображение автоматически - показать превью, создать миниатюру, декодировать анимацию. Жертве не нужно кликать. Сообщение пришло - парсер сработал - уязвимость проэксплуатирована. Именно поэтому баги в медиапарсерах регулярно всплывают в атаках уровня nation-state (Pegasus, Predator).

Фрагментация реализаций. Telegram использует собственные обёртки над стандартными библиотеками, собственный формат TGS (на базе Lottie), собственную логику конвертации. Каждая такая «обёртка» - дополнительный слой кода, где может сидеть ошибка, даже если базовая библиотека чиста.

Формат TGS: что внутри telegram-стикера​

Анимированные стикеры Telegram - формат TGS, gzip-сжатый JSON, совместимый с Bodymovin/Lottie. Клиент распаковывает архив, парсит JSON, рендерит векторную анимацию. Цепочка:

Получение сообщения → Скачивание .tgs → gunzip → JSON parse → Lottie render → Отображение

Каждый этап - точка для исследования. Декомпрессия gzip уязвима к zip-бомбам или crafted-потокам. JSON-парсер - к глубокой вложенности или специальным Unicode-последовательностям. Lottie-рендерер - к вредоносным путям анимации, вызывающим OOB-доступ к памяти. Матрёшка, где каждый слой может оказаться дырявым.

Серверная vs. клиентская обработка​

Telegram утверждает, что стикеры проходят серверную фильтрацию и конвертацию. Архитектурно это грамотно - если сервер пересоздаёт файл, вредоносные данные теоретически удаляются. Но серверная обработка - не панацея:

• Не все типы контента проходят полную пересборку
• Серверный конвертер сам может транслировать вредоносные данные без изменений, если они лежат в «безопасном» по его мнению поле
• Обработка пользовательских аватаров, кастомных эмодзи и другого медиаконтента может идти по другому pipeline

Ищете баги в медиапарсерах мессенджера - начните с определения: какой контент проходит серверную обработку, а какой доставляется «как есть». Для Telegram проверяется элементарно: отправьте файл самому себе и сравните бинарное содержимое до и после передачи через серверы (два клиента + перехват трафика). Если хоть один байт совпадает - сервер не пересобирает файл целиком.

Zero-click vs. one-click: почему разница критична для оценки CVSS 9.8​

«Zero-click» - жертве не нужно совершать никаких действий. Ни кликать по файлу, ни открывать сообщение, ни даже разблокировать устройство. Сообщение пришло, мессенджер его обработал в фоне - всё, атака состоялась.

В случае ZDI-CAN-30207 характер взаимодействия с жертвой - один из ключевых открытых вопросов. Dark Reading описывает уязвимость как «no-click». Оценка CVSS 9.8 согласуется с zero-click RCE сценарием - это потолок.

Сравнение:

Характеристика	Zero-click	One-click	Требует установки
Действие жертвы	Никаких	Открыть файл/ссылку	Скачать и запустить
Типичный CVSS	9.0-10.0	7.0-9.0	5.0-7.0
Стоимость на рынке 0day	$500K - $2.5M+	$100K - $500K	$10K - $100K
Применение	Nation-state, целевые атаки	Фишинг, APT	Массовые кампании
Сложность разработки	Максимальная	Высокая	Средняя

Из предыдущих случаев zero-click в мессенджерах - атака ForcedEntry (NSO Group / Pegasus) через iMessage: вредоносный PDF мимикрировал под GIF и эксплуатировал JBIG2-парсер. Telegram в 2024 году столкнулся с эксплойтом EvilVideo - маскировка APK под видео на Android - но это one-click, жертва должна была открыть «видео».

При поиске уязвимостей оцените: какие данные обрабатываются до любого взаимодействия пользователя? Push-уведомления, превью контента, автозагрузка миниатюр - всё это потенциальные zero-click поверхности. Чем раньше в pipeline обработки сообщения происходит парсинг, тем выше шансы на zero-click вектор.

Реверс-инжиниринг Telegram Desktop: от бинарника к пониманию парсеров​

Telegram Desktop - open-source проект, но реальный продуктивный реверс начинается с бинарника, а не с исходников на GitHub. Почему: компилятор оптимизирует код, линковщик включает конкретные версии библиотек, а в релизных билдах вырезаны assert-ы и debug-проверки. Именно скомпилированный код крутится у пользователей - его и нужно препарировать.

Подготовка окружения​

Для анализа Telegram Desktop под Linux:

# Стягиваем бинарник из официального дистрибутива
wget https://telegram.org/dl/desktop/linux -O tdesktop.tar.xz
tar xf tdesktop.tar.xz
cd Telegram

# Смотрим, какие библиотеки прилинкованы
ldd Telegram | grep -E "(webp|ffmpeg|avcodec|lottie|zlib|png|jpeg)"

# Открываем в Ghidra для статического анализа
ghidraRun  # Импорт бинарника, Auto Analysis

ldd покажет, какие версии медиабиблиотек используются. Видите libwebp.so.7 - проверьте, уязвима ли эта версия к известным CVE. Базовый шаг, но рабочий.

Поиск функций обработки медиа​

В Ghidra или IDA Pro цель первого этапа - найти точки входа парсеров:

1. По строкам. Ищем "tgs", "webp", "lottie", "sticker", "animation" - они приведут к функциям обработки. В Ghidra: Search → For Strings → Filter
2. По импортам. Если libwebp линкуется динамически - ищем вызовы WebPDecode*, WebPGetInfo, WebPDecodeBGRA. Каждый вызов - место, где внешние данные попадают в библиотеку
3. По обработчикам сообщений. Telegram использует TL-схему для протокольных сообщений. Ищем обработчики типов messageMediaDocument, documentAttributeSticker, documentAttributeAnimated

Динамический анализ​

Для Linux-версии - GDB или Frida для трассировки:

# Перехват вызовов WebPDecode при получении стикера
# frida_hook_webp.js
Interceptor.attach(Module.findExportByName("libwebp.so.7", "WebPDecodeRGBA"), {
    onEnter: function(args) {
        console.log("[WebPDecodeRGBA] data ptr:", args[0], "size:", args[1].toInt32());
        // Дамп входных данных для дальнейшего анализа
        var buf = Memory.readByteArray(args[0], Math.min(args[1].toInt32(), 4096));
        send({type: "webp_input"}, buf);
    }
});

Для Windows: x64dbg с условными брейкпоинтами на функциях декодирования. В WinDbg удобно использовать Time Travel Debugging (TTD) - записываете сессию получения стикера, потом проигрываете назад от крэша к root cause. Этот зверь умеет перематывать время - бесценная штука, когда нужно понять, что именно убило процесс.

Начните реверс с поверхностного анализа зависимостей (ldd/dumpbin), затем найдите обработчики медиа по строковым сигнатурам, потом подключите динамический анализ для конкретного формата. Не пытайтесь проанализировать весь бинарник - фокусируйтесь на пути данных от получения сообщения до рендеринга контента.

Фаззинг медиаформатов мессенджеров: от harness до первого крэша​

Фаззинг - самый продуктивный метод поиска уязвимостей в парсерах. Идея примитивная: генерируем миллионы мутированных входных файлов и скармливаем их парсеру, отслеживая крэши. На практике всё упирается в качество harness-а и corpus-а. Плохой harness - месяц впустую. Хороший - первые крэши за часы.

Архитектура фаззинг-процесса для Telegram​

Corpus (валидные .tgs/.webp) → Мутатор (AFL++/libFuzzer) → Harness (изолированный парсер) → Sanitizers (ASAN/MSAN) → Crash triage

Шаг 1: Сбор corpus-а​

Corpus - набор валидных файлов, которые фаззер будет мутировать. Для Telegram-стикеров:

# Скачиваем стикерпаки через Telegram API
# Каждый .tgs файл - gzip-сжатый Lottie JSON
python3 -c "
from telethon import TelegramClient
import asyncio

async def grab_stickers(client):
    sticker_sets = await client.get_sticker_sets()
    for s in sticker_sets:
        for doc in s.documents:
            await client.download_media(doc, file=f'corpus/{doc.id}.tgs')

# ... client initialization
"

# Распаковываем для фаззинга JSON-парсера отдельно
mkdir corpus_json
for f in corpus/*.tgs; do
    zcat "$f" > "corpus_json/$(basename $f .tgs).json" 2>/dev/null
done

Шаг 2: Создание harness-а​

Harness - минимальная программа, которая вызывает целевой парсер. Для Lottie-рендерера Telegram (rlottie):

// harness_rlottie.cpp - пример для демонстрации концепции
#include <cstdint>
#include <cstdlib>
#include "rlottie.h"

extern "C" int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) {
    // Преобразуем входные данные в строку JSON
    std::string json_data(reinterpret_cast<const char*>(data), size);
  
    // Создаём анимацию из входных данных
    auto animation = rlottie::Animation::loadFromData(json_data, "", "", false);
  
    if (animation) {
        size_t width = 512, height = 512;
        auto buffer = std::make_unique<uint32_t[]>(width * height);
        rlottie::Surface surface(buffer.get(), width, height, width * 4);
      
        // Рендерим первый кадр
        animation->renderSync(0, surface);
    }
  
    return 0;
}

Компиляция с AddressSanitizer:

clang++ -g -O1 -fsanitize=fuzzer,address \
    -I/path/to/rlottie/inc \
    harness_rlottie.cpp \
    -L/path/to/rlottie/build -lrlottie \
    -o fuzz_rlottie

Шаг 3: Запуск и мониторинг​

# Запуск AFL++ с corpus-ом
AFL_USE_ASAN=1 afl-fuzz -i corpus_json -o findings -t 1000 -- ./fuzz_rlottie @@

# Или libFuzzer напрямую
./fuzz_rlottie corpus_json/ -max_len=1048576 -timeout=5

Шаг 4: Triaging крэшей​

Не каждый крэш - эксплуатабельная уязвимость. Сортировка:

1. Дедупликация. Группируем крэши по stack trace - AFL++ делает это автоматически через бакеты
2. Классификация. ASAN-отчёт покажет тип: heap-buffer-overflow, use-after-free, stack-buffer-overflow. Heap-overflow и UAF - самые перспективные для RCE
3. Воспроизводимость. Запускаем крэш-файл вне фаззера, подтверждаем стабильность
4. Exploitability. Контролируем ли мы данные, которые пишутся за границы буфера? Можем ли управлять размером аллокации? Есть ли примитив записи?

Фаззинг не требует глубокого понимания кода на старте, но требует корректного harness-а. Начните с библиотек, которые Telegram тянет для медиа (rlottie, ffmpeg, libwebp) - для них уже есть публичные harness-ы в Google OSS-Fuzz. Адаптируйте под актуальную версию, запускайте с собранным corpus-ом. Первые крэши обычно прилетают в течение нескольких часов. Если за сутки тишина - пересмотрите harness, скорее всего он не добирается до интересного кода.

Процесс Zero Day Initiative: как устроен путь от находки до публичного advisory​

ZDI-CAN-30207 - идентификатор формата ZDI-CAN, «candidate». Внутренний номер Zero Day Initiative, присваиваемый на этапе приёма отчёта. Понимание процесса ZDI критически важно, если планируете монетизировать найденные уязвимости.

Этапы процесса ZDI​

1. Submission. Исследователь отправляет отчёт через портал ZDI: описание уязвимости, PoC, затронутые версии, оценка импакта
2. Triage. Команда ZDI воспроизводит PoC в собственной лаборатории. Баг подтверждается - присваивается ZDI-CAN-XXXXX
3. Acquisition. ZDI предлагает выкуп за эксклюзивные права на уязвимость. Сумма зависит от критичности, популярности продукта и exploitability
4. Vendor notification. ZDI уведомляет вендора (здесь - Telegram). Стандартный срок на исправление - 120 дней
5. Patch или deadline. Вендор выпускает патч - ZDI публикует advisory. Не реагирует - ZDI публикует по истечении срока. Для ZDI-CAN-30207 disclosure назначен на 24 июля 2026; 26 марта - дата публичного упоминания, точная дата vendor notification неизвестна, но 120-дневное окно отсчитывается от неё
6. Publication. Публичный advisory с ZDI-XX-XXXX идентификатором. Полный PoC обычно не публикуется - только root cause и рекомендации

Почему вендор может оспаривать находку​

Ситуация «вендор говорит - уязвимости нет, ZDI - есть» не уникальна. Причины расхождений:

• Различия в threat model. Вендор считает серверная обработка блокирует вектор, исследователь нашёл обход
• Различия в оценке severity. Баг признают, но не считают критическим
• Репутация. Публичное признание zero-click RCE в мессенджере с сотнями миллионов пользователей - удар, которого хочется избежать
• Время на анализ. На момент первой реакции вендор мог не завершить собственный разбор

Telegram занял позицию «угрозы нет». Но факт принятия отчёта ZDI говорит: независимая верификация подтвердила наличие проблемы. Кто прав - узнаем в июле (или раньше, если выйдет тихий патч).

Нашли уязвимость в мессенджере - ZDI, HackerOne, Bugcrowd являются легитимными каналами disclosure. ZDI платит за эксклюзивность и берёт на себя коммуникацию с вендором. Для начинающих: качество PoC важнее красоты описания. Работающий эксплойт, стабильно воспроизводящийся на актуальной версии - основа принятия отчёта.

Баг-баунти мессенджеров: где искать, сколько платят, какие подводные камни​

Не все мессенджеры одинаково открыты для исследователей. Зоопарк программ баг-баунти - от щедрых до несуществующих.

Текущее состояние программ​

Мессенджер	Программа	Платформа	Выплаты за RCE	Особенности
Telegram	Официальная (ограниченная)	Собственная	Тарифы не публикуются	Нет публичной программы на HackerOne/Bugcrowd; связь через security@telegram.org. Для контекста: на рынке 0day (Zerodium) Telegram RCE/LPE chain оценивается до $500K
Signal	Официальная	Собственная	Не публикуют тарифы	Малая поверхность атаки, высокое качество кода
WhatsApp (Meta)	Meta Bug Bounty	HackerOne	До $300K за zero-click RCE	Крупнейшая программа, чёткие правила
Discord	Bug Bounty	HackerOne	До $10K-$25K	Фокус на веб-уязвимостях
Viber	Через Rakuten	HackerOne	Малые выплаты	Менее активная программа

Альтернативные каналы монетизации​

Если у мессенджера нет адекватной баг-баунти:

• ZDI - выкупает zero-day через собственную программу, выплаты за критические баги в популярных мессенджерах потенциально шестизначные
• Координированное раскрытие через CERT - CERT/CC, национальные CERT-ы выступают посредниками
• Публикация после disclosure deadline - если вендор отказывается исправлять, публикация повышает давление, но может иметь юридические последствия

Подводные камни​

Scope. Многие программы исключают «теоретические» уязвимости. Ваш PoC требует условий, которые вендор считает нереалистичными (как с серверной фильтрацией Telegram) - готовьтесь к отказу.

Duplicates. В крупных мессенджерах внутренние команды безопасности активно фаззят собственный код. Вероятность дубликата высокая, и это обидно.

Legal risk. Исследование протоколов мессенджеров может попадать под законодательство о несанкционированном доступе. Всегда действуйте в рамках публичной программы или координированного disclosure.

Начните с мессенджеров, имеющих публичные программы на HackerOne/Bugcrowd - чёткие правила и юридическая защита. Для Telegram: нашли что-то серьёзное - ZDI будет наиболее надёжным каналом с подтверждённой историей обработки отчётов (как показывает ZDI-CAN-30207).

Исторические zero-day уязвимости мессенджеров: паттерны, которые повторяются​

Анализ предыдущих инцидентов выявляет повторяющиеся паттерны. Знание этих паттернов - компас для поиска новых уязвимостей.

Паттерн 1: Библиотечные зависимости как слабое звено​

CVE-2023-4863 (libwebp, CWE-787: Out-of-bounds Write) - heap buffer overflow в Huffman-декодере WebP, CVSS 8.8 (HIGH). NVD-вектор указывает UI:R, но в мессенджерах автоматический рендеринг WebP-изображений фактически превращал это в zero-click. Официально затронуты Chrome, Fedora, Debian; мессенджеры (Signal, Telegram и другие) зацепило через зависимость от libwebp - одна уязвимость, десятки приложений. Обнаружили исследователи из Apple SEAR и Citizen Lab в контексте in-the-wild эксплуатации.

Вывод для методологии. Исследуйте не только код мессенджера, но и все библиотеки-зависимости. Найти уязвимость в libwebp выгоднее, чем в одном конкретном мессенджере - она затрагивает всех, кто эту библиотеку тянет.

Паттерн 2: Конвертация формата как вектор​

В 2024 году ESET обнаружил EvilVideo в Telegram для Android: сервер возвращал APK-файл с MIME-типом видео, клиент предлагал открыть его внешним плеером. Жертва видела «видео», а получала исполняемый файл. Красивый фантик, а внутри - APK.

Вывод для методологии. Граница между форматами - плодородная зона. Что происходит, когда мессенджер получает файл одного типа, но с расширением или MIME-типом другого? Как обрабатываются расхождения? Потренируйтесь на этом.

Паттерн 3: Протокольный уровень​

Уязвимости в реализации MTProto (собственный протокол Telegram) редко публикуются, но криптографы находили проблемы в ранних версиях: отсутствие проверки порядка сообщений, replay-атаки, слабости в key exchange. Понимание того, как криптография защищает данные в протоколах мессенджеров, помогает находить слабые места в нестандартных реализациях.

Вывод для методологии. Собственные криптографические протоколы - всегда подозрительны. Мессенджер использует не стандартный TLS/Signal Protocol, а кастомное решение - копайте туда в первую очередь. Своё крипто - почти всегда хуже чужого проверенного.

Паттерн 4: Desktop-клиенты менее защищены​

Мобильные ОС дают sandbox, ASLR, SELinux. Desktop-клиенты на Linux и Windows часто имеют больше привилегий и меньше уровней защиты. Не случайно ZDI-CAN-30207 затрагивает Android и Linux - наименее sandbox-ированные платформы из тех, где работает Telegram.

При планировании исследования составьте матрицу: {платформа × зона атаки × паттерн}. Пересечение с наибольшей исторической частотой: Linux Desktop + медиапарсер + библиотечная зависимость. Там наиболее вероятен следующий критический баг.

5 шагов методологии поиска zero-day в мессенджере: от нуля до отчёта​

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

Шаг 1: Разведка (1-2 дня)​

• Определите целевую платформу и версию
• Постройте карту зависимостей (ldd, otool -L, анализ build.gradle / CMakeLists.txt если open-source)
• Проверьте все зависимости на известные CVE через pip install osv-scanner или ручной поиск в NVD
• Составьте таблицу attack surface по модели из раздела выше

Шаг 2: Статический анализ (3-5 дней)​

• Откройте бинарник в Ghidra/IDA Pro
• Найдите парсеры медиаформатов по строковым сигнатурам и импортам
• Проследите data flow: откуда приходят данные (сеть), где парсятся, куда записываются
• Ищите классические паттерны: непроверенные длины, целочисленные переполнения, memcpy/malloc с контролируемым размером

Шаг 3: Фаззинг (1-4 недели)​

• Соберите corpus валидных файлов целевого формата
• Напишите harness, изолирующий парсер от остального приложения
• Запустите AFL++/libFuzzer с ASAN/MSAN
• Настройте параллельный запуск на нескольких ядрах
• Мониторьте покрытие кода - за сутки нет роста, пересмотрите harness

Шаг 4: Анализ крэшей и разработка PoC (1-2 недели)​

• Классифицируйте крэши по типу и exploitability
• Перспективные крэши - воспроизведите в полном клиенте мессенджера, а не только в harness-е
• Разработайте PoC с реальным импактом (утечка данных, DoS, RCE)
• Проверьте: работает ли PoC через реальную доставку сообщения, или только при локальном открытии файла?

Шаг 5: Отчёт и disclosure (1-3 дня)​

• Напишите отчёт: описание уязвимости, затронутые версии, root cause, PoC-инструкции, рекомендации по исправлению, оценка CVSS
• Отправьте через официальный канал (баг-баунти, ZDI, security@вендор)
• Ведите лог коммуникации - пригодится, если вендор будет молчать

Этот процесс масштабируется: для CTF-задач шаги 3-4 занимают часы, для реального ресёрча - недели. Структура одинакова. Если вы CTF-игрок с опытом в pwn/re - навыки для шагов 2 и 4 у вас уже есть. Добавьте фаззинг и грамотный reporting - и можно выходить на реальное баг-баунти.

Защита и детекция: что делать пользователям и безопасникам прямо сейчас​

Детали ZDI-CAN-30207 не раскрыты, патч не подтверждён - действуем проактивно.

Для пользователей​

Обновитесь. Последняя версия Telegram на всех устройствах. Даже если Telegram говорит «уязвимости нет», обновления могут содержать тихие исправления. Вендоры так делают - и не стоит их за это ругать.

Отключите автозагрузку медиа. Настройки Telegram: Data and Storage → Automatic Media Download → отключите для всех типов контента. Это не гарантия (превью может генерироваться до полной загрузки), но сокращает attack surface.

Веб-версия для подозрительных чатов. Браузерный sandbox даёт дополнительный уровень изоляции по сравнению с десктопным клиентом.

Для администраторов и SOC-команд​

Мониторинг крэшей. Крэш клиента после получения конкретного сообщения - индикатор попытки эксплуатации. Настройте алерты на повторные перезапуски процесса Telegram:

# Мониторинг крэшей Telegram Desktop на Linux
# Наблюдение за coredump-ами
inotifywait -m /var/lib/systemd/coredump/ -e create |
while read dir event file; do
    if echo "$file" | grep -q "Telegram"; then
        echo "[ALERT] Telegram crash detected: $file" | \
        mail -s "Telegram Crash Alert" soc@company.com
    fi
done

Сетевые IDS-правила. До раскрытия деталей точную сигнатуру не напишешь. Но аномально большие или необычно структурированные TGS-файлы в трафике - повод копнуть.

Ограничение на уровне политик. В корпоративной среде рассмотрите ограничение Telegram до веб-версии через MDM.

Defense in depth: обновления + отключение автозагрузки + мониторинг + сетевая изоляция. Ни одна мера не даёт 100%, но их комбинация серьёзно поднимает порог эксплуатации.

Куда движется охота на zero-day в мессенджерах​

ZDI-CAN-30207 - не изолированный инцидент, а симптом. Мессенджеры становятся одной из главных целей для исследователей и атакующих.

Attack surface растёт быстрее, чем его успевают защищать. Каждый мессенджер лезет в суперприложения: мини-приложения в Telegram (TMA/TWA), платежи, Stories, бот-платформы. Каждая новая функция - новый парсер, новый протокол, новая точка входа.

Серверная обработка - не серебряная пуля. Позиция Telegram по ZDI-CAN-30207 опирается на серверную фильтрацию. Но исследователи будут целенаправленно искать обходы - это уже отдельное направление атак. Ждите advisory, где root cause - обход серверного sanitizer-а.

Цена zero-day в мессенджерах растёт. По мере усложнения эксплуатации мобильных ОС, zero-click RCE в мессенджере остаётся одним из немногих путей к полному захвату устройства без физического доступа. Приоритетная цель - и для этических исследователей, и для offensive-индустрии.

Если вы пентестер или CTF-игрок, присматривающийся к vulnerability research - мессенджеры дают идеальное сочетание: огромная пользовательская база (высокий импакт), богатая медиаобработка (широкая attack surface), open-source компоненты (white-box анализ). Начните с фаззинга медиабиблиотек - самый низкий порог входа и самая высокая вероятность результата. ZDI-CAN-30207 показывает: следующий критический баг найдёт тот, кто систематически препарирует парсеры, а не ждёт случайного крэша. Скачайте rlottie, соберите harness из примера выше, запустите AFL++ - и посмотрите, что прилетит за ночь.