Исследователи безопасности обнаружили три новых метода атак, которые позволяют вредоносным программам на уже скомпрометированных устройствах с Windows злоупотреблять ключами доступа, синхронизированными через Менеджер паролей Google. С помощью этих атак злоумышленники могут захватывать учетные записи, обходить проверку пользователя и извлекать закрытые криптографические ключи, связанные с ключами доступа.
Ключи доступа (passkeys) – это беспарольный способ аутентификации. Для входа в учетную запись используются криптографические ключи, которые хранятся на устройстве пользователя и подтверждают его личность.
Ключи доступа считаются более безопасными, чем обычные пароли. Их нельзя подобрать, повторно использовать на разных сайтах или легко похитить с помощью фишинга. При этом пользователь может подтверждать вход с помощью PIN-кода или биометрии – например, отпечатка пальца или распознавания лица.
В документации Google по ключам доступа сообщается:
В отличие от паролей, ключи доступа нельзя передать, скопировать, записать или случайно сообщить другому человеку. Благодаря этому они лучше защищены от фишинга.
В новом отчете подразделение Unit 42 компании Palo Alto Networks описало три новых метода атак, которые получили общее название Pass-ta-key. Они нацелены на Менеджер паролей Google в браузере Chrome на устройствах с Windows, оснащенных доверенным платформенным модулем TPM.
Для проведения всех трех атак вредоносная программа уже должна работать на компьютере жертвы. Исследователи не взламывают криптографические механизмы ключей доступа. Вместо этого атаки используют недостатки в том, как Chrome и облачный аутентификатор Google проверяют доверие к устройству, выполняют первоначальную настройку и восстановление, а также обрабатывают синхронизированные учетные данные.
Pass-ta-key
Первый метод получил название Pass-ta-key. Он позволяет вредоносной программе без повышенных привилегий выдать себя за доверенное устройство и запросить действительный ответ аутентификации для одного из ключей доступа жертвы.
Для этого вредоносное ПО использует защищенный TPM ключ идентификации устройства Chrome, чтобы подписать запрос, отправляемый облачному аутентификатору Google. Атака не требует прав администратора, действий со стороны пользователя, биометрической проверки или разблокировки устройства.
Облачный аутентификатор Google воспринимает запрос как поступивший с доверенного компьютера жертвы и возвращает подписанный ответ аутентификации. Такой ответ называется assertion и может использоваться для входа в целевую учетную запись.
Однако в assertion также содержится флаг User Verified, который показывает, проходил ли пользователь проверку с помощью биометрии или PIN-кода. Поэтому атака не сработает, если сервис требует такую проверку и корректно убеждается, что она действительно была успешно выполнена.
Атака не сработала против GitHub, поскольку сервис корректно проверял флаг User Verified. Однако специалисты Unit 42 успешно протестировали ее на eBay. Сервис требовал подтверждения пользователя, но неправильно проверял флаг, который указывает, действительно ли такая проверка была выполнена. После уведомления исследователей eBay устранила проблему.
Silver Pass-ta-key
Второй метод получил название Silver Pass-ta-key. Он представляет более серьезную угрозу, поскольку позволяет злоумышленникам зарегистрировать собственный ключ проверки пользователя в облачном аутентификаторе Google.
Сначала злоумышленник использует вредоносную программу на скомпрометированном устройстве, чтобы принудительно запустить повторную регистрацию Chrome. Для этого он делает недействительным существующий ключ проверки или удаляет локальный файл, в котором хранится состояние ключей доступа.
Во время повторной регистрации злоумышленник может добавить в облачный аутентификатор Google собственный ключ проверки пользователя. Это возможно потому, что сервис не проверяет, был ли новый ключ создан в доверенном аппаратном модуле.
После этого Google воспринимает запросы, подписанные ключом злоумышленника, как подтверждение того, что жертва разблокировала устройство с помощью PIN-кода или биометрии. Благодаря этому атакующий может получить доступ даже к учетным записям, которые требуют и корректно проверяют подтверждение пользователя.
После регистрации вредоносного ключа злоумышленник может проходить аутентификацию с другого устройства. Дополнительный доступ к компьютеру жертвы ему уже не требуется.
Golden Pass-ta-key
Третий и наиболее опасный метод получил название Golden Pass-ta-key. Он позволяет вредоносной программе получить главный ключ, который используется для шифрования всех ключей доступа, синхронизированных через учетную запись Менеджера паролей Google жертвы.
Этот главный ключ называется секретом домена безопасности – Security Domain Secret, или SDS. Google временно передает его браузеру Chrome, когда устройство регистрируется в системе или восстанавливает доступ к учетной записи.
Первоначально специалисты Unit 42 обнаружили, что Chrome выводил этот секрет в открытом виде во внутренних журналах FIDO. После уведомления исследователей Google удалила секрет из журналов. Однако, по данным Unit 42, SDS по-прежнему передается браузеру и некоторое время остается доступным в памяти процесса Chrome.
Специалисты Unit 42 пояснили:
Хотя после нашего уведомления Google удалила этот секрет из журналов Chrome, SDS по-прежнему передается клиенту и остается доступным в памяти процесса браузера.
Если злоумышленник заставит устройство жертвы повторно зарегистрироваться в облачном аутентификаторе и будет знать, какие данные искать, он сможет извлечь SDS непосредственно из памяти.
После этого атакующий может использовать похищенный главный ключ для расшифровки синхронизированных записей ключей доступа и извлечения их закрытых ключей. Затем эти ключи можно перенести на другое устройство, чтобы выдавать себя за жертву и входить в ее учетные записи.
Что рекомендуют исследователи
Исследователи подчеркивают, что ключи доступа по-прежнему значительно безопаснее традиционных паролей. Однако обнаруженные атаки показывают, что они не устраняют угрозу со стороны вредоносных программ, которые уже работают на скомпрометированном устройстве.
Unit 42 рекомендует:
- сайтам – требовать подтверждение пользователя и корректно проверять, действительно ли оно было выполнено;
- разработчикам менеджеров учетных данных – проверять новые ключи устройств;
- усиливать защиту процедур восстановления и повторной регистрации;
- не допускать, чтобы главные ключи становились доступными в памяти браузера.
До публикации отчета исследователи сообщили Google об атаках на Менеджер паролей Google. Они также уведомили затронутые сервисы, включая eBay, об ошибках в проверке подтверждения пользователя.