Март 2026 года. Исследователь публикует идентификатор ZDI-CAN-30207 - заявлена критическая zero-click уязвимость в Telegram, CVSS 9.8 из 10. Telegram в ответ: угрозы нет, исследователь ошибается. Публичное раскрытие деталей отложено до июля. Миллионы пользователей сидят в информационном вакууме, а исследователи безопасности - перед закрытой дверью.
Знакомая ситуация? Вендор говорит «всё хорошо», ZDI говорит «не всё», а правду узнаем через четыре месяца. Эта статья - карта всего, что известно о 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, категория Critical. Выше некуда.По данным SecurityAffairs и Dark Reading, уязвимость затрагивает Telegram на платформах Android и Linux. Заявлена возможность полного захвата устройства. Характер уязвимости связан с обработкой медиаконтента - предположительно, анимированных стикеров.
Публичное раскрытие технических деталей (disclosure) назначено на 24 июля 2026 года - если вендор не устранит проблему раньше.
Позиция Telegram
Команда Telegram публично оспорила выводы исследователя. На Хабре заявили: «исследователь ошибочно утверждает, что для атаки можно использовать стикер с вредоносным кодом». Аргумент - серверная фильтрация: все анимированные стикеры проходят серверную обработку и конвертацию, что теоретически предотвращает доставку вредоносного контента на клиент.Звучит убедительно. Но тут есть нюансы:
- Серверная конвертация сама может быть обойдена при определённых условиях
- Не все медиаформаты проходят одинаковую обработку
- Уязвимость может сидеть не в парсере формата, а в логике обработки метаданных после фильтрации
Что остаётся неизвестным
Сейчас не опубликованы: 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 году получила
Ссылка скрыта от гостей
- heap buffer overflow в Huffman-декодере WebP. Одна уязвимость накрыла Chrome, Firefox, Signal, Telegram и десятки других приложений разом.Zero-click потенциал. Мессенджер обрабатывает полученный стикер или изображение автоматически - показать превью, создать миниатюру, декодировать анимацию. Жертве не нужно кликать. Сообщение пришло - парсер сработал - уязвимость проэксплуатирована. Именно поэтому баги в медиапарсерах регулярно всплывают в атаках уровня nation-state (Pegasus, Predator).
Фрагментация реализаций. Telegram использует собственные обёртки над стандартными библиотеками, собственный формат анимированных стикеров TGS (на базе Lottie), собственную логику конвертации. Каждая «обёртка» - дополнительный слой кода, где может прятаться ошибка, даже если базовая библиотека чиста.
Формат TGS: что внутри telegram-стикера
Анимированные стикеры Telegram используют формат TGS - gzip-сжатый JSON, совместимый с Bodymovin/Lottie. Клиент распаковывает архив, парсит JSON, рендерит векторную анимацию. Цепочка:
Код:
Получение сообщения → Скачивание .tgs → gunzip → JSON parse → Lottie render → ОтображениеСерверная vs. клиентская обработка
Telegram утверждает, что стикеры проходят серверную фильтрацию и конвертацию. Архитектурно это грамотно: если сервер пересоздаёт файл, вредоносные данные теоретически удаляются. Но серверная обработка - не панацея:- Не все типы контента проходят полную пересборку
- Серверный конвертер может транслировать вредоносные данные без изменений, если они лежат в поле, которое он считает «безопасным»
- Обработка пользовательских аватаров, кастомных эмодзи и другого медиаконтента может идти по иному pipeline
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 | Массовые кампании |
| Сложность разработки | Максимальная | Высокая | Средняя |
Из прошлых случаев: ForcedEntry (NSO Group / Pegasus) через iMessage - вредоносный PDF мимикрировал под GIF и эксплуатировал JBIG2-парсер. В 2024 году ESET обнаружил эксплойт EvilVideo в Telegram - маскировка 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 Analysisldd покажет, какие версии медиабиблиотек используются. Видите libwebp.so.7 - проверьте, уязвима ли эта версия к известным CVE. Базовый шаг, но рабочий.Поиск функций обработки медиа
В Ghidra или IDA Pro первая цель - найти точки входа парсеров:- По строкам. Ищем
"tgs","webp","lottie","sticker","animation"- они приведут к функциям обработки. В Ghidra: Search → For Strings → Filter - По импортам. Если libwebp линкуется динамически - ищем вызовы
WebPDecode*,WebPGetInfo,WebPDecodeBGRA. Каждый вызов - место, где внешние данные попадают в библиотеку - По обработчикам сообщений. 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);
}
});Начните реверс с анализа зависимостей (
ldd/dumpbin), затем найдите обработчики медиа по строковым сигнатурам, потом подключите динамический анализ для конкретного формата. Не пытайтесь проанализировать весь бинарник - фокусируйтесь на пути данных от получения сообщения до рендеринга контента.Фаззинг медиаформатов мессенджеров: от harness до первого крэша
Фаззинг - самый продуктивный метод поиска уязвимостей в парсерах. Идея проста: генерируем миллионы мутированных входных файлов и скармливаем их парсеру, отслеживая крэши. На практике всё упирается в качество harness-а и corpus-а.Архитектура фаззинг-процесса для 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 <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;
}
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. Контролируем ли мы данные, которые пишутся за границы буфера? Можем ли управлять размером аллокации? Есть ли примитив записи?
Процесс 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 публикует по истечении срока (отсюда 24 июля для ZDI-CAN-30207: 120 дней от 26 марта)
- Publication. Публичный advisory с ZDI-XX-XXXX идентификатором. Полный PoC обычно не публикуется - только root cause и рекомендации
Почему вендор может оспаривать находку
Ситуация «вендор говорит нет, ZDI говорит да» - не уникальна. Причины расхождений:- Различия в threat model. Вендор считает серверная обработка блокирует вектор, но исследователь нашёл обход
- Различия в оценке severity. Вендор признаёт баг, но не считает его критическим
- Репутация. Публично признать zero-click RCE в мессенджере с сотнями миллионов пользователей - больно
- Время. На момент первой реакции вендор мог просто не закончить свой анализ
Если нашли уязвимость в мессенджере - ZDI, HackerOne, Bugcrowd являются легитимными каналами disclosure. ZDI платит за эксклюзивность и берёт на себя коммуникацию с вендором. Для начинающих: качество PoC важнее описания. Работающий эксплойт, стабильно воспроизводящийся на актуальной версии продукта - основа принятия отчёта.
Баг-баунти мессенджеров: где искать, сколько платят, какие подводные камни
Не все мессенджеры одинаково открыты для исследователей. Программы баг-баунти различаются радикально.Текущее состояние программ
| Мессенджер | Программа | Платформа | Выплаты за RCE | Особенности |
|---|---|---|---|---|
| Telegram | Официальная (ограниченная) | Собственная | До $100K+ (неофициальные данные) | Нет публичной программы на HackerOne/Bugcrowd; связь через security@telegram.org |
| 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. Исследование протоколов мессенджеров может попадать под законодательство о несанкционированном доступе. Всегда действуйте в рамках публичной программы баг-баунти или координированного раскрытия уязвимостей по OWASP.
Начните с мессенджеров, имеющих публичные программы на HackerOne/Bugcrowd - там чёткие правила и юридическая защита. Для Telegram: если нашли что-то серьёзное, ZDI - наиболее надёжный канал с подтверждённой историей обработки отчётов (ZDI-CAN-30207 тому пример).
Исторические zero-day уязвимости мессенджеров: паттерны, которые повторяются
Анализ прошлых инцидентов выявляет повторяющиеся паттерны. Знание этих паттернов направляет поиск.Паттерн 1: Библиотечные зависимости как слабое звено
CVE-2023-4863 (libwebp) - heap buffer overflow в Huffman-декодере WebP. Одна уязвимость - десятки затронутых продуктов: Chrome, Firefox, Signal, Telegram, практически любое приложение, отображающее WebP. Обнаружили 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-клиенты менее защищены
Мобильные ОС (iOS, Android) дают sandbox, ASLR, SELinux и другие механизмы, затрудняющие эксплуатацию. Desktop-клиенты на Linux и Windows часто имеют больше привилегий и меньше уровней защиты. Не случайно ZDI-CAN-30207 затрагивает Android и Linux - наименее sandbox-ированные платформы.При планировании исследования составьте матрицу: {платформа × зона атаки × паттерн}. Пересечения с наибольшей исторической частотой: 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@вендор)
- Ведите лог коммуникации - пригодится, если вендор начнёт тянуть время
Защита и детекция: что делать пользователям и безопасникам прямо сейчас
Пока детали ZDI-CAN-30207 не раскрыты, а патч не подтверждён - действуем проактивно.Для пользователей
Обновитесь. Последняя версия 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Ограничение через политики. В корпоративной среде рассмотрите ограничение 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 показывает: следующий критический баг в мессенджере найдёт тот, кто систематически препарирует парсеры. Попробуйте стянуть бинарник Telegram Desktop, прогнать
ldd, собрать harness для rlottie - и через пару часов фаззинга посмотрите, что вылезет. Может, ничего. А может - ваш собственный ZDI-CAN.
Последнее редактирование:
