Unit 42 раскрыла три сценария захвата аккаунтов через Google Password Manager
Исследователи Unit 42 описали три пути атаки на облачный аутентификатор Google Password Manager в Chrome для Windows с модулем TPM. Вредоносная программа, уже запущенная с правами обычного пользователя, может получить корректное подтверждение входа, подменить ключ проверки пользователя или извлечь 32-байтный Security Domain Secret, защищающий синхронизированные закрытые ключи доступа.
Криптографию ключей доступа эти техники не ломают. Они используют особенности окружающего кода: хранение идентификационных ключей устройства, повторную регистрацию после утраты локального состояния и проверку флага User Verified на стороне сайта. Сведений об эксплуатации в реальных атаках, номеров CVE, перечня затронутых версий Chrome и полного статуса исправлений в публикации нет.
Как устроены три сценария
Первый сценарий, Pass-ta-key, извлекает обёрнутый ключ идентификации устройства Chrome и просит тот же TPM подписать запрос через Windows CNG. Google Cloud Authenticator возвращает действительное подтверждение, но флаг UV остаётся снятым. По спецификации Web Authentication сайт, запросивший обязательную проверку пользователя, должен отклонить такой вход.
Unit 42 сообщила, что GitHub корректно проверял UV, тогда как eBay принял тестовое подтверждение и устранил пробел после уведомления. Этот путь напрямую зависит от проверки на стороне сайта: при строгой реализации она блокирует вход.
Silver Pass-ta-key использует повторную регистрацию устройства. Пока Chrome откладывает создание собственного ключа проверки пользователя, вредоносная программа может зарегистрировать ключ злоумышленника. По версии исследователей, сервис не проверяет, создан ли новый ключ защищённым оборудованием, а подписанные им ответы содержат флаг UV и пригодны для последующих входов с другого устройства.
Golden Pass-ta-key нацелен на SDS. Вредоносная программа инициирует повторную регистрацию, считывает секрет из памяти процесса Chrome в момент, когда он находится там в открытом виде, и использует его для расшифровки синхронизированных закрытых ключей. Исходный код Chromium подтверждает попадание 32-байтного секрета в структуры данных клиентского процесса, но надёжность извлечения и сохранение доступа после смены эпохи секрета остаются утверждениями Unit 42 либо открытыми вопросами.
Ограничения и меры защиты
Все три техники относятся к этапу после компрометации: они не объясняют, как вредоносное ПО попало на компьютер. Локальная разведка начинается с каталога синхронизации Chrome, где непривилегированный процесс, по оценке исследователей, может прочитать метаданные сайтов, имена пользователей, идентификаторы учётных данных и зашифрованный ключевой материал.
На фоне масштабных исправлений уязвимостей Chrome новый отчёт подчёркивает, что исправления браузера необходимо дополнять контролем конечных устройств и серверной проверкой аутентификации. Unit 42 указывает, что Google убрала прежнее появление SDS в журналах FIDO, а eBay включила проверку UV, однако публикация не подтверждает закрытие всех трёх путей.
Владельцам сервисов следует задавать userVerification как обязательную и проверять возвращённый флаг UV. Поставщикам учётных данных рекомендованы аттестация новых ключей, усиление повторной регистрации и восстановления, ограничение доступа к локальному состоянию ключей доступа и исключение мастер-ключей из журналов и памяти клиента.
Для бизнеса практический вывод состоит в сочетании двух уровней защиты: предотвращать запуск вредоносного ПО на рабочих станциях и независимо проверять подтверждения WebAuthn на сервере. Смена PIN Google Password Manager или удаление данных менеджера описаны в справке Google, но доступные материалы не подтверждают, что эти действия аннулируют уже похищенный SDS.