На одном из недавних пентестов - организация с Okta, включённый passwordless через FIDO2, всё по best practices - я получил session token администратора за сорок минут после старта фишинговой фазы. Passkeys не помогли. Аутентификация прошла штатно на стороне пользователя, а дальше вся «phishing-resistant» история закончилась: сессионный cookie уехал на мой AitM-прокси. Вендоры рассказывают про «конец фишинга», а реальный attack surface корпоративного passwordless-деплоя говорит о другом. Разберём, что именно passkeys защищают, что - нет, и как это проверять в ходе engagement.
FIDO2 и WebAuthn: что нужно знать атакующему
FIDO2 - стандарт из двух протоколов: WebAuthn (W3C, JavaScript API[URL='https://developer.mozilla.org/en-US/docs/Web/API/CredentialsContainer']navigator.credentials[/URL] в браузере) и CTAP (Client to Authenticator Protocol - связь клиента с внешним аутентификатором по USB/NFC/BLE). При регистрации устройство генерирует пару ключей: приватный остаётся в TPM или Secure Enclave, публичный уходит на сервер. При аутентификации сервер присылает cryptographic challenge, устройство подписывает его приватным ключом после биометрической верификации или ввода PIN, сервер проверяет подпись публичным ключом. Shared secret не передаётся - вот ключевое отличие от паролей. Подробнее - в нашем подробном разборе атаки на аутентификацию.Для атакующего критичен один аспект: domain binding. WebAuthn credential привязан к конкретному origin (скажем,
login.microsoftonline.com). Пользователь попадает на login.micros0ftonline.com - аутентификатор не находит matching credential и молча отказывается подписывать challenge. Credential phishing в классическом виде - поддельная форма логина, куда жертва вводит пароль - против FIDO2 аутентификации без пароля действительно мёртв.Но attack surface passkeys не заканчивается на краже credential. Цепочка атаки продолжается после успешной аутентификации. И вот тут passkeys безопасность enterprise из абсолютной превращается в условную.
Attack surface passwordless-аутентификации: где рвётся цепочка
AitM: обход phishing-resistance через session hijacking
Adversary-in-the-Middle (T1557, Credential Access / Collection) - основной вектор, который реально работает против passkeys в корпоративной среде. Хакер не пытается украсть credential - он проксирует легитимную аутентификацию через свой сервер и перехватывает сессионный cookie после успешной авторизации.
Инструменты: evilginx2(GitHub - kgretzky/evilginx2: Standalone man-in-the-middle attack framework used for phishing login credentials along with session cookies, allowing for the bypass of 2-factor authentication) и Modlishka(GitHub - drk1wi/Modlishka: Modlishka. Reverse Proxy.) умеют проксировать HTTPS-трафик в реальном времени с подменой домена. Пользователь видит фишинговую страницу, инициирует вход, проходит FIDO2-аутентификацию на своём устройстве. Аутентификация идёт на легитимном сервере - через проксирующий слой. Сервер выдаёт session token, и этот token оседает на прокси атакующего.
Цепочка в терминах kill chain:
- Initial Access - фишинговое письмо со ссылкой на AitM-прокси
- Прокси отображает легитимную страницу IdP (Entra ID, Okta)
- Пользователь проходит passkey-аутентификацию штатно - domain binding не спасает, потому что прокси транслирует запрос на настоящий домен
- IdP выдаёт session cookie -> прокси перехватывает его - Steal Web Session Cookie (T1539, Credential Access)
- Атакующий импортирует cookie -> Web Session Cookie (T1550.004, Lateral Movement) -> доступ к ресурсам организации
Ограничения техники:
- Прокси должен корректно проксировать весь поток, включая WebSocket и JavaScript-вызовы WebAuthn API. Evilginx2 справляется с Entra ID, Okta, Google Workspace. Для кастомных реализаций WebAuthn может потребоваться написание собственного phishlet - и это отдельная головная боль.
- Token Protection в Entra ID (на момент написания - в preview) привязывает sign-in token к устройству через proof-of-possession, но в текущем preview покрывает только desktop-приложения (Teams, OneDrive) на Windows. Browser session cookies (
ESTSAUTH/ESTSAUTHPERSISTENT), которые крадёт evilginx2, пока не защищены. В моей выборке из шести деплоев эту защиту включили один раз. - Conditional Access с device compliance check отсекает сессии с нескомплаентных устройств. Но требует корректной настройки, и применяется не ко всем приложениям.
- Risk-based policies (Entra ID Identity Protection, Okta ThreatInsight) могут заблокировать вход с anomalous IP - но AitM с чистого VPS в той же географии часто проходит незамеченным.
Synced passkeys vs device-bound credentials: разница для атакующего
Реализации FIDO2 делятся на два класса, и для оценки passkeys attack surface эта разница принципиальна:- Device-bound passkeys - приватный ключ в TPM/Secure Enclave конкретного устройства. Не синхронизируется, не экспортируется. Аппаратный ключ безопасности (YubiKey), Windows Hello с TPM.
- Synced passkeys - приватный ключ синхронизируется через облако: iCloud Keychain, Google Password Manager, 1Password, Dashlane.
Компрометация iCloud-аккаунта или Google-аккаунта (social engineering, SIM swap, infostealer) даёт доступ ко всем синхронизированным passkeys пользователя - это Valid Accounts (T1078, Initial Access) через cloud credential. MDM-политики в enterprise часто конфликтуют с синхронизацией: если организация разрешает BYOD и сотрудник синхронизирует passkey на личное устройство - корпоративный credential выходит из-под контроля ИБ-службы.
По данным FIDO Alliance, NIST SP 800-63B-4 (initial public draft, Aug 2024) допускает syncable authenticators для уровня AAL2, но для AAL3 требуется hardware-based authenticator с verifier impersonation resistance; syncable passkeys квалифицируются только для AAL2. Документ в статусе draft, не финальная редакция. Для high-assurance сценариев (финансовые транзакции, привилегированный доступ) синхронизируемые ключи формально не подходят.
Device-bound passkeys - сложнее, но не неуязвимы:
Физический доступ к устройству + знание PIN/shoulder surfing = полный доступ к credential. На аппаратных токенах (YubiKey 5 с firmware до 5.7) хранится до 25 discoverable (resident) FIDO2 credentials, с firmware 5.7+ - до 100 discoverable passkeys; non-discoverable credentials лимита не имеют, генерируются на лету из device secret (по данным Yubico). Основной вектор для enterprise - social engineering helpdesk для перевыпуска credential на новое устройство.
Рекомендация при пентесте: первым делом определить тип passkeys. Synced - фокус на облачные аккаунты и BYOD-политику. Device-bound - фокус на fallback-механизмы и процедуры helpdesk.
Fallback-механизмы: пароль, который никуда не делся
Слабое звено любого корпоративного passwordless-деплоя - резервные методы аутентификации. Kaspersky в анализе enterprise-готовности passkeys отмечает: «большинство сервисов при подключении passkeys не отключают пароль автоматически».На практике это выглядит так:
- Microsoft Entra ID позволяет настроить passkeys как primary method, но TAP (Temporary Access Pass) остаётся для аварийного доступа и onboarding. Для гибридных сред с on-premises AD, по данным InfoSecPortal, «нативной поддержки входа через RDP и VDI у Microsoft пока нет» - часть инфраструктуры сидит на паролях.
- Okta поддерживает passwordless policy, но fallback на SMS OTP или email magic link часто оставляют для legacy-интеграций.
- Google Workspace позволяет enforcement FIDO2, но администраторы оставляют backup codes.
- Credential phishing на пароль (если не отключён) - passkey не поможет, когда рядом живёт пароль
Company2024!. - SMS OTP interception / SIM swap -> Multi-Factor Authentication Interception (T1111, Credential Access).
- Social engineering helpdesk: «потерял YubiKey, нужен временный доступ» -> генерация TAP -> Valid Accounts (T1078).
Тестирование FIDO2-деплоя на пентесте: от recon до session capture
Требования к окружению
- ОС: Kali Linux 2024.x или Parrot OS
- RAM: минимум 4 ГБ для AitM-прокси, 8 ГБ при параллельной работе с Burp Suite
- Сеть: для внешнего пентеста - VPS с внешним IP и валидным SSL-сертификатом (Let's Encrypt). Для внутреннего - контроль DNS или возможность ARP/LLMNR spoofing
- Инструменты: evilginx2 (активный проект, GitHub, последний коммит - 2024), Burp Suite Pro, browser DevTools. Для анализа CTAP2-трафика - Burp с расширением для WebAuthn (или ручной разбор через DevTools)
Recon: fingerprinting аутентификации
Что детектит SOC: аномальный IP при аутентификации (sign-in log), несовпадение device fingerprint, impossible travel. Entra ID Identity Protection помечает такие сессии как risky - но только если risk-based policies включены и порог не завышен.
Что может помешать атакующему:
| Защитная мера | Блокирует AitM? | Статус внедрения |
|---|---|---|
| Token Protection (Entra ID) | Частично - только sign-in tokens desktop-приложений на Windows; browser cookies не покрыты | Preview, единичные деплои |
| DPoP (RFC 9449) | Частично - proof-of-possession для OAuth access/refresh tokens, но не для браузерных session cookies IdP | RFC опубликован (Sept 2023), вендорское внедрение ограничено |
| CAP с device compliance | Частично - зависит от scope политики | Распространено, но не universal |
| Risk-based Conditional Access | Частично - anomaly detection | Распространено |
| Аппаратный token binding (FIDO2 Level 3) | Не напрямую - защищает credential, не session | Нишевое |
FIDO2 уязвимости и атаки: trade-off таблица для пентестера
| Вектор | Работает против passkeys? | Предусловия | Контрмера | Контекст |
|---|---|---|---|---|
| Credential phishing (поддельная форма) | Нет - domain binding | - | - | Закрыт FIDO2 by design |
| AitM session hijacking | Да | Прокси с валидным SSL, доставка ссылки | Token Protection, DPOP | Внешний и внутренний пентест |
| Infostealer (cookie theft с endpoint) | Да | Компрометация endpoint, Browser Session Hijacking (T1185) | EDR, browser isolation | Post-exploitation |
| Атака на synced passkeys | Да | Компрометация cloud-аккаунта (iCloud/Google) | MFA на cloud account, MDM enforcement | BYOD-среды |
| Fallback password attack | Да, если пароль не отключён | Наличие fallback-метода | Полный отказ от паролей | Гибридные деплои |
| Helpdesk social engineering | Да | Слабый identity verification в helpdesk | Строгая процедура re-enrollment | Любой enterprise |
| Physical access + PIN/bio | Да, при физическом доступе | Доступ к устройству + PIN/shoulder surfing | Device encryption, strong PIN policy | Физический доступ |
Чеклист: аудит беспарольной аутентификации на пентесте
- Определить IdP и наличие WebAuthn - redirect URL при логине, DevTools Network tab, поиск
publicKeyCredentialRequestOptions. - Определить тип passkeys - synced (iCloud/Google Password Manager) или device-bound (YubiKey, Windows Hello TPM). Attestation policy подскажет.
- Проверить fallback-механизмы - попытка логина без FIDO2-устройства. Пароль? SMS? Email? TAP?
- Проверить Conditional Access - вход с несоответствующего устройства, из другой геолокации, с неизвестного browser fingerprint.
- Проверить Token Protection / DPOP - украденный session cookie работает на другом устройстве или нет?
- Развернуть AitM-прокси - evilginx2 с phishlet для целевого IdP. Проверить перехват session token.
- Проверить процедуру recovery - что происходит при «потере устройства»? Какой identity verification в helpdesk? Достаточно звонка?
- Оценить BYOD-политику - могут ли сотрудники синхронизировать passkeys на личные устройства вне MDM?
- Проверить legacy-периметр - приложения без SSO, on-premises AD без FIDO2-поддержки, RDP-доступ к серверам.
- Задокументировать gap между маркетинговыми заявлениями и реальной конфигурацией - это ценнейшая часть отчёта для заказчика.
За полтора года я тестировал шесть корпоративных деплоев FIDO2 - Entra ID, Okta, один кастомный на базе WebAuthn-библиотеки. В пяти из шести перехват сессии через AitM работал без модификации стандартного evilginx2 phishlet. В одном - Token Protection в preview-режиме заблокировала импорт cookie на мою машину. Один из шести. Вот текущий уровень готовности enterprise к пост-аутентификационным атакам.
Индустрия сфокусировалась на «phishing-resistant credentials» и упустила «phishing-resistant sessions». Token Protection, DPOP, device-bound session tokens - всё это существует, но в preview или в стадии RFC. Пока session token остаётся bearer token без привязки к устройству, passkeys закрывают половину проблемы и создают ложное чувство безопасности у тех, кто не заглядывает дальше вендорских whitepaper. Через год-два, когда Token Protection станет GA в Entra ID и конкуренты подтянутся, ситуация изменится. Сейчас - нет. Если хочешь руками почувствовать, где заканчивается phishing-resistance и начинается session hijacking - web-задачи на HackerLab.pro(https://hackerlab.pro) заточены под сценарии с похожей механикой.
Последнее редактирование модератором:
