Как я нашел способ авторизоваться без клауд-пароля и уведомлений

TwinFoxer

Member
Пользователь
Регистрация
27 Фев 2025
Сообщения
18
Реакции
6
Разработчики Telegram не сидят без дела: в мессенджере с каждым годом все больше функций. Но некоторые из них, если перефразировать «Собачье сердце», могут превратиться «из классной фичи в мерзкий баг». Этот материал — о любопытной уязвимости, с которой я столкнулся, расследуя, как украли 200 миллионов рублей в крипте зимой 2025 года.

Корень проблемы​

Сценарий простой. Представь, что ты открываешь встроенный в Telegram браузер и переходишь по ссылке на web.telegram.org. Почти мгновенно — без ввода пароля, без подтверждения входа, без оповещений — ты оказываешься авторизован. Вроде ничего необычного: ты ведь и так уже в Telegram! Но теперь представь, что злоумышленник вовремя перехватит этот токен. И использует его... скажем, в другом браузере. Или на другом устройстве.

Что получается: Telegram запускает сессию с широкими правами, не требуя клауд‑пароля, не уведомляя пользователя и не отслеживая, где эта сессия используется. Нет браузерной привязки. Нет логов. Нет никаких ограничений!



Реальный кейс: кража крипты​

Я занимаюсь ИТ‑просвещением в рамках независимого некоммерческого проекта CakesCats, посвященного цифровой гигиене, безопасности и анализу современных угроз. К проекту обращаются люди с вопросами и кейсами.

Пострадавший в этом инциденте пришел ко мне в начале 2025 года через публичные каналы. Он пострадал от кражи криптовалюты на очень значительную сумму.

После базового аудита я был сильно впечатлен, что следов почти нет. Такое встречается крайне редко, если не сказать, что я с таким встретился впервые. Но я не собирался сдаваться и постепенно нашел 0-day в Telegram.

info​

В процессе расследования я использовал Mobile Verification Toolkit (MVT). Большое спасибо его разработчикам и сообществу за отличный инструмент!
Вот цепочка событий, которую мне удалось восстановить:

  • Пользователь зашел на сайт и авторизовался через Telegram Login Widget.
  • Через несколько часов с криптокошельков исчезли все средства.
  • Seed-фразы хранились в Telegram (что, конечно, очень плохая практика).
  • Атакующий, воспользовавшись сессией, достал содержимое заметок, не входя явно в Telegram, и получил доступ к крипте.
  • Не было уведомлений о необычных новых сессиях или подтверждений входа — Telegram или девайс человека «не заметил» кражу.

Технический контекст​

Пострадавший использовал iPhone с iOS версии 18.3 и браузер Safari. Также было известно, что для авторизации в Telegram он использовал виджет из серии Telegram Widgets.

Я тщательно проверил все клиентские устройства в поисках следов и опросил пользователя — он не находил никаких «потерянных флешек» и не заметил ничего подозрительного. Ситуация оказалась максимально нетипичной: я не припомню случая, когда не осталось бы ни единого реального доказательства. Обычно все куда проще: чья‑то невнимательность, злой умысел кого‑то из близкого круга, вредоносное ПО. Но здесь — пустота.

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

В тот момент в регионе, где находился клиент, проходила ИТ‑конференция, в том числе с участием телеком- и кибербезопасных структур. Владелец айфона остановился в гостинице, которая принимала участников, — поездка была спонтанной. Это может быть совпадением, но также и индикатором высокоорганизованной атаки уровня APT. В таких случаях высока вероятность, например, использования IMSI-catcher или подобного оборудования, а также непубличных эксплоитов.

Обнаружилась лишь одна интересная деталь: в базовых логах iPhone (baseband logs) отсутствовали записи за два дня, когда предположительно и была проведена атака. За два с половиной месяца — это единственное слепое пятно.

Опять же, рут iPhone — это нетривиальная задача, даже если это твой собственный телефон. А тут неизвестные провели такую атаку удаленно и забрали только содержимое заметок в Telegram! У клиента были еще и брокерские и банковские приложения, где тоже хранились деньги. И ничего из этого не тронуто.

Методом исключения и пошагового разбора killchain атаки родилась единственная правдоподобная гипотеза: была перехвачена сессия Telegram. Где именно и каким образом это произошло — остается загадкой даже сейчас. Ни один из стандартных сценариев не подтверждается. И все же именно эта версия подтолкнула меня глубже копать в сторону возможных манипуляций с сессиями Telegram.

Но тут есть одно но...


Telegram Login Widget и невидимые сессии​

Во время тестирования было зафиксировано интересное поведение.

  • В обычных условиях после входа через Telegram Login Widget появляется новое устройство и его «сессия» — она видна в настройках аккаунта.
  • Однако, особенно в случае авторизации через Telegram-сайты, новая сессия при каждом входе не создается — ни в списке устройств, ни в перечне подключенных сайтов ты ее не увидишь. Более того, даже если вручную выйти из аккаунта, сам токен авторизации остается рабочим и позволяет снова и снова входить в систему без ограничений.
  • Единственный след — это системное уведомление от Telegram о входе в аккаунт. После этого — тишина. Однако при повторной авторизации на сторонних сервисах с тем же токеном все продолжает работать — и это лишь подтверждает, что сессия все еще активна.
Такое поведение затрудняет отслеживание или даже просто обнаружение того факта, что кто‑то вошел в аккаунт пользователя. Менеджмент сессий просто невозможен.


Гипотеза: widget → токен → доступ к данным​

На практике механизм логина через виджет должен выглядеть так:

  1. Пользователь кликает на Telegram Login на сайте.
  2. Telegram возвращает токен сессии, который доступен внутри браузера.
  3. Этот токен можно перехватить до редиректа. Например, это можно сделать через JS-логирование, расширение, вредонос или сниффинг трафика.
  4. Получив токен, злоумышленник может авторизоваться внутри инфраструктуры Telegram, например на web.telegram.org в другом браузере, получить доступ к аккаунту (или его части — например, букмаркам или чатам), не вызывая никаких подозрений.
При этом:

  • Telegram не всегда добавляет такую сессию в лог;
  • cloud password (2FA) не запрашивается;
  • повторное использование токена может сработать, если оно происходит достаточно быстро или с того же IP.
В нашем случае по‑прежнему очень много странного. А именно:

  • нет уведомлений, значит, пользователь не подозревает о доступе;
  • закладки в Telegram не зашифрованы (или доступны в рамках сессии);
  • базовые логи iOS «пропали» именно в момент атаки;
  • Telegram Login Widget дал токен с правами на приватные чаты и звонки;
  • возможный вектор похищения данных — через встроенный браузер Telegram, где перехват токена до редиректа возможен.
Вот как это выглядит на практике. Когда пользователь авторизуется через Telegram Browser (тот самый, который используют для автологина в сервисы вроде bugs.telegram.org или web.telegram.org), создается токен. При этом:

  • не требует клауд‑пароля, даже если он включен;
  • не создает новых сессий в списке «Активные устройства»;
  • не вызывает уведомлений Telegram о входе;
  • не привязан к браузеру или устройству, откуда он был получен;
  • имеет (хотя уже правильнее говорить «имел») возможность принимать входящие и запускать приватные сессии.

Это почти идеальный сценарий для захвата сессии.

Proof-of-Concept: токен из ниоткуда​

Технически все просто. Мы используем встроенный браузер Telegram (например, при переходе по ссылке внутри Telegram, он включен по умолчанию), ловим момент до редиректа — и сохраняем токен авторизации.

Если успеть, можно использовать этот токен где угодно: в Firefox, Chrome, даже в headless-сценариях. И все это — без необходимости входа, подтверждений или повторной авторизации.

Как это сработало в нашем сценарии? Представим, что у пользователя активен Telegram, где‑то в фоне открыта сессия и он кликнул по ссылке, ведущей на web.telegram.org. Пока браузер Telegram делает редирект, злоумышленник (через установку плагина, JS-инъекции или эксплоит на стороне клиента, да хоть бы просмотр истории браузера) перехватывает токен. Всё!

Дальше — просто: токен вставляется в URL, и злоумышленник получает сессию Telegram Web, полную, рабочую, не отслеживаемую. Без пароля. Без 2FA.

Почему это работает?​

Основная проблема — отсутствие строгой привязки токена к среде. Telegram генерирует токены, которые действуют как входной билет на «полную версию», но не ограничивает, кто, где и как их применяет. Это классическая ошибка проектирования: авторизационный токен, не имеющий контекста среды выполнения.

Даже если Telegram считает, что токены привязаны к сессии, на практике мы видим:

  • они живут дольше, чем должны;
  • не инвалидируются (!) при удалении сессии;
  • могут быть использованы за пределами того браузера, где были созданы.

Что уже поменяли в Telegram?​

На момент подготовки статьи видно, что разработчики Telegram отредактировали поведение виджетов, — теперь те чаще создают сессии без прав. Однако никаких публичных уведомлений об этом не последовало. Ни упоминания в каналах Telegram Dev, ни записи в changelog.

Пока неизвестно, была ли эта уязвимость закрыта из‑за внутреннего аудита, жалоб пользователей или внешнего отчета. Но факт остается фактом: она существовала, и эксплуатация была возможна — тихо, без следов и с реальным доступом.

Отмечу и некоторые изменения по линии Telegram Widget: уже в день написания этого текста разработчики попытались ограничить поведение виджетов. Теперь виджеты, судя по всему, не создают сессии с привилегиями. Но это не касается автоматических токенов авторизации, генерируемых системой при переходе через браузер Telegram. Эти токены могут использоваться в обход всех ограничений. Вообще всех!


Выводы​

Итак, авторизационные токены Telegram могут использоваться для доступа к аккаунту в обход cloud-пароля и систем оповещений. Сессия, созданная через встроенный браузер Telegram, потенциально может быть перехвачена и воспроизведена злоумышленником. Отсутствие полноценного контроля среды — таких параметров, как User-Agent, IP-адрес или цифровой отпечаток устройства, — делает Telegram уязвимым перед классическими атаками типа session hijacking.

И речь здесь идет не просто о техническом баге, а об архитектурной уязвимости, которая заслуживает самого серьезного внимания — как со стороны разработчиков, так и со стороны сообщества.

Такой «пасхальный» (поскольку нашел я его на Пасху) 0-day! Приятный сюрприз для ресерчера, но не для пользователей. Если у тебя Telegram с включенной двухфакторной аутентификацией и ты думаешь, что никто не может войти без твоего ведома, — подумай дважды! Особенно если тебе есть что терять, как в случае моего клиента.
 
Сверху