Исследовательская группа Unit 42 компании Palo Alto Networks описала три способа атаки на облачный аутентификатор Google Password Manager в Google Chrome: Pass-ta-key, Silver Pass-ta-key и Golden Pass-ta-key. Вредоносная программа с правами обычного пользователя Windows потенциально может войти в защищённые ключом доступа аккаунты без отпечатка пальца, PIN-кода и видимого запроса на экране. Криптография ключей доступа при этом не взламывается. Атакуются окружающие механизмы: хранение идентификационных ключей устройства, повторная регистрация после исчезновения локального состояния, добавление ключей проверки пользователя, секреты в памяти Chrome и контроль аутентификации со стороны сайтов. Исследование касается только Chrome и Google Password Manager на компьютерах Windows с Trusted Platform Module (TPM). Во всех сценариях вредоносный код уже работает на машине жертвы, поэтому речь идёт о действиях после компрометации, а не о способе первоначального заражения.
До атаки программа может изучить локально синхронизированные данные Chrome по адресу %LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB. По сведениям Unit 42, непривилегированному процессу доступны метаданные, по которым определяются связанные с ключами доступа сайты и сервисы, имена пользователей, идентификаторы учётных данных и зашифрованный материал закрытых ключей. Сайт или сервис, принимающий такую аутентификацию, в терминологии Web Authentication называется relying party, то есть доверяющей стороной.
Pass-ta-key извлекает экспортированный контейнер с идентификационным ключом устройства Chrome, после чего заставляет TPM компьютера жертвы подписать подготовленный злоумышленником запрос. Обращение к модулю выполняется через Windows Cryptography API: Next Generation (CNG). В исходном коде Chromium видно, что Chrome создаёт TPM-ключ без имени; комментарий разработчиков поясняет, что так ключ нельзя напрямую сохранить на диск. Вместо этого он экспортируется как непрозрачный блок данных, а затем загружается с флагом, подавляющим пользовательские запросы. В том же файле оставлена пометка TODO со ссылкой на задачу Chromium 398125799, где предложено присваивать таким ключам метки. Эта схема позволяет повторно использовать контейнер без окна подтверждения.
Google Cloud Authenticator в сценарии Pass-ta-key возвращает действительное утверждение аутентификации, но бит User Verified (UV) остаётся сброшенным. Спецификация Web Authentication требует, чтобы доверяющая сторона при параметре userVerification = required отклоняла результат без UV. Одной передачи параметра недостаточно: сайт обязан проверить бит в полученном ответе. Unit 42 сообщила, что eBay уже начал валидировать UV. Из трёх сценариев именно Pass-ta-key сильнее всего зависит от корректности проверки на стороне конкретного сайта: при строгой обработке UV такой вход блокируется.
Silver Pass-ta-key использует повторную регистрацию устройства. Атакующий добивается перерегистрации Chrome и действует в промежутке, когда браузер ещё не создал собственный ключ проверки пользователя. В этот момент регистрируется ключ, контролируемый злоумышленником. По версии Unit 42, сервис не удостоверяется, что новый ключ появился внутри защищённого оборудования, поэтому может принять подмену. Подписи такого ключа уже содержат установленный UV-бит. Если сценарий срабатывает, дальнейшие входы возможны из среды атакующего, без компьютера жертвы.
Исходный код Chromium подтверждает существование состояния deferred_uv_key_creation, в котором новое устройство ожидает отложенного создания ключа проверки пользователя. Но открытый код не доказывает, что серверная подмена работает в актуальной стабильной версии Chrome и на действующей инфраструктуре Google. Также неизвестно, проверяет ли производственный сервис аппаратную аттестацию при приёме нового или заменяющего UV-ключа. Unit 42 предлагает требовать такую аттестацию, принимать ключи лишь от одобренного защищённого оборудования и ужесточить повторную регистрацию устройств вместе с восстановлением аккаунта.
Golden Pass-ta-key нацелена на Security Domain Secret (SDS) — 32-байтный секрет, которым расшифровываются закрытые ключи синхронизированных ключей доступа. После запуска повторной регистрации устройства вредоносная программа ждёт появления SDS в памяти процесса Chrome, считывает его в короткий промежуток существования в открытом виде и использует для восстановления закрытых ключей. Из трёх техник эта затрагивает наиболее чувствительный элемент: фактически мастер-секрет синхронизированного хранилища. Silver Pass-ta-key и Golden Pass-ta-key, по оценке исследователей, способны оставить злоумышленнику повторно используемый доступ уже из собственной среды после завершения компрометации исходного компьютера.
Код Chromium подтверждает, что Chrome создаёт либо получает 32-байтные секреты домена безопасности и держит их в структурах данных клиентского процесса. Значит, SDS действительно попадает в память браузера. При этом публично не установлено, насколько надёжно его удаётся извлекать, всегда ли это приводит к полному захвату аккаунта и сохранится ли доступ после перехода на следующую «эпоху» секрета. Unit 42 также сообщила, что Google убрала прежнюю утечку SDS через FIDO logs. Удаление секрета из журналов закрывает тот конкретный канал, но SDS по-прежнему поступает клиенту Chrome и некоторое время находится в памяти.
По состоянию на 3 августа 2026 года публикация не содержит номеров CVE, списка затронутых версий Chrome и полного статуса исправлений; случаев эксплуатации в реальных атаках тоже не описано. Поиск в National Vulnerability Database (NVD) на эту дату не обнаружил CVE, соответствующих Pass-ta-key, Silver Pass-ta-key или Golden Pass-ta-key. Анализ исходного кода Chromium, доступного к 3 августа 2026 года, подтверждает части архитектуры, но не доказывает работоспособность всех трёх техник против последней стабильной версии и производственных сервисов. В общедоступных материалах Chrome не найдено уведомление об удалении SDS из FIDO-журналов, а на страницах поддержки и пресс-ресурсах eBay нет сообщения о начале проверки UV.
Пользователь может изменить PIN-код Google Password Manager или удалить все данные менеджера паролей, однако документация Google не описывает отдельную ротацию либо отзыв SDS. Неясно, аннулирует ли смена PIN уже украденный секрет, лишает ли атакующего доступа удаление данных и продолжает ли извлечённый SDS работать после ротации или в следующих эпохах секрета. Нет и пользовательского средства, способного показать факт утечки SDS. Поэтому доступные действия восстановления нельзя считать подтверждённым способом отзыва мастер-секрета, пока Google не разъяснит их фактическое действие.
Сайтам следует запрашивать userVerification = required, проверять UV-бит в возвращённом утверждении и отклонять ответ при его отсутствии. Разработчикам браузеров и хранилищ нужны аппаратная аттестация новых UV-ключей, проверка заменяющих ключей, более строгая перерегистрация устройств и ограничение доступа к локальным метаданным ключей доступа. Мастер-секреты не должны попадать в клиентские журналы, а время их нахождения в памяти в открытом виде следует свести к минимуму. Для SDS необходимы понятные механизмы ротации и отзыва, а также прямое объяснение, отменяют ли похищенный секрет смена PIN и удаление данных Google Password Manager.
The Hacker News направило Google вопрос о том, сохраняет ли украденный Security Domain Secret силу после смены PIN-кода Google Password Manager, а Palo Alto Networks попросило уточнить детали исследования Unit 42. Издание обещало обновить материал после ответа любой из организаций. Пока подтверждена лишь основа некоторых механизмов, а текущая эксплуатируемость, серверные исправления и судьба похищенного SDS остаются неизвестными. Эти сценарии не означают удалённого взлома ключей доступа: сначала атакующему требуется запустить вредоносную программу на Windows-компьютере жертвы. Но после такого проникновения защита может зависеть уже не от стойкости криптографии, а от хранения данных на конечном устройстве, правил повторной регистрации и одного проверенного либо пропущенного UV-бита.
До атаки программа может изучить локально синхронизированные данные Chrome по адресу %LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB. По сведениям Unit 42, непривилегированному процессу доступны метаданные, по которым определяются связанные с ключами доступа сайты и сервисы, имена пользователей, идентификаторы учётных данных и зашифрованный материал закрытых ключей. Сайт или сервис, принимающий такую аутентификацию, в терминологии Web Authentication называется relying party, то есть доверяющей стороной.
Pass-ta-key извлекает экспортированный контейнер с идентификационным ключом устройства Chrome, после чего заставляет TPM компьютера жертвы подписать подготовленный злоумышленником запрос. Обращение к модулю выполняется через Windows Cryptography API: Next Generation (CNG). В исходном коде Chromium видно, что Chrome создаёт TPM-ключ без имени; комментарий разработчиков поясняет, что так ключ нельзя напрямую сохранить на диск. Вместо этого он экспортируется как непрозрачный блок данных, а затем загружается с флагом, подавляющим пользовательские запросы. В том же файле оставлена пометка TODO со ссылкой на задачу Chromium 398125799, где предложено присваивать таким ключам метки. Эта схема позволяет повторно использовать контейнер без окна подтверждения.
Google Cloud Authenticator в сценарии Pass-ta-key возвращает действительное утверждение аутентификации, но бит User Verified (UV) остаётся сброшенным. Спецификация Web Authentication требует, чтобы доверяющая сторона при параметре userVerification = required отклоняла результат без UV. Одной передачи параметра недостаточно: сайт обязан проверить бит в полученном ответе. Unit 42 сообщила, что eBay уже начал валидировать UV. Из трёх сценариев именно Pass-ta-key сильнее всего зависит от корректности проверки на стороне конкретного сайта: при строгой обработке UV такой вход блокируется.
Silver Pass-ta-key использует повторную регистрацию устройства. Атакующий добивается перерегистрации Chrome и действует в промежутке, когда браузер ещё не создал собственный ключ проверки пользователя. В этот момент регистрируется ключ, контролируемый злоумышленником. По версии Unit 42, сервис не удостоверяется, что новый ключ появился внутри защищённого оборудования, поэтому может принять подмену. Подписи такого ключа уже содержат установленный UV-бит. Если сценарий срабатывает, дальнейшие входы возможны из среды атакующего, без компьютера жертвы.
Исходный код Chromium подтверждает существование состояния deferred_uv_key_creation, в котором новое устройство ожидает отложенного создания ключа проверки пользователя. Но открытый код не доказывает, что серверная подмена работает в актуальной стабильной версии Chrome и на действующей инфраструктуре Google. Также неизвестно, проверяет ли производственный сервис аппаратную аттестацию при приёме нового или заменяющего UV-ключа. Unit 42 предлагает требовать такую аттестацию, принимать ключи лишь от одобренного защищённого оборудования и ужесточить повторную регистрацию устройств вместе с восстановлением аккаунта.
Golden Pass-ta-key нацелена на Security Domain Secret (SDS) — 32-байтный секрет, которым расшифровываются закрытые ключи синхронизированных ключей доступа. После запуска повторной регистрации устройства вредоносная программа ждёт появления SDS в памяти процесса Chrome, считывает его в короткий промежуток существования в открытом виде и использует для восстановления закрытых ключей. Из трёх техник эта затрагивает наиболее чувствительный элемент: фактически мастер-секрет синхронизированного хранилища. Silver Pass-ta-key и Golden Pass-ta-key, по оценке исследователей, способны оставить злоумышленнику повторно используемый доступ уже из собственной среды после завершения компрометации исходного компьютера.
Код Chromium подтверждает, что Chrome создаёт либо получает 32-байтные секреты домена безопасности и держит их в структурах данных клиентского процесса. Значит, SDS действительно попадает в память браузера. При этом публично не установлено, насколько надёжно его удаётся извлекать, всегда ли это приводит к полному захвату аккаунта и сохранится ли доступ после перехода на следующую «эпоху» секрета. Unit 42 также сообщила, что Google убрала прежнюю утечку SDS через FIDO logs. Удаление секрета из журналов закрывает тот конкретный канал, но SDS по-прежнему поступает клиенту Chrome и некоторое время находится в памяти.
По состоянию на 3 августа 2026 года публикация не содержит номеров CVE, списка затронутых версий Chrome и полного статуса исправлений; случаев эксплуатации в реальных атаках тоже не описано. Поиск в National Vulnerability Database (NVD) на эту дату не обнаружил CVE, соответствующих Pass-ta-key, Silver Pass-ta-key или Golden Pass-ta-key. Анализ исходного кода Chromium, доступного к 3 августа 2026 года, подтверждает части архитектуры, но не доказывает работоспособность всех трёх техник против последней стабильной версии и производственных сервисов. В общедоступных материалах Chrome не найдено уведомление об удалении SDS из FIDO-журналов, а на страницах поддержки и пресс-ресурсах eBay нет сообщения о начале проверки UV.
Пользователь может изменить PIN-код Google Password Manager или удалить все данные менеджера паролей, однако документация Google не описывает отдельную ротацию либо отзыв SDS. Неясно, аннулирует ли смена PIN уже украденный секрет, лишает ли атакующего доступа удаление данных и продолжает ли извлечённый SDS работать после ротации или в следующих эпохах секрета. Нет и пользовательского средства, способного показать факт утечки SDS. Поэтому доступные действия восстановления нельзя считать подтверждённым способом отзыва мастер-секрета, пока Google не разъяснит их фактическое действие.
Сайтам следует запрашивать userVerification = required, проверять UV-бит в возвращённом утверждении и отклонять ответ при его отсутствии. Разработчикам браузеров и хранилищ нужны аппаратная аттестация новых UV-ключей, проверка заменяющих ключей, более строгая перерегистрация устройств и ограничение доступа к локальным метаданным ключей доступа. Мастер-секреты не должны попадать в клиентские журналы, а время их нахождения в памяти в открытом виде следует свести к минимуму. Для SDS необходимы понятные механизмы ротации и отзыва, а также прямое объяснение, отменяют ли похищенный секрет смена PIN и удаление данных Google Password Manager.
The Hacker News направило Google вопрос о том, сохраняет ли украденный Security Domain Secret силу после смены PIN-кода Google Password Manager, а Palo Alto Networks попросило уточнить детали исследования Unit 42. Издание обещало обновить материал после ответа любой из организаций. Пока подтверждена лишь основа некоторых механизмов, а текущая эксплуатируемость, серверные исправления и судьба похищенного SDS остаются неизвестными. Эти сценарии не означают удалённого взлома ключей доступа: сначала атакующему требуется запустить вредоносную программу на Windows-компьютере жертвы. Но после такого проникновения защита может зависеть уже не от стойкости криптографии, а от хранения данных на конечном устройстве, правил повторной регистрации и одного проверенного либо пропущенного UV-бита.
