ANTICHAT

ANTICHAT (https://forum.antichat.xyz/index.php)
-   Уязвимости (https://forum.antichat.xyz/forumdisplay.php?f=74)
-   -   Уязвимость нулевого дня в мессенджерах: ZDI-CAN-30207 в Telegram и методология охоты на zero-day баги (https://forum.antichat.xyz/showthread.php?t=592551)

Сергей Попов 01.04.2026 16:04
https://forum.antichat.xyz/attachmen...226e2d200a.png

Март 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, MITMSIM-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
Код:
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 для трассировки:

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. Этот зверь умеет перематывать время - бесценная штука, когда нужно понять, что именно убило процесс.

Начните реверс с поверхностного анализа зависимостей (
Код:
ldd
/
Код:
dumpbin
), затем найдите обработчики медиа по строковым сигнатурам, потом подключите динамический анализ для конкретного формата. Не пытайтесь проанализировать весь бинарник - фокусируйтесь на пути данных от получения сообщения до рендеринга контента.
Фаззинг медиаформатов мессенджеров: от 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 крэшей
Не каждый крэш - эксплуатабельная уязвимость. Сортировка:
  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 оценивается до $500KSignalОфициальнаяСобственнаяНе публикуют тарифыМалая поверхность атаки, высокое качество кода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 дня)
  • Определите целевую платформу и версию
  • Постройте карту зависимостей (
    Код:
    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:

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++ - и посмотрите, что прилетит за ночь.


Время: 18:51