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 и / или токен, чтобы получить доступ к ресурсам компании от имени пользователя. Сделать это можно с любого устройства и проходить аутентификацию повторно не придется.
