Почему наличие 2FA не равно устойчивости защиты

2FA - эффективный метод повышения уровня безопасности ИТ-инфраструктуры, именно поэтому его внедрение становится нормой жизни для современной компании. Однако эта мера не является 100% гарантией устойчивости защиты при аутентификации. Эффективность 2FA зависит от ряда факторов - от внешних угроз и уровня ИБ-грамотности сотрудников до способа реализации самого технического решения.

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

Обойти второй фактор аутентификации вполне реально и без «модной» фишинговой рассылки - используя системные ошибки вендора или некорректную интеграцию решений. Классический пример такого «обхода» мы рассмотрим на примере кейса ITG Security.

Фишинговая атака Adversary-in-the-Middle - как это было

Основной целью тестирования было оценить, есть ли возможность перехватить токен доступа к ADFS и обойти многофакторную аутентификацию. Для технической проверки пентестеры смоделировали фишинговую атаку типа Adversary-in-the-Middle.

По итогам пентеста удалось получить доступ к токену доступа ADFS. Как условному «хакеру» это удалось и в чем причина успешной атаки - разбираем в подробностях.

Атака с позиции пентестера

В процессе тестовой фишинговой атаки участвовало 4 сущности:

• пользовательский браузер;
• сервер пентестера;
• легитимный сервер ADFS;
• сервер многофакторной аутентификации.

Пошаговое описание атаки выглядело так:

Шаг №1 - доставка фишинговой ссылки

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

Шаг №2 - проксирование легитимного контента

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

Шаг №3 - перехват учетных данных пользователя

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

Шаг №4 - проксирование MFA-вызова

Легитимный сервер получает данные пользователя, перенаправленные хакером. Если логин и пароль правильные, то ADFS-сервер инициирует многофакторную аутентификацию. Сервер многофакторной аутентификации отправляет OTP-код, push-уведомление или иной challenge - который снова попадает на сервер атакующего и перенаправляется оттуда пользователю.

Шаг №5 - прохождение многофакторной аутентификации пользователем

Пользователь, по-прежнему находящийся на сервере хакера, подтверждает MFA-вызов, а его ответ снова проксируется на легитимный сервер.

Шаг №6 - перехват токена доступа

ADFS-сервер «опознает» пользователя как легитимного и выпускает токен доступа (Access Token). Так как токен передается через сервер атакующего, последний получает возможность перехватить его и сохранить копию.

Шаг №7 - получение полноценного доступа к защищенным ресурсам

Используя перехваченный токен доступа, атакующий сервер получает Access Cookie для ADFS.
Теперь хакер получил возможность использовать перехваченный cookie и / или токен, чтобы получить доступ к ресурсам компании от имени пользователя. Сделать это можно с любого устройства и проходить аутентификацию повторно не придется.

Атака глазами пользователя

Если говорить коротко, то пользователь ничего не заметил.

Пользователь во время такой фишинговой атаки не видит чего-то подозрительного. С его точки зрения происходит абсолютно нормальный «штатный» процесс:

1. Перейдя по ссылке пользователь попадает на привычную страницу входа в корпоративную систему - хакер проксирует оригинальную страницу, поэтому визуальных отличий не будет. Это идеальный «клон», и отличить его «на глаз» просто невозможно.
2. Пользователь вводит свой логин и пароль - все по-прежнему выглядит обычно.
3. После ввода учетных данных пользователю приходит запрос на прохождение многофакторной аутентификации.
4. Пользователь подтверждает второй фактор и успешно авторизуется. Далее он продолжает работать как всегда.

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

Может ли пользователь понять, что сервер «фальшивый»? Теоретически у него есть один шанс - обратить внимание на доменное имя в адресной строке браузера. Однако на практике мало кто проверяет URL при каждом переходе по ссылкам - в особенности если страница выглядит именно такой, какой пользователь привык ее видеть.
 

Секрет успеха атаки

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

• Токен доступа не имел привязки к устройству пользователя;
• Token Binding отсутствовал;
• Сессионная cookie  без привязки к контексту;
• Однократное подтверждение MFA, без участия многофакторной аутентификации в валидации сессии в дальнейшем.

То есть любой, кто получил копию cookie или токена (способ получения при этом не принципиален), имеет возможность использовать их на любом устройстве, чтобы получить доступ к корпоративным ресурсам. С точки зрения системы он будет вполне легитимным пользователем.

В чем была ошибка компании

Как устранить уязвимость

Решить проблему вполне реально и для этого существует эффективный инструмент - внедрение Phishing-resistant MFA. Этот метод проверки личности ориентирован на противодействие фишиингу. В основе Phishing-resistant MFA - протколы, обеспечивающие взаимную аутентификацию сервера и клиента. То есть в рамках аутентификации сервер дополнительно получает криптографическое подтверждение того, что пользователь обращается к нему с корпоративного устройства, а клиент - подтверждение подлинности корпоративного сервера.

Какие технологии можно порекомендовать для устранения уязвимости:

• WebAuthn / FIDO2 - обеспечивает аутентификацию с привязкой к конкретному домену;
• Certificate-Based Authentication (CBA) - использует клиентские сертификаты и криптографическое подтверждение владения закрытым ключом. Такой подход обеспечивает более высокий уровень защиты и относится к phishing-resistant методам аутентификации, поскольку подтверждение личности не сводится к вводу одноразового кода, который можно перехватить или выманить через фишинг.
• Microsoft Entra ID с Conditional Access может значительно снизить риск компрометации учетных записей, но только при корректной настройке и использовании устойчивых к фишингу методов аутентификации. Сам по себе Conditional Access не устраняет все сценарии атак так как уровень защиты зависит от выбранных Authentication Strengths, а также дополнительных мер против перехвата и повторного использования токенов.

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