Развертывание синхронизируемых ключей доступа (passkeys) в корпоративной среде небезопасно. Основной риск заключается в том, что такие ключи наследуют уязвимости облачных учетных записей, используемых для их синхронизации, включая процессы восстановления доступа. Организации FIDO Alliance и Yubico выпустили официальные рекомендации для предприятий, советуя отдавать предпочтение привязанным к устройству ключам доступа в случаях, требующих высокого уровня надежности. Синхронизация через сервисы, такие как Apple iCloud и Google Cloud, смещает границу доверия с физического устройства на облачный аккаунт, создавая новые векторы атак.
Существует три основные поверхности атаки, связанные с синхронизируемыми ключами. Во-первых, это захват облачной учетной записи, позволяющий злоумышленнику авторизовать новые устройства и получить доступ к ключам. Во-вторых, размывание границ между корпоративными и личными аккаунтами: сотрудник, вошедший в личный Apple iCloud на рабочем устройстве, может синхронизировать корпоративные ключи в свое неуправляемое облако. В-третьих, злоумышленники могут злоупотреблять процессами восстановления доступа через службы поддержки, чтобы скопировать связку ключей на новое, недоверенное устройство.
Один из практических векторов атаки — это принудительное понижение уровня аутентификации. Исследователи из Proofpoint продемонстрировали, как фишинговый прокси-сервер, использующий технику Adversary-in-the-Middle (AitM), может обмануть систему идентификации. В качестве цели была выбрана платформа Microsoft Entra ID. Атакующий имитировал подключение через неподдерживаемый браузер, например Safari на Windows. В ответ система Entra ID отключала аутентификацию по ключу доступа из-за предполагаемой несовместимости.
В результате такого обмана пользователю предлагались более слабые методы входа, такие как SMS или одноразовые пароли (OTP). Злоумышленник перехватывал эти данные вместе с сессионным cookie, получая полный доступ к учетной записи. Эта атака не взламывает протокол WebAuthn, а обходит его, эксплуатируя непоследовательную поддержку стандарта в разных браузерах и операционных системах, а также готовность провайдеров идентификации (IdP) разрешать слабые методы ради удобства пользователей. Атака злоупотребляет функцией немедленного посредничества (Immediate mediation) в WebAuthn, которая позволяет сайтам предлагать альтернативные способы входа.
Другой вектор атак связан с уязвимостями в браузерах. Исследователи из SquareX установили, что скомпрометированная среда браузера, например через вредоносное расширение или XSS-уязвимость, может перехватывать вызовы WebAuthn. В браузере Chrome для этого используется API расширений под названием
Независимое исследование, представленное на конференции DEF CON, продемонстрировало атаку типа DOM-based clickjacking. Она нацелена на элементы интерфейса, внедряемые расширениями менеджеров паролей. Всего один клик пользователя на вредоносной странице может спровоцировать автозаполнение и утечку сохраненных данных: логинов, данных кредитных карт и одноразовых кодов. Исследователь сообщил, что в некоторых сценариях таким же образом можно было эксплуатировать и аутентификацию с помощью ключей доступа у нескольких вендоров.
Решением для корпоративной среды являются привязанные к устройству ключи доступа. В этом случае приватные ключи генерируются и используются внутри защищенных аппаратных компонентов, откуда их невозможно экспортировать. Такой подход обеспечивает предсказуемые сигналы с устройства, позволяет проводить аттестацию (проверку подлинности) и предоставляет управляемый жизненный цикл ключа, который можно инвентаризировать и отозвать.
Для построения надежной системы защиты необходимо внедрить строгую политику аутентификации. Предприятия должны требовать устойчивую к фишингу аутентификацию для всех пользователей, особенно с привилегированными ролями. Следует принимать только привязанные к устройству аутентификаторы с неэкспортируемыми ключами, хранящимися в защищенном оборудовании. При этом необходимо полностью исключить все более слабые резервные методы: SMS, голосовые вызовы, приложения с TOTP-кодами, ссылки по электронной почте и push-уведомления.
Безопасность браузера и контроль над расширениями играют ключевую роль. Необходимо внедрять белые списки разрешенных расширений в управляемых браузерах. Следует блокировать расширения, запрашивающие разрешения
Процессы регистрации и восстановления доступа должны быть перестроены. Основой для восстановления учетной записи должны служить высоконадежные, привязанные к устройству аутентификаторы, что исключает векторы атак с использованием социальной инженерии на службы поддержки. При регистрации новых учетных данных система должна разрешать только привязанные к устройству ключи и собирать метаданные (аттестацию), такие как модель устройства и уровень его защиты, для верификации.
Эффективная защита требует непрерывного контроля за сессией. Сессионные cookie должны быть привязаны к контексту доверенного устройства, чтобы сделать их непереносимыми. Система должна требовать повторную аутентификацию, если состояние безопасности устройства, его местоположение или другие параметры меняются. Попытки аутентификации с использованием слабых факторов должны блокироваться по умолчанию. Идеальная архитектура безопасности, используемая такими организациями, как Snowflake и Корнеллский университет (Cornell University), основывается на трех принципах: привязанные к устройству учетные данные, непрерывное доверие в течение всей сессии и универсальное обеспечение гигиены конечных точек в реальном времени. Эти принципы были озвучены на вебинаре «Как злоумышленники обходят FIDO: почему синхронизируемые ключи доступа не работают и что с этим делать», организованном компанией Beyond Identity.
Существует три основные поверхности атаки, связанные с синхронизируемыми ключами. Во-первых, это захват облачной учетной записи, позволяющий злоумышленнику авторизовать новые устройства и получить доступ к ключам. Во-вторых, размывание границ между корпоративными и личными аккаунтами: сотрудник, вошедший в личный Apple iCloud на рабочем устройстве, может синхронизировать корпоративные ключи в свое неуправляемое облако. В-третьих, злоумышленники могут злоупотреблять процессами восстановления доступа через службы поддержки, чтобы скопировать связку ключей на новое, недоверенное устройство.
Один из практических векторов атаки — это принудительное понижение уровня аутентификации. Исследователи из Proofpoint продемонстрировали, как фишинговый прокси-сервер, использующий технику Adversary-in-the-Middle (AitM), может обмануть систему идентификации. В качестве цели была выбрана платформа Microsoft Entra ID. Атакующий имитировал подключение через неподдерживаемый браузер, например Safari на Windows. В ответ система Entra ID отключала аутентификацию по ключу доступа из-за предполагаемой несовместимости.
В результате такого обмана пользователю предлагались более слабые методы входа, такие как SMS или одноразовые пароли (OTP). Злоумышленник перехватывал эти данные вместе с сессионным cookie, получая полный доступ к учетной записи. Эта атака не взламывает протокол WebAuthn, а обходит его, эксплуатируя непоследовательную поддержку стандарта в разных браузерах и операционных системах, а также готовность провайдеров идентификации (IdP) разрешать слабые методы ради удобства пользователей. Атака злоупотребляет функцией немедленного посредничества (Immediate mediation) в WebAuthn, которая позволяет сайтам предлагать альтернативные способы входа.
Другой вектор атак связан с уязвимостями в браузерах. Исследователи из SquareX установили, что скомпрометированная среда браузера, например через вредоносное расширение или XSS-уязвимость, может перехватывать вызовы WebAuthn. В браузере Chrome для этого используется API расширений под названием
webAuthenticationProxy, который может перехватывать методы navigator.credentials.create() и navigator.credentials.get(). Изначально этот API был предназначен для легитимных сценариев удаленного рабочего стола. Независимое исследование, представленное на конференции DEF CON, продемонстрировало атаку типа DOM-based clickjacking. Она нацелена на элементы интерфейса, внедряемые расширениями менеджеров паролей. Всего один клик пользователя на вредоносной странице может спровоцировать автозаполнение и утечку сохраненных данных: логинов, данных кредитных карт и одноразовых кодов. Исследователь сообщил, что в некоторых сценариях таким же образом можно было эксплуатировать и аутентификацию с помощью ключей доступа у нескольких вендоров.
Решением для корпоративной среды являются привязанные к устройству ключи доступа. В этом случае приватные ключи генерируются и используются внутри защищенных аппаратных компонентов, откуда их невозможно экспортировать. Такой подход обеспечивает предсказуемые сигналы с устройства, позволяет проводить аттестацию (проверку подлинности) и предоставляет управляемый жизненный цикл ключа, который можно инвентаризировать и отозвать.
Для построения надежной системы защиты необходимо внедрить строгую политику аутентификации. Предприятия должны требовать устойчивую к фишингу аутентификацию для всех пользователей, особенно с привилегированными ролями. Следует принимать только привязанные к устройству аутентификаторы с неэкспортируемыми ключами, хранящимися в защищенном оборудовании. При этом необходимо полностью исключить все более слабые резервные методы: SMS, голосовые вызовы, приложения с TOTP-кодами, ссылки по электронной почте и push-уведомления.
Безопасность браузера и контроль над расширениями играют ключевую роль. Необходимо внедрять белые списки разрешенных расширений в управляемых браузерах. Следует блокировать расширения, запрашивающие разрешения
webAuthenticationProxy, activeTab или широкие права на выполнение скриптов на странице. Также требуется постоянный мониторинг установки и использования расширений для выявления подозрительной активности. Процессы регистрации и восстановления доступа должны быть перестроены. Основой для восстановления учетной записи должны служить высоконадежные, привязанные к устройству аутентификаторы, что исключает векторы атак с использованием социальной инженерии на службы поддержки. При регистрации новых учетных данных система должна разрешать только привязанные к устройству ключи и собирать метаданные (аттестацию), такие как модель устройства и уровень его защиты, для верификации.
Эффективная защита требует непрерывного контроля за сессией. Сессионные cookie должны быть привязаны к контексту доверенного устройства, чтобы сделать их непереносимыми. Система должна требовать повторную аутентификацию, если состояние безопасности устройства, его местоположение или другие параметры меняются. Попытки аутентификации с использованием слабых факторов должны блокироваться по умолчанию. Идеальная архитектура безопасности, используемая такими организациями, как Snowflake и Корнеллский университет (Cornell University), основывается на трех принципах: привязанные к устройству учетные данные, непрерывное доверие в течение всей сессии и универсальное обеспечение гигиены конечных точек в реальном времени. Эти принципы были озвучены на вебинаре «Как злоумышленники обходят FIDO: почему синхронизируемые ключи доступа не работают и что с этим делать», организованном компанией Beyond Identity.
