Многие уже внедрили второй фактор для доступа к корпоративным сервисам, это практически стандарт в ИБ. И, казалось бы, проблема компрометации учетных записей должна была заметно сократиться. Однако согласно статистике, атаки на учетные записи продолжают оставаться одним из наиболее распространенных сценариев компрометации.
Автор: Виктор Чащин, директор по стратегическому развитию, МУЛЬТИФАКТОР
Причина, по сути, связана не с отсутствием MFA, а с изменением самих атак. Фишинг уже перестал быть просто попыткой выманить пароль через поддельную форму входа – злоумышленники активно используют атаки типа Adversary-in-the-Middle (AiTM). В этом сценарии фишинговый сайт выступает посредником между пользователем и реальным сервисом, проксируя процесс аутентификации.
Выглядит это так. Пользователь вводит учетные данные на фишинговом сайте и подтверждает вход вторым фактором, полагая, что взаимодействует с легитимным сервисом. Однако поскольку вся процедура проходит через инфраструктуру атакующего, злоумышленник получает не только пароль, но и активную сессию пользователя. Как видно, факт сам по себе использования MFA не предотвращает компрометацию.
Поэтому в профессиональной среде появился термин Phishing-Resistant MFA – многофакторная аутентификация, устойчивая к фишинговым атакам.
Почему так получилось?
Большинство распространенных факторов аутентификации создавались во времена, когда основной угрозой считалась кража пароля. Второй фактор должен был подтвердить, что пользователь действительно владеет устройством или каналом связи. Однако архитектура тех решений допускает воспроизведение фактора вне контекста конкретного сервиса. Код из СМС, одноразовый пароль из приложения-аутентификатора или пуш-подтверждение могут быть введены на любом сайте. С точки зрения системы они выглядят корректно, если введены в допустимый интервал времени. Именно этим пользуются атакующие в сценариях проксирования аутентификации.
Другими словами, проблема в том, что традиционная MFA не проверяет, где именно пользователь проходит процедуру входа. Если злоумышленник способен принять запрос от пользователя и передать его настоящему сервису в реальном времени, второй фактор будет принят так же, как и при легитимном входе.
Да, традиционная MFA по-прежнему защищает, например, от перебора паролей или от утечек учетных данных. Но при этом они оказываются уязвимыми к современному фишингу.
Phishing-Resistant MFA
Термин Phishing-Resistant MFA описывает принципиально иной подход к аутентификации. Здесь важен не просто второй фактор, а архитектура подтверждения личности пользователя.
Главное отличие заключается в том, что подтверждение входа привязывается к конкретному домену сервиса и конкретному устройству. Устройство пользователя получает запрос от сервиса и выполняет его криптографическую подпись запроса.
Если пользователь находится на поддельном сайте, подпись не будет сформирована. Устройство проверяет адрес ресурса и не позволит использовать ключ для другого домена. Таким образом, посредник не может воспроизвести процедуру аутентификации.
На практике такие механизмы обычно реализуются на базе стандартов FIDO2 и WebAuthn. Они используют пару криптографических ключей: закрытый ключ хранится на устройстве пользователя, а открытый ключ – на стороне сервиса. Закрытый ключ никогда не передается в инфраструктуру аутентификации и не может быть извлечен злоумышленником. Именно поэтому подобные методы считаются устойчивыми к фишинговым атакам. Даже если пользователь попадает на поддельный сайт, злоумышленник не получает пригодный для использования второй фактор.
Внедрение Phishing-Resistant MFA обычно строится вокруг аппаратных или платформенных аутентификаторов. Это могут быть физические ключи безопасности, а также встроенные механизмы устройств, например TPM или Secure Enclave.
При регистрации пользовательского устройства создается уникальная пара ключей. Закрытый ключ остается на устройстве и используется для подписи запросов аутентификации. Открытый ключ сохраняется в системе управления идентификацией и используется для проверки подписи. При попытке входа сервис формирует криптографический вызов. Устройство пользователя подписывает его закрытым ключом и возвращает результат. Если подпись корректна, система подтверждает аутентификацию.
В корпоративной инфраструктуре такие решения, как правило, интегрируются с существующими каталогами пользователей и системами управления доступом. Чаще всего речь идет о взаимодействии с каталогами учетных записей, корпоративными приложениями и инфраструктурой удаленного доступа.
Впрочем, криптография – безусловно надежный, но не единственный способ бороться с AiTM-атаками. Второй механизм – разделение каналов передачи аутентификационных данных: в одном происходит передача логина и пароля, а во втором – подтверждение второго фактора. Например, пользователь вводит логин и пароль в браузере, а подтверждение второго фактора выполняет через отдельное мобильное приложение. Но при этом важно, чтобы запрос на второй фактор инициировался доверенной системой через защищенный API.
Отметим, что на практике даже если современная аутентификация используется для основных сервисов, уязвимости могут сохраняться из-за наследованных компонентов инфраструктуры (то что называют термином "легаси").
Наиболее типичными проблемами становятся:
- использование резервных методов входа через СМС или одноразовые коды;
- наличие устаревших протоколов доступа;
- сервисные учетные записи без строгой аутентификации;
- долгоживущие сессии, которые можно использовать после компрометации;
- разрозненная система управления доступом.
Да, организация формально внедряет современную MFA, к ней вопросов нет, но при этом сохраняются альтернативные пути входа, которые могут использовать злоумышленники при атаке.
Устойчивость к фишингу на примере MULTIFACTOR
Большинство конкретных корпоративных решений MFA развиваются эволюционно: от простых одноразовых кодов к более сложным сценариям, включающим контроль контекста доступа и привязку факторов к устройству. Решение MULTIFACTOR [1] в этом смысле представляет собой типичный и показательный пример такой архитектуры.
Система выстраивается как отдельный слой аутентификации, встроенный в инфраструктуру заказчика. При этом проверка логина и пароля остается на стороне целевой системы (например, 1С, VPN или корпоративного портала), а второй фактор обрабатывается через внешний сервис. Такой подход позволяет не вмешиваться в логику приложений, добавлять защиту поверх существующих механизмов, и при этом эффективно бороться с AiTM-атаками на аутентификацию. Мобильное приложение MULTIFACTOR использует подтверждение запросов входа на привязанном устройстве, а также механизмы ограничения повторяющихся запросов аутентификации. Это позволяет снижать эффективность атак, основанных на массовой отправке пуш-запросов пользователю.
Ключевой элемент MULTIFACTOR – взаимодействие через API. После успешной проверки учетных данных защищаемая система инициирует запрос ко второму фактору, используя служебные параметры (API Key и секрет). Эти данные привязаны к конкретной организации и не доступны извне. Соответственно, злоумышленник не может корректно инициировать проверку второго фактора без доступа к внутренней инфраструктуре, даже если ему удалось воспроизвести интерфейс входа. Подобный подход существенно усложняет реализацию AiTM-атак и снижает эффективность типовых фишинговых фреймворков.
С точки зрения пользователя процесс выглядит стандартно: после ввода логина и пароля требуется подтвердить вход. А за этой простотой скрывается разделение потоков аутентификации – пароль проверяется в инфраструктуре заказчика, а второй фактор проходит через отдельный контур.
Важная особенность реализации – поддержка различных каналов второго фактора. В зависимости от сценария это могут быть мобильное приложение, пуш-подтверждение, Telegram, eXpress, звонок или СМС. При этом более устойчивыми к фишингу считаются методы, в которых подтверждение происходит на привязанном устройстве пользователя, а не через передаваемый код. Интеграция с корпоративными системами реализуется через адаптеры и плагины. Например, для 1С используется отдельный модуль, который встраивается в процесс аутентификации и добавляет шаг подтверждения второго фактора. Аналогичным образом решение может быть подключено к RDP, VPN и другим сервисам, включая те, которые изначально не поддерживают MFA.
С архитектурной точки зрения система построена по гибридной модели. Облачная часть отвечает за обработку запросов и управление политиками, а компоненты на стороне заказчика обеспечивают интеграцию с конкретными системами. Это позволяет централизованно обновлять механизмы защиты и быстрее реагировать на новые сценарии атак.
При этом важно понимать, что устойчивость к фишингу в таких решениях достигается не одним механизмом, а их комбинацией. Помимо собственно второго фактора используются дополнительные меры – контроль IP-адресов, белые и черные списки, ограничения по времени доступа, а также базовые антифрод-правила. Они не устраняют полностью сценарии проксирующего фишинга, но позволяют выявлять аномалии и снижать вероятность успешной атаки.
Заключение
Для специалистов по безопасности вопрос применения MFA уже постепенно выходит за рамки выбора конкретного фактора. Речь идет о более широком изменении архитектуры аутентификации.
Phishing-Resistant MFA фактически переводит процесс проверки пользователя из модели передачи секретов в модель криптографического подтверждения. Пользователь больше не сообщает системе код или пароль. Его устройство подтверждает владение ключом, привязанным к конкретному сервису. Такой подход значительно усложняет атаки, основанные на фишинге и проксировании аутентификации. Даже если пользователь взаимодействует с поддельным интерфейсом, злоумышленник не может получить пригодный для использования фактор.
Разумеется, внедрение подобной архитектуры требует пересмотра существующих процессов доступа и интеграции с корпоративной инфраструктурой. Именно в этом направлении, судя по всему, будет развиваться корпоративная аутентификация в ближайшие годы.
Система MULTIFACTOR демонстрирует характерный для рынка подход: переход от простого второго шага к более сложной архитектуре аутентификации, где безопасность определяется не столько типом фактора, сколько контекстом его использования и способом интеграции в инфраструктуру.
Реклама: ООО «МУЛЬТИФАКТОР». ИНН 9725026066. Erid: 2SDnje9imNJ