«Проблема не в том, что MFA можно обойти. Проблема в том, что мы доверяем физическому устройству, не задумываясь о том, кто его контролирует. Атака через подмену терминала — это не взлом, а социальная инженерия, нацеленная на самую слабую точку: наше ожидание, что публичная инфраструктура безопасна по умолчанию.»
Как работает классический вход с MFA
Чтобы понять уязвимость, нужно разобраться в стандартном процессе. Многофакторная аутентификация (MFA) в веб-приложениях обычно строится по схеме «знание + владение». Пользователь вводит логин и пароль (первый фактор) на странице входа. После успешной проверки сервер генерирует одноразовый код или запрос на подтверждение и отправляет его через второй канал — чаще всего в мобильное приложение-аутентификатор (например, TOTP) или по SMS.
Ключевой момент: сессия создаётся на сервере только после успешного подтверждения второго фактора. Браузеру выдаётся уникальный токен сессии (обычно в виде cookie), который и служит пропуском для всех последующих действий. Без этого токена злоумышленник, даже зная пароль, не может получить доступ.
Сценарий атаки: поддельный терминал в общественном месте
Представьте рабочую ситуацию: сотрудник компании в командировке заходит в коворкинг или кафе, чтобы проверить рабочую почту. Он видит публичный компьютер или терминал с табличкой «Быстрый доступ к Wi-Fi и сервисам». Устройство выглядит как обычный киоск — монитор, клавиатура, возможно, сенсорный экран.
На самом деле этот терминал полностью контролируется злоумышленником. Это может быть специально подготовленный мини-ПК с предустановленным вредоносным ПО или даже легитимный компьютер, к которому физически получили доступ. Его задача — имитировать нормальный процесс входа, чтобы перехватить данные.
Техническая реализация обхода MFA
Атака строится не на взломе криптографии, а на манипуляции потоками данных между пользователем и настоящим сервером. Терминал выступает в роли человека посередине (Man-in-the-Middle, MitM), но на уровне браузера.
Этап 1: Перехват учётных данных
Пользователь открывает браузер на терминале и переходит на корпоративный портал. Терминал показывает точную копию страницы входа. Когда сотрудник вводит логин и пароль, скрипт на терминале немедленно отправляет эти данные на сервер злоумышленника, а параллельно — на настоящий сервер компании.
Настоящий сервер, получив верные логин и пароль, запускает процесс MFA: генерирует одноразовый код. В этот момент терминал показывает пользователю поддельную страницу с сообщением: «Введите код из приложения-аутентификатора для завершения входа».
[ИЗОБРАЖЕНИЕ: Схема потока данных, показывающая, как терминал перехватывает логин/пароль и передаёт их одновременно злоумышленнику и легитимному серверу, а затем запрашивает у пользователя код MFA.]
Этап 2: Обход второго фактора
Это сердце атаки. Пользователь, видя привычный запрос, открывает своё мобильное приложение (например, Google Authenticator или его корпоративный аналог), получает шестизначный код TOTP и вводит его на поддельной странице.
Код TOTP действителен короткое время, обычно 30 секунд. Как только пользователь ввёл код на терминале, вредоносный скрипт мгновенно использует его для завершения аутентификации на настоящем сервере от имени пользователя. Сервер, получив корректный код, создаёт сессию и отправляет в браузер сессионный cookie.
Но этот cookie приходит не в браузер пользователя, а в браузер, управляемый злоумышленником на терминале. Теперь атакующий обладает действующей, полностью аутентифицированной сессией.
Этап 3: Кража сессии и поддержание доступа
С этого момента терминал может выполнить несколько действий. Самый простой — передать украденный сессионный cookie на сервер атакующего, который затем может использовать его для доступа к аккаунту со своей инфраструктуры. Однако современные системы часто привязывают сессию к IP-адресу или User-Agent.
Более изощрённый метод — использование терминала как прокси. Сессия остаётся активной на самом терминале, а атакующий удалённо управляет браузером через инструменты вроде Selenium или Puppeteer, выполняя действия от имени жертвы: чтение писем, скачивание документов, отправку сообщений.
Чтобы пользователь ничего не заподозрил, после кражи сессии терминал может показать страницу с ошибкой («Временные неполадки с сервисом, попробуйте позже») или даже перенаправить на настоящий, уже авторизованный портал, создавая иллюзию успешного входа.
Почему это опасно и почему это работает
Главная сила этой атаки — в эксплуатации доверия к физическому окружению. MFA защищает от удалённых атак, когда злоумышленник не имеет физического доступа к устройству пользователя. Но здесь атакующий контролирует само устройство ввода. Пользователь психологически готов вводить свои данные на публичном терминале для доступа к Wi-Fi или сервису, не подозревая, что весь трафик скомпрометирован.
С технической стороны, атака обходит MFA, потому что второй фактор используется по назначению — для входа на настоящий сервер. Проблема в том, что инициатором этого входа выступает не пользователь со своего доверенного устройства, а контролируемый терминал. MFA проверяет «что вы вводите» (код), но не «откуда и с какого устройства вы это делаете» в данном контексте.
Как обнаружить и предотвратить подобные атаки
Полностью полагаться на MFA как на серебряную пулю нельзя. Нужны дополнительные слои защиты, учитывающие контекст аутентификации.
Для пользователей (сотрудников)
- Никогда не использовать публичные или непроверенные устройства для входа в корпоративные системы. Это должно быть жёстким правилом.
- Обращать внимание на аномалии: нестандартный вид страницы входа, запрос кода MFA сразу, без ввода пароля (если это не поведение по умолчанию), ошибки сертификатов в браузере (HTTPS).
- Использовать аппаратные ключи безопасности (FIDO2/U2F): в отличие от TOTP, где код можно перехватить, ключ требует физического взаимодействия с устройством и криптографически привязан к домену сайта. Поддельный терминал не сможет воспроизвести этот запрос корректно.
Для администраторов и специалистов по безопасности
- Внедрение анализа риска входа (UEBA): системы должны оценивать контекст — с какого IP-адреса, из какой страны, с какого типа устройства происходит вход. Попытка входа с публичного IP, ассоциированного с интернет-кафе, после которого сразу следует доступ с IP из другой страны, должна блокироваться или требовать дополнительного подтверждения.
- Использование сертифицированных СЗИ: применение средств защиты информации, сертифицированных ФСТЭК России, для контроля доверенных рабочих мест и анализа поведения приложений может помочь в выявлении нестандартной активности.
- Сессионный контроль: привязка сессии не только к cookie, но и к отпечатку браузера, аппаратным характеристикам. Реализация механизмов единовременной активности сессии — если происходит новый вход, предыдущая сессия должна принудительно завершаться с уведомлением пользователя.
- Обучение и моделирование угроз: регулярное проведение учебных фишинговых атак, включая сценарии с имитацией публичной инфраструктуры, чтобы выработать у сотрудников устойчивые поведенческие паттерны.
Вывод
Поддельный терминал — это напоминание о том, что безопасность цепочки равна прочности её самого слабого звена. MFA — мощный инструмент, но он не защищает от компрометации точки ввода. Угроза смещается из цифровой плоскости в физическую и социальную. Защита требует комбинации технологических мер, таких как контекстная аутентификация и аппаратные ключи, и постоянного повышения осведомлённости пользователей о рисках, связанных с использованием неподконтрольной инфраструктуры. В условиях регуляторных требований 152-ФЗ и стандартов ФСТЭК подобные сценарии должны учитываться при оценке угроз и построении системы защиты персональных данных, где несанкционированный доступ к сессии сотрудника может привести к утечке значительных массивов информации.