Исследователи Palo Alto Networks описали сразу три атаки на Google Password Manager, которые позволяли угонять аккаунты, защищенные с помощью passkey. Хотя атаки подразумевают, что компьютер жертвы должен был быть скомпрометирован заранее, при этом малвари не требуются права администратора, PIN-код, биометрия или взаимодействие с пользователем.
Атаки этой серии получили названия Pass-ta-key, Silver Pass-ta-key и Golden Pass-ta-key. Все они затрагивают браузер Chrome на устройствах под управлением Windows, оснащенных модулем Trusted Platform Module (TPM).
Эксперты объясняют, что атаки Pass-ta-key не компрометируют криптографию менеджера паролей, а эксплуатируют слабости в механизмах доверия, регистрации, восстановления и синхронизации учетных данных.
В первом сценарии, который специалисты назвали Pass-ta-key, малварь с обычными пользовательскими правами выдает себя за доверенное устройство и запрашивает аутентификационный ответ для одного из passkey жертвы. Для этого вредонос использует сохраненный Chrome блоб, содержащий ключ идентификации устройства (identity key). При этом закрытый ключ остается внутри TPM, однако вредонос может обратиться к нему посредством Windows CNG, вынудив подписать запрос атакующего.
В результате облачный аутентификатор Google считает, что запрос поступил от доверенного устройства, и возвращает действительный ответ для входа в аккаунт. Однако в нем не установлен флаг User Verified (UV), который должен свидетельствовать о том, что пользователь подтвердил операцию с помощью PIN-кода или биометрии.
Из-за этой особенности атака не работает против сервисов, которые действительно проверяют UV. Например, GitHub отклонил подготовленный исследователями запрос, а системы eBay приняли ответ без UV (в настоящее время разработчики eBay уже устранили эту проблему).
Вторая атака, Silver Pass-ta-key, связана с повторной регистрацией устройства и построена на том, что проникшая в систему малварь повреждает локальное состояние Google Password Manager (к примеру, удалив локальные файлы), тем самым вынуждая Chrome заново зарегистрироваться в облачном аутентификаторе Google. Как выяснили исследователи, атакующий может успеть зарегистрировать собственный ключ user-verification, так как сервис не проверяет, был ли новый ключ создан на доверенном оборудовании.
После этого облачный аутентификатор Google принимает запросы, подписанные ключом злоумышленника, за подтверждение того, что жертва разблокировала устройство с помощью PIN-кода или биометрии (то есть запросы получают флаг UV). С помощью такого ключа злоумышленник может входить в аккаунты со своего устройства, даже не имея доступа к компьютеру жертвы.
Третья и наиболее опасная атака получила имя Golden Pass-ta-key и позволяет похитить 32-байтовый Security Domain Secret (SDS) — мастер-ключ, которым защищены все синхронизированные passkey в учетной записи Google Password Manager жертвы. Дело в том, что во время повторной регистрации устройства в облачном аутентификаторе Chrome некоторое время хранит SDS в открытом виде в памяти своего процесса. И оттуда его может извлечь малварь.
«Если злоумышленник вынудит жертву повторно зарегистрироваться в облачном аутентификаторе и знает, какой шаблон нужно искать, он может извлечь SDS непосредственно из памяти», — говорят эксперты.
После получения SDS атакующий может расшифровать приватные ключи, связанные с passkey, перенести их в другую систему и выдать себя за жертву. Кроме того, исследователи отмечают, что тот же SDS потенциально позволяет расшифровывать любые ключи доступа, которые появятся в аккаунте жертвы позднее. Пока неясно, можно ли отозвать украденный SDS путем смены PIN-кода Google Password Manager или удаления сохраненных данных.
Следует отметить, что в своем отчете специалисты не приводят идентификаторы CVE, не перечисляют уязвимые версии Chrome, а также не сообщают, устранены ли проблемы Pass-ta-key в настоящее время.
При этом эксперты подчеркивают, что passkey остаются безопаснее обычных паролей, хотя и не защищают от малвари, которая уже скомпрометировала устройство. Владельцам сайтов специалисты рекомендуют всегда подтверждать личность пользователя и обязательно валидировать флаг UV. Разработчикам менеджеров учетных данных они советуют проверять происхождение новых ключей, усилить защиту процедур восстановления и не допускать появления мастер-ключей в логах и памяти клиентских приложений.
