Двухфакторная аутентификация: реальные цифры сбоев и обхода защиты

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

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

Масштаб credential stuffing в журналах аутентификации

В исследовании Verizon анализировались журналы единого входа у провайдеров SSO за два года. Медианная дневная доля попыток аутентификации, классифицированных как credential stuffing, составила 19% от общего потока. Это доля запросов, распознанных как автоматическое использование украденных пар логин-пароль, а не доля успешных входов и не доля взломанных аккаунтов.

В этой выборке показатель достигал 25% у крупных компаний и 12% у малых. Максимум за день составил 44% всех попыток аутентификации. Это максимум по всей проанализированной выборке: из приведённых данных нельзя заключить, что он был зафиксирован именно в крупной компании.

Credential stuffing редко выглядит как эффектная атака. Чаще это массовая проверка украденных паролей на разных сервисах.

Показатели 19% и 44% описывают поток попыток, которые системы классифицировали как credential stuffing. Они не сообщают, сколько таких запросов закончилось успешным входом. Часть могла быть остановлена ограничением частоты запросов или другими защитными механизмами, часть могла не дойти до проверки учётных данных. Для оценки эффективности защиты нужно различать три вещи: число попыток, число успешных аутентификаций и число инцидентов, в которых учётная запись действительно оказалась скомпрометирована.

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

Как обходят второй фактор

В 4% утечек из выборки Verizon исследователи зафиксировали техники обхода второго фактора, включая атаки adversary-in-the-middle, SIM swap и кражу токенов сессии. Это доля инцидентов, где такая техника встретилась в цепочке атаки. Её нельзя трактовать как процент всех атак на MFA, которые завершились успехом.

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

Инфостилеры способны похищать сохранённые пароли и данные сессий с заражённого устройства. Однако наличие инфостилера не означает, что каждый украденный токен пригоден для использования: важны срок его действия, настройки сервиса и другие условия. Точно так же сам факт кражи пароля ещё не говорит, что злоумышленник сможет войти в конкретный аккаунт.

Фишинг-посредник

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

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

SIM swap

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

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

Эффективность методов двухфакторной аутентификации: исследование Google

В мае 2019 года исследователи Google, Нью-Йоркского университета и Калифорнийского университета в Сан-Диего опубликовали результаты сравнения методов подтверждения входа. Данные относятся к пользователям Google и условиям конкретного исследования. Их нельзя автоматически переносить на любую платформу и любую организацию.

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

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

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

Почему аппаратный ключ не равен SMS-коду

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

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

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

Инфостилеры, повторы паролей и корпоративные риски

Verizon проанализировал журналы 14 742 заражённых устройств. Медианная доля уникальных паролей, которые пользователь применял в разных сервисах, составила 49%. Иными словами, в этой выборке медианный показатель повторного использования паролей был заметным. Это не означает, что у каждого пользователя половина паролей повторялась, и не описывает всех сотрудников или все корпоративные среды.

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

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

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

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

Настройка MFA: решения зависят от сценария

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

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

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

Против credential stuffing полезны ограничения частоты запросов, анализ необычных попыток входа и дополнительные проверки при подозрительной активности. Одного rate-limiter может быть недостаточно: злоумышленники способны распределять запросы, а слишком жёсткие ограничения могут мешать легитимным пользователям. Настройку приходится согласовывать с мониторингом и процедурами разблокировки, иначе защита сама станет источником проблем.

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

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

Двухфакторная аутентификация снижает риск, но её эффективность зависит от метода и сценария атаки. Исследование Google показывает заметную разницу между SMS, push и аппаратными ключами при целевом фишинге. Данные Verizon, в свою очередь, описывают масштаб автоматизированных попыток, распространённость скомпрометированных учётных данных как первоначального вектора и отдельные техники обхода второго фактора. Эти показатели нельзя соединять в одну причинную цепочку: сами по себе они не доказывают, что повторные пароли, инфостилеры или отсутствие MFA объяснили конкретную долю утечек.

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