Март 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 overflowCVE-2023-4863 (libwebp)
Протокол доставкиMTProto (Telegram), Signal Protocol, кастомныеCrypto-атаки, replay, downgradeПрошлые проблемы MTProto 1.0
Превью ссылокHTML-рендерер, парсер OG-теговSSRF, XSS, утечка IPWhatsApp link preview leaks
Звонки (VoIP)WebRTC, кастомные RTP-стекиBuffer overflow, RCE через RTPPegasus через WhatsApp VoIP
Файловый обменОбработчики .apk, .exe, .py, архивовPath traversal, symlink attacksTelegram 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-clickOne-clickТребует установкиДействие жертвыНикакихОткрыть файл/ссылкуСкачать и запуститьТипичный CVSS9.0-10.07.0-9.05.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:
Bash:
Код:
# Стягиваем бинарник из официального дистрибутива
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
покажет, какие версии медиабиблиотек используются. Видите
- проверьте, уязвима ли эта версия к известным CVE. Базовый шаг, но рабочий.
Поиск функций обработки медиа
В Ghidra или IDA Pro цель первого этапа - найти точки входа парсеров:
- По строкам. Ищем
,
,
,
,
- они приведут к функциям обработки. В Ghidra: Search → For Strings → Filter
- По импортам. Если libwebp линкуется динамически - ищем вызовы
,
,
. Каждый вызов - место, где внешние данные попадают в библиотеку
- По обработчикам сообщений. Telegram использует TL-схему для протокольных сообщений. Ищем обработчики типов
Код:
messageMediaDocument
,
Код:
documentAttributeSticker
,
Код:
documentAttributeAnimated
Динамический анализ
Для Linux-версии - GDB или Frida для трассировки:
Bash:
Код:
# Перехват вызовов 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. Этот зверь умеет перематывать время - бесценная штука, когда нужно понять, что именно убило процесс.
Начните реверс с поверхностного анализа зависимостей (
/
), затем найдите обработчики медиа по строковым сигнатурам, потом подключите динамический анализ для конкретного формата. Не пытайтесь проанализировать весь бинарник - фокусируйтесь на пути данных от получения сообщения до рендеринга контента.
Фаззинг медиаформатов мессенджеров: от harness до первого крэша
Фаззинг - самый продуктивный метод поиска уязвимостей в парсерах. Идея примитивная: генерируем миллионы мутированных входных файлов и скармливаем их парсеру, отслеживая крэши. На практике всё упирается в качество harness-а и corpus-а. Плохой harness - месяц впустую. Хороший - первые крэши за часы.
Архитектура фаззинг-процесса для Telegram
Код:
Код:
Corpus (валидные .tgs/.webp) → Мутатор (AFL++/libFuzzer) → Harness (изолированный парсер) → Sanitizers (ASAN/MSAN) → Crash triage
Шаг 1: Сбор corpus-а
Corpus - набор валидных файлов, которые фаззер будет мутировать. Для Telegram-стикеров:
Bash:
Код:
# Скачиваем стикерпаки через 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):
C++:
Код:
// harness_rlottie.cpp - пример для демонстрации концепции
#include
#include
#include "rlottie.h"
extern
"C"
int
LLVMFuzzerTestOneInput
(
const
uint8_t
*
data
,
size_t size
)
{
// Преобразуем входные данные в строку JSON
std
::
string
json_data
(
reinterpret_cast
(
data
)
,
size
)
;
// Создаём анимацию из входных данных
auto
animation
=
rlottie
::
Animation
::
loadFromData
(
json_data
,
""
,
""
,
false
)
;
if
(
animation
)
{
size_t width
=
512
,
height
=
512
;
auto
buffer
=
std
::
make_unique
(
width
*
height
)
;
rlottie
::
Surface
surface
(
buffer
.
get
(
)
,
width
,
height
,
width
*
4
)
;
// Рендерим первый кадр
animation
->
renderSync
(
0
,
surface
)
;
}
return
0
;
}
Компиляция с AddressSanitizer:
Bash:
Код:
clang++ -g -O1 -fsanitize
=
fuzzer,address
\
-I/path/to/rlottie/inc
\
harness_rlottie.cpp
\
-L/path/to/rlottie/build -lrlottie
\
-o fuzz_rlottie
Шаг 3: Запуск и мониторинг
Bash:
Код:
# Запуск 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 крэшей
Не каждый крэш - эксплуатабельная уязвимость. Сортировка:
- Дедупликация. Группируем крэши по stack trace - AFL++ делает это автоматически через бакеты
- Классификация. ASAN-отчёт покажет тип: heap-buffer-overflow, use-after-free, stack-buffer-overflow. Heap-overflow и UAF - самые перспективные для RCE
- Воспроизводимость. Запускаем крэш-файл вне фаззера, подтверждаем стабильность
- 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
- Submission. Исследователь отправляет отчёт через портал ZDI: описание уязвимости, PoC, затронутые версии, оценка импакта
- Triage. Команда ZDI воспроизводит PoC в собственной лаборатории. Баг подтверждается - присваивается ZDI-CAN-XXXXX
- Acquisition. ZDI предлагает выкуп за эксклюзивные права на уязвимость. Сумма зависит от критичности, популярности продукта и exploitability
- Vendor notification. ZDI уведомляет вендора (здесь - Telegram). Стандартный срок на исправление - 120 дней
- Patch или deadline. Вендор выпускает патч - ZDI публикует advisory. Не реагирует - ZDI публикует по истечении срока. Для ZDI-CAN-30207 disclosure назначен на 24 июля 2026; 26 марта - дата публичного упоминания, точная дата vendor notification неизвестна, но 120-дневное окно отсчитывается от неё
- 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 BountyHackerOneДо $300K за zero-click RCEКрупнейшая программа, чёткие правила
DiscordBug BountyHackerOneДо $10K-$25KФокус на веб-уязвимостях
ViberЧерез RakutenHackerOneМалые выплатыМенее активная программа
Альтернативные каналы монетизации
Если у мессенджера нет адекватной баг-баунти:
- 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 дня)
- Определите целевую платформу и версию
- Постройте карту зависимостей (
,
, анализ
/
если open-source)
- Проверьте все зависимости на известные CVE через
Код:
pip install osv-scanner
или ручной поиск в NVD
- Составьте таблицу attack surface по модели из раздела выше
Шаг 2: Статический анализ (3-5 дней)
- Откройте бинарник в Ghidra/IDA Pro
- Найдите парсеры медиаформатов по строковым сигнатурам и импортам
- Проследите data flow: откуда приходят данные (сеть), где парсятся, куда записываются
- Ищите классические паттерны: непроверенные длины, целочисленные переполнения,
/
с контролируемым размером
Шаг 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:
Bash:
Код:
# Мониторинг крэшей 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++ - и посмотрите, что прилетит за ночь.
Линейный вид
