спасибо за комментарий. в исходной статье поспешил с формулировками, гипотезы как факты подал. Это уже упоминал в комментариях ниже и в follow-up материалах. Но суть от этого не меняется: захват аккаунта молчаливый, владелец узнаёт постфактум, support отвечает сутками.
Что касается App Attestation и реального приложения у фишера. Тут уточню — Attestation отсекает фишера, который сидит на сервере и притворяется приложением MAX. Это 90% массового рынка: боты на дешёвом VPS за $5/мес. Они физически не могут получить токен от Google Play Services, потому что на Linux-сервере Play Services просто нет.
Если фишер ставит реальное приложение MAX на реальный телефон и через него ретранслирует запросы жертвы — тут Attestation честно не помогает, согласен. Но это уже принципиально другая экономика: ферма из 50-100 телефонов вместо одного сервера, $30к капекса вместо $5/мес, и значительно медленнее по пропускной способности. Большинство кампаний уйдёт на мессенджеры без такой защиты.
Что касается прокси и геопозиции. Согласен, прокси с IP жертвы — стандартная техника, гео-проверка низкоэффективна. В финальной таблице v3 её и нет.
Что касается push-подтверждения, если жертва уже вводит SMS. Принципиальный момент. В Telegram с 2018 при наличии активной сессии SMS-код вообще не приходит. Жертва на фишинг-сайте видит «введите код из SMS», а SMS просто не приходит. Вместо этого код прилетает push-ом в её активный Telegram с подписью «Кто-то пытается войти». Фишер физически не может проксировать то, чего у жертвы нет. Это не про «нажмёт ли подтверждение» — это про разницу в канале доставки кода.
Что касается лимита по target-номеру. Тут речь не про одну атаку, а про конвейер. PhaaS шлёт одной жертве несколько приманок за месяц-два разными темами: посылка → голосование → фото → повестка → штраф. Жертва один раз отказалась, через неделю на другую повелась. Лимит 3-5 SMS в сутки на номер обрывает повторные волны.
Что касается защиты в браузере и свежести доменов. Браузер нужен, согласен, но не вместо защиты в сервисе, а вместе. Браузер блокирует только уже известные плохие домены. У этой кампании 180 свежих в спячке, ни один пока не в базе Safe Browsing. На телефонах (основная аудитория MAX) браузерных защит ещё меньше. По свежести домена — обходится отстаиванием, согласен, это просто один сигнал в общем risk-score, не основная проверка.
Реально необратимый захват происходит только когда жертва САМА выдала фишеру свой cloud password по социалке — «позвонили из службы безопасности, попросили продиктовать». На уровне протокола проксирование SMS без знания пароля full control не даёт.
Что реально надо MAX. Push-confirmation в активную сессию перед выдачей токена (Telegram-2018), плюс 24-часовая задержка на критичные действия с нового устройства. Это закрывает молчаливость захвата даже для basic-сессий и даёт окно вмешательства владельцу.
Апдейт. VK на отчёт ответили, что это не уязвимость. Окей. На днях выложу воссозданный инструмент атакующего — Python-терминал, умеет всё что и фишер. Желающие смогут сами потестить на своём аккаунте, проверить защиты, может кто предложит решения лучше моих.
И свежее. Похоже MAX за последние недели докрутил: теперь при критичном действии с админ-правами (а токенов в API два типа) жертве приходит SMS-уведомление. В апреле-мае этого не было, и аккаунт уходил молча. Сейчас SMS есть. Push в открытый мессенджер это не заменяет, но окно для реакции появилось.
я сделал уже форк макса с возможностью синхронного шифрования . через пару дней выложу в открытый доступ , но есть проблема - аккаунт блокируют через некоторое время ))) не рекомендую использовать личную сим для этого.
Согласен, в этом главная сложность. Серверной частью владеет сам мессенджер, и переделать её невозможно. Поэтому минимакс не может быть полностью независимым от MAX.
Идея я так понимаю в другом: использовать MAX как обычную почту. Сам мессенджер просто передаёт зашифрованные сообщения между двумя людьми, не зная их содержимого. Серверной частью становится локальное приложение у каждого пользователя: оно шифрует своим ключом перед отправкой и расшифровывает при получении. У каждого как бы свой «мини-сервер» на телефоне или компьютере. MAX в этой схеме это только канал доставки.
Что MAX в такой схеме всё равно видит: кто кому пишет, когда, и сколько байтов. Это называется метаданные, и спрятать их полностью без отдельной сети не получится. Содержимое сообщений MAX не увидит, но связи между людьми и активность по времени останутся доступны их аналитике.
То есть полноценной приватности через чужую инфраструктуру не построить. Можно построить ситуативную: «вы не прочитаете что я написал, но видите что я с этим человеком переписывался». Для большинства бытовых задач хватает. Для серьёзных угроз нужна отдельная сеть с собственным транспортом, не на чужих серверах.
Идея у вас та же что у меня, только в моём случае пока бот сидит на сервере и работает через окошко терминала, а вы предлагаете готовое приложение с кнопками. Уже делаю, но не успеваю, проектов много.
Главная сложность не в коде, а в законах. Программы которые позволяют общаться через MAX обходным путём, без официальных правил мессенджера, формально нарушают его условия использования. А в России, насколько я знаю, есть ещё отдельные ограничения на такое. Сейчас разговариваю с юристами. Пока они не дадут чёткий зелёный свет, готовое приложение я в открытый доступ не выложу. Потому что это уже не «делал для себя», это «раздаю другим».
Скорее всего сделаю по-другому: опубликую отдельной статьёй здесь же подробную инструкцию как собрать такое приложение самостоятельно. То есть код плюс пошаговое руководство, чтобы каждый собрал у себя дома. Юристы говорят что между «дать готовое» и «рассказать как сделать» большая разница, второе разрешено.
Про бан аккаунта. Если использовать отдельную сим-карту, не делать массовых рассылок и вести себя как обычный пользователь, риск приемлемый. У меня свой такой работает уже несколько недель без проблем. Мессенджер обычно ловит спамеров и рекламные рассылки, а не одного человека который общается со своими.
Именно так, причем нужно отдать им должное у них все налажено и автоматизировано . То чем они занимаються вызывает отвращение , но как они это автоматизировали вызывает восхищение . У нас не каждый легальный бизнес так эффективно работает .
да и в virustotal есть это вкладка relations (только домен вводите без https) и в др в сервисах например crt.sh или shodan или dnsdumpster.com
Это отличная идея поскольку я начал реализовывать бота но партнеры верно отметили, что такой бот будет инструментом для троллей , а вот ваша идея компромиссная и эффективная . спасибо
Это протестируем .
Схема которую я тут описал работает универсально , но занимает много времени
Я готовлю инструкцию и бота антискам бота . Поскольку времени мало как обычно выложу то что сделал и благодаря комментариям доработаю . Это не коммерческий проект будет по этому все желающие смогут подключиться .
Вы знаете оказыаеться действительно я был залогинен давно (не обратил даже внимание ) ))) без регистрации можно только смотреть отчёты . Создать свой модно тоже бесплатно но регистрация нужна .
)) Надеюсь нет. Я просто пример привел . чтобы гарантированно исключить такую уязвимость нужна двухфакторная аутентификация , в рф есть например Яндекс ключ ,но я считаю что для сервиса через который можно получить доступ в госуслуги необходим уровень безопасности даже лучше чем гугл аутентификатор , но тут нет даже его (подобного сервиса и ключами)., хотя бы Яндекс бы ключи подключили из того что уже есть . Но конечно нужен уровень безопасности выше.
спасибо за коммент по большинству пунктов согласен
да Origin/Referer прокси подставит что хочет это работает от CSRF а не от server-to-server проксирования тут моя ошибка
по SDK-токену тоже прав статический api_id вытаскивается из APK за пять минут сам по себе он ничего не даёт . работает только в связке с app attestation - Play Integrity у гугла или DeviceCheck у эпла . вот этот токен серверный бот атакующего получить не сможет потому что гугл и эпл проверяют что есть реальное устройство и подлинная подпись приложения . без attestation вызов /api/send-code просто не должен проходить . писать надо было сразу про attestation а не про SDK-токен в общем
JA3/JA4 как session-binding да не работает согласен атакующий сам и есть initial-клиент у него всё совпадёт . но как сигнал на стороне max смысл какой то есть когда один fingerprint лезет на десятки разных номеров за час это паттерн прокси-кита а не нормального юзера . но это уже anomaly detection а не привязка тут ты тоже прав я в отчёте смешал две разные штуки
про "сотни запросов в день с одного ИП" - честно гипотеза . логов max у меня нету подтвердить не могу . оператор вполне может крутить через резидентские прокси или симбокс с реконнектом тогда ИП будет постоянно новый . так что рейт-лимит по сорс ИП реально не панацея нужен лимит по таргет-номеру (один телефон не получает смс чаще например пяти раз в час) и тут уже сложнее обойти
если совсем коротко суть не в этих мерах по отдельности . api max не проверяет что /api/send-code зовёт реальное приложение max а не левый сервер . из этого растёт вся атака кто угодно поднимает прокси-фронт юзер вводит номер прокси проксирует запрос в реальный апи max шлёт настоящий смс юзер вводит код прокси проксирует код получает sessionToken заходит в аккаунт . cloud password проксируется через /api/sign-in-2fa тем же способом 2фа не помогает
реально закрывают это только две вещи
первое app attestation на /api/send-code . серверный бот аттестейшен от гугла/эпла не получит ему нечем подтвердить что он реальное приложение
второе push-confirmation в активные сессии при попытке нового входа как у телеги whatsapp signal . даже если каким то чудом attestation обошли без подтверждения с уже активного устройства жертвы новая сессия не выпускается
всё остальное (Origin SDK-токен в одиночку JA3-привязка IP-лимиты) слабые меры тут ты прав . спасибо что разобрал внимательно сам бы не заметил часть слабостей
спасибо за комментарий. в исходной статье поспешил с формулировками, гипотезы как факты подал. Это уже упоминал в комментариях ниже и в follow-up материалах. Но суть от этого не меняется: захват аккаунта молчаливый, владелец узнаёт постфактум, support отвечает сутками.
Что касается App Attestation и реального приложения у фишера. Тут уточню — Attestation отсекает фишера, который сидит на сервере и притворяется приложением MAX. Это 90% массового рынка: боты на дешёвом VPS за $5/мес. Они физически не могут получить токен от Google Play Services, потому что на Linux-сервере Play Services просто нет.
Если фишер ставит реальное приложение MAX на реальный телефон и через него ретранслирует запросы жертвы — тут Attestation честно не помогает, согласен. Но это уже принципиально другая экономика: ферма из 50-100 телефонов вместо одного сервера, $30к капекса вместо $5/мес, и значительно медленнее по пропускной способности. Большинство кампаний уйдёт на мессенджеры без такой защиты.
Что касается прокси и геопозиции. Согласен, прокси с IP жертвы — стандартная техника, гео-проверка низкоэффективна. В финальной таблице v3 её и нет.
Что касается push-подтверждения, если жертва уже вводит SMS. Принципиальный момент. В Telegram с 2018 при наличии активной сессии SMS-код вообще не приходит. Жертва на фишинг-сайте видит «введите код из SMS», а SMS просто не приходит. Вместо этого код прилетает push-ом в её активный Telegram с подписью «Кто-то пытается войти». Фишер физически не может проксировать то, чего у жертвы нет. Это не про «нажмёт ли подтверждение» — это про разницу в канале доставки кода.
Что касается лимита по target-номеру. Тут речь не про одну атаку, а про конвейер. PhaaS шлёт одной жертве несколько приманок за месяц-два разными темами: посылка → голосование → фото → повестка → штраф. Жертва один раз отказалась, через неделю на другую повелась. Лимит 3-5 SMS в сутки на номер обрывает повторные волны.
Что касается защиты в браузере и свежести доменов. Браузер нужен, согласен, но не вместо защиты в сервисе, а вместе. Браузер блокирует только уже известные плохие домены. У этой кампании 180 свежих в спячке, ни один пока не в базе Safe Browsing. На телефонах (основная аудитория MAX) браузерных защит ещё меньше. По свежести домена — обходится отстаиванием, согласен, это просто один сигнал в общем risk-score, не основная проверка.
Реально необратимый захват происходит только когда жертва САМА выдала фишеру свой cloud password по социалке — «позвонили из службы безопасности, попросили продиктовать». На уровне протокола проксирование SMS без знания пароля full control не даёт.
Что реально надо MAX. Push-confirmation в активную сессию перед выдачей токена (Telegram-2018), плюс 24-часовая задержка на критичные действия с нового устройства. Это закрывает молчаливость захвата даже для basic-сессий и даёт окно вмешательства владельцу.
Апдейт. VK на отчёт ответили, что это не уязвимость. Окей. На днях выложу воссозданный инструмент атакующего — Python-терминал, умеет всё что и фишер. Желающие смогут сами потестить на своём аккаунте, проверить защиты, может кто предложит решения лучше моих.
И свежее. Похоже MAX за последние недели докрутил: теперь при критичном действии с админ-правами (а токенов в API два типа) жертве приходит SMS-уведомление. В апреле-мае этого не было, и аккаунт уходил молча. Сейчас SMS есть. Push в открытый мессенджер это не заменяет, но окно для реакции появилось.
я сделал уже форк макса с возможностью синхронного шифрования . через пару дней выложу в открытый доступ , но есть проблема - аккаунт блокируют через некоторое время ))) не рекомендую использовать личную сим для этого.
не совсем . ,бот через vk api не может писать сам на прямую только отвечать - это ключевое отличие .
Согласен, в этом главная сложность. Серверной частью владеет сам мессенджер, и переделать её невозможно. Поэтому минимакс не может быть полностью независимым от MAX.
Идея я так понимаю в другом: использовать MAX как обычную почту. Сам мессенджер просто передаёт зашифрованные сообщения между двумя людьми, не зная их содержимого. Серверной частью становится локальное приложение у каждого пользователя: оно шифрует своим ключом перед отправкой и расшифровывает при получении. У каждого как бы свой «мини-сервер» на телефоне или компьютере. MAX в этой схеме это только канал доставки.
Что MAX в такой схеме всё равно видит: кто кому пишет, когда, и сколько байтов. Это называется метаданные, и спрятать их полностью без отдельной сети не получится. Содержимое сообщений MAX не увидит, но связи между людьми и активность по времени останутся доступны их аналитике.
То есть полноценной приватности через чужую инфраструктуру не построить. Можно построить ситуативную: «вы не прочитаете что я написал, но видите что я с этим человеком переписывался». Для большинства бытовых задач хватает. Для серьёзных угроз нужна отдельная сеть с собственным транспортом, не на чужих серверах.
Идея у вас та же что у меня, только в моём случае пока бот сидит на сервере и работает через окошко терминала, а вы предлагаете готовое приложение с кнопками. Уже делаю, но не успеваю, проектов много.
Главная сложность не в коде, а в законах. Программы которые позволяют общаться через MAX обходным путём, без официальных правил мессенджера, формально нарушают его условия использования. А в России, насколько я знаю, есть ещё отдельные ограничения на такое. Сейчас разговариваю с юристами. Пока они не дадут чёткий зелёный свет, готовое приложение я в открытый доступ не выложу. Потому что это уже не «делал для себя», это «раздаю другим».
Скорее всего сделаю по-другому: опубликую отдельной статьёй здесь же подробную инструкцию как собрать такое приложение самостоятельно. То есть код плюс пошаговое руководство, чтобы каждый собрал у себя дома. Юристы говорят что между «дать готовое» и «рассказать как сделать» большая разница, второе разрешено.
Про бан аккаунта. Если использовать отдельную сим-карту, не делать массовых рассылок и вести себя как обычный пользователь, риск приемлемый. У меня свой такой работает уже несколько недель без проблем. Мессенджер обычно ловит спамеров и рекламные рассылки, а не одного человека который общается со своими.
Можно но я бы не советовал использовать номер привязанный к госуслугам.
Именно так, причем нужно отдать им должное у них все налажено и автоматизировано . То чем они занимаються вызывает отвращение , но как они это автоматизировали вызывает восхищение . У нас не каждый легальный бизнес так эффективно работает .
да и в virustotal есть это вкладка relations (только домен вводите без https) и в др в сервисах например crt.sh или shodan или dnsdumpster.com
Это отличная идея поскольку я начал реализовывать бота но партнеры верно отметили, что такой бот будет инструментом для троллей , а вот ваша идея компромиссная и эффективная . спасибо
Это протестируем .
Схема которую я тут описал работает универсально , но занимает много времени
Я готовлю инструкцию и бота антискам бота . Поскольку времени мало как обычно выложу то что сделал и благодаря комментариям доработаю . Это не коммерческий проект будет по этому все желающие смогут подключиться .
Так и есть- уже переехали .
Вы знаете оказыаеться действительно я был залогинен давно (не обратил даже внимание ) ))) без регистрации можно только смотреть отчёты . Создать свой модно тоже бесплатно но регистрация нужна .
Где можно проверить информацию ?
все верно . иностранный след нашел но это не суть статьи . спасибо за резюме ( не ирония)
)) потому что он не помогает . но ты понял суть
возможно вы правы. Самое интересное что группа которую я описал по прежнему работает и сегодня сменили очередной хост .и меры никто не принимает .
)) Надеюсь нет. Я просто пример привел . чтобы гарантированно исключить такую уязвимость нужна двухфакторная аутентификация , в рф есть например Яндекс ключ ,но я считаю что для сервиса через который можно получить доступ в госуслуги необходим уровень безопасности даже лучше чем гугл аутентификатор , но тут нет даже его (подобного сервиса и ключами)., хотя бы Яндекс бы ключи подключили из того что уже есть . Но конечно нужен уровень безопасности выше.
Она приватная пок .я открою доступ как закончу исправлять ошибки пришлю вам в личку тоже.
спасибо за коммент по большинству пунктов согласен
да Origin/Referer прокси подставит что хочет это работает от CSRF а не от server-to-server проксирования тут моя ошибка
по SDK-токену тоже прав статический api_id вытаскивается из APK за пять минут сам по себе он ничего не даёт . работает только в связке с app attestation - Play Integrity у гугла или DeviceCheck у эпла . вот этот токен серверный бот атакующего получить не сможет потому что гугл и эпл проверяют что есть реальное устройство и подлинная подпись приложения . без attestation вызов /api/send-code просто не должен проходить . писать надо было сразу про attestation а не про SDK-токен в общем
JA3/JA4 как session-binding да не работает согласен атакующий сам и есть initial-клиент у него всё совпадёт . но как сигнал на стороне max смысл какой то есть когда один fingerprint лезет на десятки разных номеров за час это паттерн прокси-кита а не нормального юзера . но это уже anomaly detection а не привязка тут ты тоже прав я в отчёте смешал две разные штуки
про "сотни запросов в день с одного ИП" - честно гипотеза . логов max у меня нету подтвердить не могу . оператор вполне может крутить через резидентские прокси или симбокс с реконнектом тогда ИП будет постоянно новый . так что рейт-лимит по сорс ИП реально не панацея нужен лимит по таргет-номеру (один телефон не получает смс чаще например пяти раз в час) и тут уже сложнее обойти
если совсем коротко суть не в этих мерах по отдельности . api max не проверяет что /api/send-code зовёт реальное приложение max а не левый сервер . из этого растёт вся атака кто угодно поднимает прокси-фронт юзер вводит номер прокси проксирует запрос в реальный апи max шлёт настоящий смс юзер вводит код прокси проксирует код получает sessionToken заходит в аккаунт . cloud password проксируется через /api/sign-in-2fa тем же способом 2фа не помогает
реально закрывают это только две вещи
первое app attestation на /api/send-code . серверный бот аттестейшен от гугла/эпла не получит ему нечем подтвердить что он реальное приложение
второе push-confirmation в активные сессии при попытке нового входа как у телеги whatsapp signal . даже если каким то чудом attestation обошли без подтверждения с уже активного устройства жертвы новая сессия не выпускается
всё остальное (Origin SDK-токен в одиночку JA3-привязка IP-лимиты) слабые меры тут ты прав . спасибо что разобрал внимательно сам бы не заметил часть слабостей
это не мой комент ))) но шутку оценил лайк поставил.
всегда рад помочь