КРАТКИЙ СМЫСЛ-ПЕРЕСКАЗ СУТИ ПРОБЛЕМЫ

Существует мнение, что многофакторная защита авторизации, гарантировано защищает аккаунты от взлома. Но это не совсем так.

Несмотря на активное внедрение многофакторной аутентификации (MFA), киберпреступники научились обходить её с помощью всё более изощрённых методов.

Один из них — атаки типа «противник посередине» (Adversary-in-the-Middle, AiTM), которые особенно эффективно реализуются через обратные прокси-серверы.

Эти атаки позволяют перехватывать не только логины и пароли, но и сессионные cookies, открывая злоумышленникам путь в защищённые аккаунты, даже если включена MFA.

Популярность этого метода подкрепляется удобством: благодаря наборам инструментов «Фишинг как услуга» (Phishing-as-a-Service, PhaaS) , таких как:
Tycoon 2FA, Evilproxy, Rockstar 2FA и других.

Даже неспециалисты могут запустить такую кампанию.

Разработчики этих комплектов постоянно обновляют их, добавляя функции обхода защитных механизмов, маскировки трафика и сбора дополнительных данных.

Например, инструменты ограничивают доступ к фишинговым страницам только по точной ссылке, используют фильтрацию по IP-адресу и User-Agent, внедряют динамически обфусцированный JavaScript и задерживают активацию ссылок, чтобы обойти защиту на стороне почтовых сервисов.

Фишинговые прокси работают по схеме:
Пользователь переходит по ссылке, указывает логин и пароль, а затем подтверждает MFA.

Всё это происходит на настоящем сайте — просто через прокси-сервер атакующего.

После успешной аутентификации сайт выдаёт сессионную cookie, которую перехватывает злоумышленник. В его руках оказывается полный доступ к учётной записи.

Некоторые атакующие тут же добавляют своё MFA-устройство в профиль жертвы, чтобы сохранить доступ и после окончания текущей сессии.

БОЛЕЕ ПОДРОБНОЕ ИЗУЧЕНИЕ ПРОБЛЕМЫ "
Современный фишинг: обход MFA. Автор: Джейсон Шульц"

Киберпреступники обходят многофакторную аутентификацию (MFA), используя атаки типа «злоумышленник посередине» (AiTM) через обратные прокси-серверы, перехватывая учётные данные и файлы cookie для аутентификации.

• Разработчики таких комплектов «Фишинг как услуга» (PhaaS), как Tycoon 2FA и Evilproxy, добавили функции, которые упрощают их использование и затрудняют обнаружение.
  

• WebAuthn, решение для многофакторной аутентификации без пароля, использующее криптографию с открытым ключом, предотвращает передачу пароля и обнуляет серверные базы данных аутентификации, обеспечивая надёжную защиту от атак с обходом многофакторной аутентификации.
  

• Несмотря на значительные преимущества в плане безопасности, WebAuthn внедряется медленно. Компания Cisco Talos рекомендует организациям пересмотреть свои текущие стратегии многофакторной аутентификации в свете этих развивающихся фишинговых угроз.

В течение последних тридцати лет фишинг был основным средством в арсенале многих киберпреступников.

Все специалисты по кибербезопасности знакомы с фишинговыми атаками: преступники выдают себя за сайт, которому доверяют, в попытке вынудить жертв социальной инженерии к разглашению личной информации, такой как имена пользователей учетных записей и пароли.

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

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

Какое-то время эти методы работали, но по мере того, как фишинговые атаки становились все более изощренными и целенаправленными, фильтры спама и обучение пользователей становились менее эффективными.

В основе этой проблемы лежит тот факт, что имена пользователей часто легко угадать или вычислить, а люди, как правило, очень плохо используют надёжные пароли. Люди также склонны повторно использовать одни и те же слабые пароли на разных сайтах. Киберпреступники, зная имя пользователя и пароль жертвы, часто пытаются взломать учётные данные и войти на разные сайты, используя одну и ту же комбинацию имени пользователя и пароля.

Чтобы подтвердить подлинность пользователей, системы аутентификации обычно используют как минимум один из трёх методов или факторов аутентификации:

• Что-то, что вы знаете (например, имя пользователя и пароль)

• Что-то, что у вас есть (например, смартфон или USB-ключ)

• Что-то, чем вы являетесь (например, ваш отпечаток пальца или распознавание лица)

В условиях появления всё более изощрённых фишинговых сообщений использование только одного фактора аутентификации, такого как имя пользователя и пароль, является проблематичным.
Многие сетевые администраторы в ответ на это внедрили многофакторную аутентификацию, которая включает дополнительный фактор, например SMS-сообщение или push-уведомление, в качестве дополнительного шага для подтверждения личности пользователя при входе в систему.
Благодаря включению дополнительного фактора в процесс аутентификации скомпрометированные имена пользователей и пароли становятся гораздо менее ценными для киберпреступников.
Однако киберпреступники — изобретательные люди, и они нашли хитрый способ обойти многофакторную аутентификацию. Добро пожаловать в безумный мир обхода многофакторной аутентификации!

Как злоумышленники обходят MFA?

Чтобы обойти MFA, злоумышленники встраиваются в процесс аутентификации с помощью атаки «злоумышленник посередине» (AiTM).

Как правило, это делается с помощью обратного прокси-сервера. Обратный прокси-сервер функционирует как сервер-посредник, принимающий запросы от клиента и перенаправляющий их на реальные веб-серверы, к которым клиент хочет подключиться.

Чтобы обойти многофакторную аутентификацию, злоумышленник настраивает обратный прокси-сервер и рассылает фишинговые сообщения как обычно. Когда жертва подключается к обратному прокси-серверу злоумышленника, он перенаправляет трафик жертвы на настоящий сайт.
С точки зрения жертвы, сайт, к которому она подключилась, выглядит подлинным — и это так!
Жертва взаимодействует с законным сайтом.

Единственное отличие, заметное жертве, — это расположение сайта в адресной строке браузера.

Вклинившись в этот процесс обмена данными между клиентом и сервером, злоумышленник может перехватить имя пользователя и пароль, которые отправляются от жертвы на легитимный сайт.

Это завершает первый этап атаки и запускает запрос многофакторной аутентификации, отправляемый жертве с легитимного сайта.

Когда ожидаемый запрос многофакторной аутентификации получен и одобрен, файл cookie аутентификации возвращается жертве через прокси-сервер злоумышленника, где он перехватывается злоумышленником.

Теперь злоумышленник владеет как именем пользователя и паролем жертвы, так и файлом cookie аутентификации с официального сайта.

Наборы для фишинга как услуги (PhaaS)

Благодаря готовым наборам инструментов «Фишинг как услуга» (Phaas) практически любой может проводить такого рода фишинговые атаки, не зная многого о том, что происходит «под капотом».

В этой сфере появились такие наборы инструментов, как Tycoon 2FA, Rockstar 2FA, Evilproxy, Greatness, Mamba 2FA и другие.

Со временем разработчики некоторых из этих наборов инструментов добавили функции, чтобы сделать их более простыми в использовании и менее заметными:

• Наборы для обхода MFA от Phaas обычно включают шаблоны для самых популярных фишинговых целей, чтобы помочь киберпреступникам в организации фишинговых кампаний.
  

• Наборы для обхода MFA ограничивают доступ к фишинговым ссылкам только для тех пользователей, у которых есть правильный фишинговый URL-адрес, и перенаправляют других посетителей на безопасные веб-страницы.
  

• Наборы для обхода многофакторной аутентификации часто проверяют IP-адрес и/или заголовок User-Agent посетителя, блокируя доступ, если IP-адрес соответствует известной компании по обеспечению безопасности/крадущемуся программному обеспечению или если User-Agent указывает на то, что это бот.
  
  Фильтры User-Agent также могут использоваться для дальнейшей нацеливания фишинговых атак на пользователей, использующих определённое оборудование/программное обеспечение.
  

• Наборы для обхода MFA с обратным прокси-сервером обычно вводят свой собственный код JavaScript на страницы, которые они предоставляют жертвам, для сбора дополнительной информации о посетителе и обработки перенаправлений после кражи файла cookie аутентификации.
  Эти скрипты часто динамически запутываются для предотвращения статического снятия отпечатков пальцев, что позволило бы поставщикам средств безопасности идентифицировать сайты атак в обход MFA.
  

• Чтобы обойти антифишинговые защиты, которые могут автоматически переходить по URL-адресам, содержащимся в электронном письме, в момент его получения, может быть предусмотрена короткая программируемая задержка между отправкой фишингового сообщения и активацией фишингового URL-адреса.

Ускоряют рост атак в обход MFA через обратный прокси общедоступные инструменты с открытым исходным кодом, такие как Evilginx. Evilginx дебютировал в 2017 году как модифицированная версия популярного веб-сервера с открытым исходным кодом nginx. Со временем приложение было переработано и переписано на Go и реализует собственный HTTP и DNS-сервер. Хотя он позиционируется как инструмент для тестирования red teams на проникновение, поскольку у него открытый исходный код, любой может скачать и модифицировать его.

К счастью для защитников, существуют общие для Evilginx и других инструментов для обхода MFA характеристики, которые могут указывать на то, что атака с обходом MFA уже началась:

• Многие серверы обратного прокси-сервера для обхода MFA размещены на относительно недавно зарегистрированных доменах/сертификатах.
  

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

• По умолчанию URL-адреса фишинговых приманок Evilginx состоят из 8 букв в смешанном регистре.
  

• По умолчанию Evilginx использует HTTP-сертификаты, полученные от LetsEncrypt. Кроме того, сертификаты, которые он создаёт по умолчанию, имеют организацию «Evilginx Signature Trust Co.» и общее имя «Evilginx Super-Evil Root CA».
  

• После того, как злоумышленник перехватил файл cookie для аутентификации сеанса, он обычно загружает этот файл cookie в свой собственный браузер, чтобы выдать себя за жертву.
  
  Если злоумышленник не будет осторожен, какое-то время два разных пользователя с разными пользовательскими агентами и IP-адресами будут использовать один и тот же файл cookie сеанса. Это можно обнаружить с помощью веб-журналов или продуктов безопасности, которые ищут такие вещи, как “невозможное перемещение”.
  

• Чтобы жертва не переходила по ссылке, которая перенаправляет ее с фишингового сайта, обратный прокси-сервер Evilginx переписывает URL-адреса, содержащиеся в HTML-формате, с законного сайта.
  
  Популярные цели фишинга могут использовать очень специфические URL-адреса, и сетевые защитники могут искать эти URL-адреса, обслуживаемые с серверов, отличных от легитимного сайта.
  

• Многие реализации обратного прокси-сервера для обхода многофакторной аутентификации написаны с использованием встроенных в язык программирования реализаций Transport Layer Security (TLS). Таким образом, отпечаток TLS обратного прокси-сервера и легитимного веб-сайта будет отличаться.

WebAuthn спешит на помощь?

FIDO (Быстрая идентификация личности онлайн) Альянс и W3C создали WebAuthn (Web Authentication API) - спецификацию, которая позволяет выполнять MFA на основе криптографии с открытым ключом. WebAuthn, по сути, не имеет пароля.

Когда пользователь регистрируется в MFA с помощью WebAuthn, генерируется криптографическая ключевая пара. Закрытый ключ хранится на устройстве пользователя, а соответствующий открытый ключ хранится на сервере.

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

Пароли никогда не вводятся в веб-форму и не передаются по интернету. Это также делает базы данных аутентификации на стороне сервера бесполезными для злоумышленников. Что хорошего в краже открытого ключа?

Рисунок 3. Процесс аутентификации WebAuthn.

В качестве дополнительного уровня безопасности учётные данные WebAuthn также привязываются к источнику веб-сайта, на котором они будут использоваться. Например, предположим, что пользователь переходит по ссылке в фишинговом сообщении на контролируемый злоумышленником обратный прокси-сервер mfabypass.com, который выдаёт себя за банк пользователя.

Адрес в адресной строке веб-браузера не будет соответствовать адресу банка, к которому привязаны учётные данные, и процесс многофакторной аутентификации WebAuthn завершится ошибкой.

Привязка учётных данных к определённому источнику также предотвращает связанные с идентификацией атаки, такие как переполнение учётными данными, когда злоумышленники пытаются повторно использовать одни и те же учётные данные на нескольких сайтах.

Несмотря на то, что спецификация WebAuthn была впервые опубликована в 2019 году, она внедрялась относительно медленно.

Судя по данным телеметрии аутентификации Cisco Duo за последние шесть месяцев, аутентификация с помощью WebAuthn по-прежнему составляет очень небольшой процент от всех аутентификаций с помощью MFA.

В определенной степени это понятно. Многие организации, возможно, уже внедрили другие типы MFA и могут считать, что это достаточная защита.

Однако они могут захотеть пересмотреть свой подход, поскольку все больше и больше фишинговых атак используют стратегии обхода MFA.

Покрытие

Cisco Secure Endpoint (ранее AMP для конечных устройств) идеально подходит для предотвращения запуска вредоносного ПО, описанного в этой статье. Попробуйте Secure Endpoint бесплатно здесь.

Cisco Secure Email (ранее Cisco Email Security) может блокировать вредоносные электронные письма, отправляемые злоумышленниками в рамках их кампании. Вы можете бесплатно попробовать Secure Email здесь.

Cisco Secure Firewall (ранее называвшиеся Next-Generation Firewall и Firepower NGFW), такие как Threat Defense Virtual, Adaptive Security Appliance и Meraki MX, могут обнаруживать вредоносные действия, связанные с этой угрозой.

Cisco Secure Network/Cloud Analytics (Stealthwatch/Stealthwatch Cloud) автоматически анализирует сетевой трафик и предупреждает пользователей о потенциально нежелательной активности на каждом подключенном устройстве.

Cisco Secure Malware Analytics (Threat Grid) выявляет вредоносные двоичные файлы и встраивает защиту во все продукты Cisco Secure.

Cisco Secure Access — это современная облачная служба безопасности (SSE), построенная на принципах нулевого доверия. Secure Access обеспечивает бесперебойный, прозрачный и безопасный доступ к интернету, облачным сервисам или частным приложениям независимо от того, где работают ваши пользователи.

Если вас интересует бесплатная пробная версия Cisco Secure Access, пожалуйста, свяжитесь с представителем Cisco или авторизованным партнером.

Umbrella, защищенный интернет-шлюз Cisco (SIG), блокирует доступ пользователей к вредоносным доменам, IP-адресам и URL-адресам независимо от того, находятся ли пользователи в корпоративной сети или за ее пределами.

Cisco Secure Web Appliance (ранее Web Security Appliance) автоматически блокирует потенциально опасные сайты и проверяет подозрительные сайты перед доступом к ним пользователей.

Дополнительные средства защиты с учётом особенностей вашей среды и данных об угрозах доступны в Центре управления брандмауэром.

Cisco Duo обеспечивает многофакторную аутентификацию пользователей, гарантируя, что только авторизованные пользователи получат доступ к вашей сети.

Недавно в СМИ появилась новость:

"Новые языковые модели от OpenAI оставляют невидимые водяные знаки в сгенерированном тексте."
Важно отметить, что символы находятся в случайных местах текста. В окне браузера, популярных онлайн-редакторах документов и Microsoft Word эти символы по умолчанию не видно.

Водяные знаки вшитые моделями o4-mini и o3 представляют собой коды неразрывного пробела в формате Unicode — они остаются незаметными в большинстве текстовых редакторов, но могут быть выявлены в специализированных инструментах, таких как Sublime Text и VS Code.

Хотя ранее была новость:
OpenAI не будет ставить ватермарки на текст ChatGPT. OpenAI пока не будет внедрять водяные знаки на тексты, созданные ChatGPT, несмотря на наличие такой технологии и инструмента для ее обнаружения.
Это решение связано с опасениями, что внедрение водяных знаков может негативно повлиять на использование ChatGPT и прибыль компании.

КАК УБРАТЬ НЕВИДИМЫЕ ЗНАКИ?

Но изначально, введения скрытных водяных символов, не имеет смысла. Т.к очень легко обходиться, даже без написания скриптов или софта.

Первый способ.
Сделать скриншот текста, и отправить его на распознание в "Яндекс Картинки" или программу типа ABBYY FineReader т.п.
Распознается текст уже в виде обычных символов.

Второй способ.
Конвертировать текст в аудио-звуковой формат(надиктовывая в диктофон ил по помощи нейросетей и софта), а затем звуковой файл конвертировать в текстовый.

Третий способ(шутка).
Вручную перепечатать текст, глядя на ответ нейросети. Здесь Технологии скрытного шифрования бессильны.

Это скриншот поста 2024 года из Телеграм https://t.me/olegtsarov/20331
Верить или не верить посту политика уехавшего из Украины в РФ, дело каждого.

Полная цитата из телеграм-поста:

Помню разговор с одним из офицеров СБУ во время Майдана. Я ему дал телефон, чтобы он мне установил мессенджер, который был разработан нашими общими знакомыми и точно не прослушивался.

Я им долго еще пользовался после, но потом устал бороться с глюками и багами и удалил его. У ребят это был некоммерческий проект, а чтобы все время его модернизировать, требовались деньги и усилия.

Но дело не в этом. Сотрудник СБУ, сейчас он работе в ФСБ, говорит: «Олег Анатольевич, у вас, что Viber стоит?».

Я ему говорю, что да, так как некоторые мои знакомые общаются в Viber. Хотя большинство в WhatsApp. Я ничего секретного в нем не пересылаю.

Он мне говорит: «Дело не в этом, ни у одного сотрудника СБУ Viber не стоит.

Мы обнаружили, что если у вас установлен Viber, американцы как-то могут через него заходить на ваш телефон и читать не только переписку в этом мессенджере, но и получают доступ ко всей информации в смартфоне — заметки, фотографии и прочее, видят переписку во всех мессенджерах».
Вот с того времени у меня нет Viber.

3) Попытка урегулирования (скриншоты в конце)

В ответ на требование о верификации я направил компании разъяснение, в котором указал, что готов предоставить персональные данные в пределах, предусмотренных законодательством РФ и заключенным договором. В частности, я отказался передавать копии страниц паспорта, содержащие сведения о семейном положении, детях и других данных, не относящихся к идентификации клиента. Я уведомил «Рег.ру» о том, что их требования незаконны, а также я сообщил, что ПО включено в реестр отечественного ПО РФ, и что подобные действия создают препятствия для его работы. Кроме того, я запросил документальное обоснование необходимости такого сбора, а также объяснение целей и методов обработки этих данных.

Сложность ситуации усугубил еще и тот факт, что 30 августа 2024 года выпало на пятницу. Сотрудники Рег.ру заблокировали домены и спокойно ушли на выходные, это обычная практика у «лидера» среди регистраторов доменных имен. Ответ от компании поступил только 2 сентября, на третий день блокировки.

В ответ на мой отказ предоставить избыточные данные сотрудники «Рег.ру» продолжили настаивать на передаче полного комплекта документов, направлять мне формальные отписки, утверждая, что их действия соответствуют законодательству РФ, но не предоставляя ссылок на конкретные нормы права и честно говоря, общаясь абсолютно без ориентации на клиента, максимально непрофессионально. Цитата на мое требования предоставить обоснование сбора таких данных:

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

Кроме того, хочу отметить, что компания «Рег.ру» неоднократно получала персональные данные, подписанные электронной цифровой подписью (ЭЦП) владельца данных, что исключает возможность недостоверности предоставленных сведений. Полученные «Рег.ру» данные логически легко подтверждаются с данными, содержащимися в реестре программного обеспечения.

4) Переписка с руководством

После нескольких дней бесполезной переписки с технической поддержкой и юридическим отделом «Рег.ру» я попытался напрямую выйти на руководство компании. Через общие контакты мне удалось получить личный Telegram генерального директора «Рег.ру» Кузьмичёва Андрея Юрьевича. Я направил ему детальное описание ситуации, включая все юридические обоснования неправомерности их действий.

Генеральный директор изначально проявил заинтересованность и запросил номер обращения в системе поддержки, однако после предоставления этой информации прекратил общение и проигнорировал дальнейшие сообщения, в том числе касающиеся ответа Роскомнадзора.

5) Вынужденная передача данных

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

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

После получения zip-архива с запрашиваемыми данными ООО «Рег.ру» провело их неправомерную проверку, так как не имело оснований ни на их запрос, ни на их обработку, после чего домены были разблокированы. Постепенно заработало ПО и все сопутствующие сервисы (хотя обновление DNS-записей может длиться до 72 часов).

6) Обращение в Роскомнадзор

После многочисленных попыток урегулировать вопрос непосредственно с Рег.ру, включая общение с генеральным директором, мной было подано три обращения в Роскомнадзор. Первые два обращения были проигнорированы ведомством, однако третье обращение инициировало полноценное разбирательство.

29 января 2025 года Управление Роскомнадзора по Центральному федеральному округу направило мне официальный ответ №5893-02-11/77, в котором указало, что у ООО «Рег.ру» отсутствовали законные основания для запроса копий всех страниц паспорта. Ведомство обязало компанию привести свою деятельность в соответствие с требованиями законодательства.

Ответ Роскомнадзора был отправлен в юридическую поддержку Рег.ру и проигнорирован что в моем понимании подтверждает тот факт, что компания осознает незаконность своих действий, но предпочитает игнорировать обращения пользователей и предписания надзорных органов, рассчитывая, что большинство пострадавших клиентов не пойдут дальше и не доведут дело до суда. Хотя, признаюсь откровенно, мое сообщение далеко не отличалось официальным тоном и скорее напоминало те, что часто приходят от самой компании Рег.ру — бессмысленные и раздражающие с ноткой злорадства и угроз (естественно в рамках закона, по типу подачи группового иска).

7) Подача иска и заключение для текущей статьи (вероятно будет продолжение).

В соответствии с выводом Федеральной службы по надзору в сфере связи, информационных технологий и массовых коммуникаций (Роскомнадзор), я намерен подать иск в суд по следующим основаниям:

• Нарушение условий договора со стороны регистратора.

• Незаконный сбор и обработка персональных данных.

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

• Моральная компенсация за понесенный моральный ущерб и ущерб репутации.

Дополнительно, я хочу инициировать подачу именно коллективного иска от всех пострадавших пользователей, которые столкнулись с аналогичными нарушениями со стороны компании «Рег.ру», если таковые наберутся. Судебные расходы по делу я беру на себя.

Если вы также стали жертвой требования о предоставлении избыточных персональных данных или других незаконных действий со стороны компании «Рег.ру», присоединяйтесь к коллективному иску. Контактный адрес: class_action_regru@bk.ru.

Я буду благодарен всем редакторам и пользователям, которые распространит данную информацию, а также благодарю всех, кто дочитал до конца.

Скриншоты.