Новые атаки Pass-ta-key позволяют вредоносному ПО перехватывать синхронизированные с Google пароли

Исследователи безопасности обнаружили три атаки, которые позволяют вредоносному ПО на уже скомпрометированных устройствах Windows злоупотреблять синхронизированными паролями Google Password Manager для захвата учетных записей, обхода проверки пользователей и извлечения закрытых ключей паролей.

Пароли — это метод аутентификации без пароля, который использует криптографические ключи, хранящиеся на устройстве пользователя, для входа в онлайн-аккаунты.

Они считаются более безопасными, чем пароли, поскольку их невозможно угадать, повторно использовать или легко украсть с помощью фишинга, а также они позволяют пользователям проходить аутентификацию с помощью PIN-кода или биометрических данных, таких как отпечаток пальца или распознавание лица.

«В отличие от паролей, пароли нельзя передавать, копировать, записывать или случайно передавать кому-либо другому. «Это делает их более защищенными от фишинга», — говорится в сообщении Документация Google по ключам доступа.

Однако новый отчет подразделения 42 компании Palo Alto Networks демонстрирует три новые атаки, которые в совокупности называются «Pass-ta-key,» которые нацелены на диспетчер паролей Google в Chrome на устройствах Windows, оснащенных модулем доверенной платформы (TPM).

Все три атаки требуют, чтобы вредоносное ПО уже было запущено на компьютере жертвы и не нарушало криптографию, используемую паролями. Вместо этого они используют недостатки в том, как Chrome и облачный аутентификатор Google обрабатывают доверие к устройству, регистрацию, восстановление и синхронизированные учетные данные.

Первая техника, названная Pass-ta-key, позволяет непривилегированному вредоносному ПО выдавать себя за доверенное устройство и запрашивать действительный ответ аутентификации для одного из паролей жертвы.

Вредоносная программа использует ключ идентификации устройства Chrome, поддерживаемый TPM, для подписи запроса, отправляемого в облачный аутентификатор Google. Это можно сделать без прав администратора, взаимодействия с пользователем, биометрии или разблокировки устройства.

Затем облачный аутентификатор Google рассматривает запрос как исходящий от доверенного компьютера жертвы и возвращает подписанный ответ аутентификации, известный как утверждение, который можно использовать для входа в целевую учетную запись.

Однако утверждение включает флаг проверки пользователя, указывающий, проводилась ли биометрическая проверка или проверка PIN-кода. Это приводит к сбою атаки, если служба требует и должным образом подтверждает, что проверка пользователя прошла успешно.

Pass-ta-key не работает при попытке аутентификации на GitHub
Источник: Unit 42

Хотя атака на GitHub, который должным образом проверил флаг проверки пользователя, не удалась, Unit 42 заявила, что успешно протестировала атаку на eBay. Хотя eBay требовал проверки пользователя, он не проверял должным образом флаг, указывающий, произошла ли эта проверка.

eBay устранил проблему после того, как о ней сообщили исследователи.

Вторая техника, названная Silver Pass-ta-key, идет еще дальше, позволяя злоумышленникам зарегистрировать свой собственный ключ проверки пользователя в облачном аутентификаторе Google.

Сначала злоумышленник использует вредоносное ПО на взломанном устройстве, чтобы заставить Chrome перерегистрировать его, сделав недействительным существующий ключ проверки или удалив локальный файл, содержащий состояние его ключа доступа.

В процессе повторной регистрации злоумышленник может зарегистрировать ключ проверки пользователя, которым он управляет, поскольку облачный аутентификатор не проверяет, исходит ли новый ключ от доверенного оборудования.

Затем Google принимает запросы, подписанные ключом злоумышленника, в качестве доказательства того, что жертва разблокировала устройство с помощью PIN-кода или биометрических данных. Это позволяет злоумышленнику получить доступ к учетным записям, которые должным образом требуют и подтверждают проверку пользователя.

После регистрации вредоносного ключа злоумышленник может пройти аутентификацию из другой системы без необходимости дальнейшего доступа к компьютеру жертвы.

Третья и самая суровая техника, названная Golden Pass-ta-key, позволяет вредоносному ПО получить главный ключ, используемый для шифрования всех паролей, синхронизированных через учетную запись Google Password Manager жертвы.

Этот главный ключ, известный как секрет домена безопасности, временно отправляется в Chrome, когда устройство регистрируется или восстанавливает доступ к учетной записи.

Первоначально Unit 42 обнаружило, что Chrome раскрыл секрет в открытом виде через свои внутренние журналы FIDO. Google удалил секрет из журналов после того, как исследователи сообщили о проблеме, но Unit 42 утверждает, что он по-прежнему отправляется в Chrome и остается временно доступным в памяти процесса браузера.

«Хотя Google удалил этот секрет из выходных данных журнала Chrome после нашего отчета, SDS по-прежнему отправляется клиенту и остается доступным в памяти процесса Chrome», объясняет Unit 42.

«Если злоумышленник заставит жертву перерегистрироваться в облачном аутентификаторе и узнает шаблон, который нужно искать, он сможет извлечь SDS непосредственно из памяти»

Затем злоумышленник может использовать украденный главный ключ для расшифровки синхронизированных записей паролей жертвы и восстановления ее закрытых ключей. Эти закрытые ключи можно передать в другую систему и использовать для выдачи себя за жертву и входа в ее учетные записи.

Блок 42 предупреждает, что украденный главный ключ также может быть использован для расшифровки будущих паролей, синхронизированных с учетной записью. Сообщается, что текущая реализация Google не предусматривает возможности ротации или отзыва ключа, а это означает, что текущие и будущие синхронизированные пароли остаются защищенными одним и тем же секретом.

Хотя исследователи утверждают, что пароли остаются значительно безопаснее традиционных паролей, атаки показывают, что они не устраняют риски, связанные с вредоносным ПО, уже запущенным на взломанном устройстве.

В Unit 42 рекомендуется, чтобы веб-сайты требовали и надлежащим образом подтверждали проверку пользователей. Менеджеры учетных данных также должны проверять вновь зарегистрированные ключи устройств, упрощать процессы восстановления и повторной регистрации устройств, а также предотвращать доступ к главным ключам в памяти браузера.

Исследователи раскрыли Google информацию об атаках Google Password Manager и сообщили о связанных с ними недостатках проверки пользователей затронутым сервисам, включая eBay, прежде чем опубликовать свои выводы.

Редактор: AndreyEx