Исследователи Palo Alto Networks Unit 42 опубликовали исследование трёх постэксплуатационных техник, позволяющих вредоносному ПО, работающему с правами обычного пользователя на Windows-системе с TPM, выполнять аутентификацию в учётных записях жертвы, защищённых passkey, — без биометрии, PIN-кода и каких-либо уведомлений на экране. Атаки направлены против Google Password Manager в браузере Chrome и не ломают криптографию WebAuthn, а эксплуатируют особенности хранения ключей, логики повторной регистрации устройства и проверки флага верификации пользователя на стороне веб-сервисов. Случаев эксплуатации в реальных атаках не зафиксировано, CVE-идентификаторы не присвоены, а полный статус исправлений остаётся неизвестным.
Архитектурные предпосылки атак
Все три метода — Pass-ta-key, Silver Pass-ta-key и Golden Pass-ta-key — требуют предварительного запуска вредоносного кода на устройстве жертвы. Это постэксплуатационные техники: они описывают, что атакующий может сделать на уже скомпрометированной машине, а не способ первоначального проникновения.
По данным исследователей, Chrome хранит синхронизированные учётные данные в каталоге %LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB, и непривилегированный процесс способен прочитать метаданные, включая идентификаторы сервисов (relying party), имена пользователей, идентификаторы учётных данных и зашифрованный материал закрытых ключей.
Ключевая архитектурная особенность подтверждается исходным кодом Chromium: Chrome создаёт TPM-ключ без имени (что, согласно комментарию в коде, предотвращает его сохранение на диск), экспортирует его как непрозрачный блоб и затем загружает повторно. При подписании используется флаг NCryptSignHash, подавляющий любые пользовательские запросы. В том же файле присутствует TODO-комментарий со ссылкой на задачу Chromium 398125799, предлагающую маркировать такие ключи.
Три вектора атаки
Pass-ta-key: обход без верификации пользователя
Первый метод извлекает обёрнутый ключ идентификации устройства Chrome и через Windows CNG API запрашивает у того же TPM подпись для контролируемого атакующим запроса. Облачный аутентификатор Google возвращает валидное утверждение (assertion), отличающееся от легитимного лишь одним битом — флагом User Verified (UV), который остаётся неустановленным.
Согласно спецификации Web Authentication Level 3, если сервис устанавливает параметр userVerification в значение «required», он обязан отклонить аутентификацию при отсутствии UV-бита. По данным Unit 42, GitHub корректно выполнял эту проверку, тогда как eBay принимал такие утверждения до тех пор, пока не устранил проблему после раскрытия информации.
Silver Pass-ta-key: подмена ключа верификации
Второй метод нацелен на процесс повторной регистрации устройства. Вредоносное ПО принудительно инициирует перерегистрацию Chrome, и в возникающем временном окне — когда браузер ещё не создал ключ верификации пользователя — атакующий регистрирует собственный ключ. Исходный код Chromium подтверждает существование состояния deferred_uv_key_creation для вновь зарегистрированных устройств.
По утверждению исследователей, серверная сторона не проверяет, получен ли вновь зарегистрированный ключ от аппаратного модуля безопасности. Утверждения, подписанные подставным ключом, несут установленный UV-флаг, что, как сообщается, позволяет выполнять аутентификацию с устройства атакующего без доступа к машине жертвы. Однако публичный код Chromium не позволяет независимо верифицировать серверную часть этой атаки для текущей стабильной версии Chrome.
Golden Pass-ta-key: извлечение мастер-секрета
Наиболее серьёзный третий метод направлен на 32-байтовый Security Domain Secret (SDS) — мастер-ключ, используемый для расшифровки синхронизированных закрытых ключей passkey. По данным Unit 42, вредоносное ПО инициирует перерегистрацию и считывает секрет из памяти процесса Chrome в момент, когда он кратковременно находится там в открытом виде.
Исходный код Chromium подтверждает, что Chrome создаёт или получает 32-байтовые секреты домена безопасности в структурах данных клиентского процесса. Тем не менее надёжность извлечения, возможность захвата учётной записи и сохранение доступа при смене эпох секрета остаются неподтверждёнными независимыми источниками.
Исследователи сообщают, что Google удалил ранее существовавшую утечку SDS через FIDO-логи Chrome, однако секрет по-прежнему попадает в память клиента, что не закрывает описанный вектор.
Неопределённость со статусом исправлений
Раскрытие не устанавливает, закрыты ли все три вектора атаки. Исследование не содержит CVE-идентификаторов, списка затронутых версий Chrome и полного статуса исправлений. Публичная документация Google позволяет пользователям сменить PIN-код Google Password Manager или удалить все данные менеджера паролей, но не описывает механизм ротации или отзыва SDS. Остаётся открытым критический вопрос: аннулирует ли смена PIN-кода или удаление данных секрет, уже извлечённый атакующим.
Оценка воздействия
Область воздействия ограничена пользователями Chrome на Windows с TPM, использующими Google Password Manager для синхронизации passkey. Два из трёх методов (Silver и Golden Pass-ta-key), по данным исследователей, обеспечивают повторный доступ из среды атакующего после первоначальной компрометации — это превращает разовый инцидент в устойчивый канал доступа к учётным записям жертвы.
Важно учитывать контекст: все техники требуют предварительного выполнения кода на устройстве. Это не удалённая атака на passkey как технологию, а расширение возможностей злоумышленника, уже закрепившегося в системе. Тем не менее для организаций, рассматривающих passkey как замену паролям с повышенной устойчивостью к компрометации, эти находки демонстрируют, что постэксплуатационный ландшафт сложнее, чем предполагалось.
Рекомендации
Для операторов веб-сервисов (relying party):
- Установить параметр userVerification в значение required и проверять наличие UV-бита в возвращаемом утверждении — это единственная мера, полностью контролируемая на стороне сервиса и блокирующая первый вектор атаки.
- Не полагаться исключительно на настройку запроса — валидировать фактический ответ аутентификатора.
Для поставщиков учётных данных (credential providers):
- Проверять аппаратную аттестацию при регистрации новых ключей верификации.
- Усилить проверки при повторной регистрации и восстановлении устройств.
- Ограничить доступ к локальному состоянию passkey и исключить попадание мастер-секретов в логи и доступную память.
Для конечных пользователей:
- Обеспечить защиту конечных точек от вредоносного ПО — это обязательное условие для всех трёх атак.
- При подозрении на компрометацию устройства — сменить PIN-код Google Password Manager и рассмотреть удаление данных менеджера паролей, хотя эффективность этих мер в отношении уже извлечённого SDS не подтверждена документацией Google.
Исследование Unit 42 выявляет системную проблему: безопасность passkey зависит не только от криптографии, но и от всей цепочки — от хранения ключей на устройстве до серверной валидации. Пока Google не опубликует официальный ответ с подтверждением статуса исправлений и механизма ротации SDS, организациям следует как минимум убедиться, что их веб-сервисы строго проверяют UV-флаг, а пользователям — поддерживать актуальную версию Chrome и контролировать защиту конечных точек.
