- 29,081
- 46
- 8 Ноя 2022
Ключи доступа обещали убить фишинг. Атака Pass-ta-key показала, что умирать он пока не собирается.
<div class="articl-text-cover" style="position:relative;width:100%;max-width:800px;margin-left:auto;margin-right:auto;aspect-ratio:1200/676;margin-bottom:2rem;overflow:hidden">
<div itemprop="articleBody">Ключи доступа должны были избавить пользователей от одной из главных проблем паролей: секрет больше не приходится вводить на сайте, поэтому фишинговая страница не может просто перехватить его и повторно использовать для входа. Однако атака Pass-ta-key показала одну неприятную лазейку в Windows. Вредоносная программа на уже заражённом компьютере способна добраться до ключей доступа, сохранённых через Google Password Manager. Публикация вызвала споры ещё и потому, что многие считали такие ключи недоступными для обычных программ после сохранения в TPM.
Название Pass-ta-key обыгрывает английское passkey, выражение pass the key и созвучие с pasta. Атака рассчитана на Google Password Manager в Windows и позволяет получить хранящиеся в учётной записи ключи доступа после заражения компьютера. Важная деталь часто терялась в обсуждениях: Pass-ta-key не взламывает криптографию FIDO2 и не крадёт секреты с сервера Google через неизвестную уязвимость. Для начала злоумышленнику нужен уже скомпрометированный компьютер.
Отсюда возникает вопрос, который и вызвал основную путаницу. TPM, или доверенный платформенный модуль, представляет собой защищённый аппаратный компонент для криптографических операций и хранения чувствительных ключей. Если закрытый ключ нельзя извлечь из TPM, каким образом вредонос получает сразу набор ключей доступа?
Спецификации FIDO2 не требуют хранить каждый ключ доступа внутри TPM или другого аппаратного защищённого модуля. У разных платформ применяются собственные механизмы: Secure Enclave у Apple, доверенная среда выполнения TEE, StrongBox в Android и другие варианты. Аппаратная защита играет важную роль, но стандарт не привязывает все ключи доступа к одному обязательному типу хранилища.
В русской документации Microsoft для passkey используется термин «ключ доступа», поэтому дальше речь именно о ключах доступа FIDO2, а не о паролях или PIN-кодах. Microsoft также поддерживает привязанные к устройству и синхронизированные ключи доступа.
Жёсткая привязка каждого ключа к TPM создала бы серьёзную бытовую проблему. Пользователь покупает новый компьютер или телефон, а перенести уже созданные ключи невозможно. Пришлось бы заходить во все сервисы и создавать учётные данные заново. Массовая замена паролей при такой схеме быстро превратилась бы в неудобную процедуру обслуживания десятков или сотен учётных записей.
Поэтому разработчики операционных систем и менеджеров учётных данных перешли к синхронизации между устройствами. Ключи можно хранить локально в защищённом хранилище либо переносить через зашифрованную облачную инфраструктуру. Конкретная схема зависит от платформы и менеджера.
На macOS, iOS и Android безопасность локального хранилища во многом держится на строгом разделении приложений. Установленная программа не получает автоматически доступ к памяти и данным соседних приложений. Чтобы выйти за пределы выделенной области, вредоносному ПО обычно приходится обходить механизмы самой операционной системы, например эксплуатировать отдельную серьёзную уязвимость.
Windows исторически допускает гораздо более свободное взаимодействие программ, работающих с правами одного пользователя. Система поддерживает песочницы и другие средства изоляции, но обычное приложение вне песочницы в ряде сценариев располагает значительно более широким доступом к пользовательским данным, чем программа на мобильной платформе. Архитектуру сложно радикально изменить из-за многолетней обратной совместимости Windows со старым программным обеспечением.
Разработчики менеджеров ключей доступа учитывают эту особенность. Хранить весь набор закрытых ключей непосредственно на Windows-компьютере рискованно: после заражения вредонос уже работает внутри среды, которой пользователь доверяет собственные учётные записи и приложения. Поэтому Google Password Manager, 1Password, Dashlane и некоторые другие менеджеры используют для Windows облачную схему с шифрованием.
Google Password Manager хранит синхронизированные ключи доступа в учётной записи Google. Компания указывает, что ключи доступа в менеджере защищаются блокировкой Android-устройства либо PIN-кодом Google Password Manager. Поддержка предусмотрена в том числе для Windows 10 и более новых версий системы.
При входе на сайт через Google Password Manager компьютер проходит процедуру проверки, связанную с учётной записью и устройством. В Windows для части схемы используется ключ пользователя или устройства, защищённый TPM. После успешной проверки инфраструктура Google получает возможность сформировать криптографическое подтверждение для сайта.
Сайт не получает закрытый ключ. Серверу передаётся подписанное подтверждение, которое доказывает наличие нужных учётных данных. Закрытый ключ остаётся зашифрованным внутри инфраструктуры менеджера и используется для подписи в рамках предусмотренной процедуры. Многие сторонние менеджеры в Windows строят синхронизацию по близкому принципу.
На других платформах операция может выполняться непосредственно на устройстве. Защищённое локальное хранилище содержит закрытый ключ, а смартфон или компьютер самостоятельно подписывает запрос на вход. Сайт снова получает лишь криптографическое подтверждение, а не секрет, пригодный для копирования и повторного ввода.
Pass-ta-key атакует не криптографический алгоритм, а доверие к уже авторизованному Windows-компьютеру. Вредоносная программа использует доступ к учётной записи Google, а в отдельных вариантах дополнительно обращается к пользовательскому или привязанному к устройству ключу из TPM. Злоумышленник фактически действует изнутри системы, которая уже прошла часть необходимых проверок.
Исследователь описал три варианта Pass-ta-key. Самый мощный заставляет заражённый компьютер с Windows выдавать себя за iPhone. Google Password Manager после этого запускает штатный механизм синхронизации, предназначенный для переноса ключей доступа на новое устройство.
Механизм нужен именно для удобства владельца учётной записи. При покупке нового смартфона не приходится создавать отдельный ключ доступа для каждого сайта заново. Pass-ta-key использует эту полезную функцию против пользователя: заражённая Windows-машина имитирует новое доверенное устройство и получает синхронизированные ключи.
Результат выглядит серьёзно, но принципиально нового класса атак здесь нет. Полностью заражённый компьютер с открытой учётной записью давно считается крайне опасной ситуацией. Если пользователь уже разблокировал менеджер паролей, почту, облачное хранилище или другой чувствительный сервис, работающий с его правами вредонос получает гораздо больше возможностей, чем при атаке извне.
Менеджеры паролей сталкиваются с той же проблемой. Вредонос на разблокированном компьютере может пытаться читать доступные данные, инициировать вход на сайты или использовать штатные функции приложения. Конкретный результат зависит от защиты самого менеджера, разграничения процессов и возможностей вредоносной программы.
Отдельные менеджеры применяют дополнительные меры, чтобы усложнить кражу данных из памяти. Например, программа может использовать системные интерфейсы, ограничивающие чтение определённых областей памяти другими процессами. По описанию Pass-ta-key нельзя исключить, что Google Password Manager защищает некоторые участки слабее специализированных менеджеров вроде 1Password. Однако дополнительные барьеры не меняют основную модель угроз: полностью скомпрометированная и уже авторизованная система больше не считается надёжной средой.
Назначение ключей доступа находится в другой плоскости. Пароль приходится знать пользователю и проверяющему сервису в форме, позволяющей подтвердить совпадение секрета. Человек может ввести пароль на фишинговом сайте, вредонос может перехватить ввод, а утечка серверной базы создаёт материал для дальнейших атак.
Ключи доступа работают на основе пары криптографических ключей. Сервис хранит открытый ключ, а закрытый остаётся под контролем пользователя и его устройств или менеджера учётных данных. Для входа система подписывает запрос закрытым ключом, после чего сервер проверяет подпись открытым. Передавать сам секрет сайту не требуется.
Поэтому фальшивая страница не может просто показать привычную форму, получить ключ доступа в виде строки и затем вставить его на настоящем сайте. Пользователь ничего секретного не печатает и не копирует. Google прямо относит устойчивость к фишингу к преимуществам ключей доступа.
Pass-ta-key показывает другую границу защиты. Если вредонос уже выполняет команды на авторизованном Windows-компьютере, атакующему зачастую незачем ломать FIDO2 или пытаться вычислить закрытый ключ. Проще использовать законные функции синхронизации и права, которые система предоставляет владельцу учётной записи.
Поэтому Pass-ta-key не доказывает ненадёжность ключей доступа как замены паролям. Атака напоминает о более старой и неприятной проблеме: после полного заражения компьютера безопасность зависит уже не только от способа входа. На Windows последствия особенно серьёзны из-за менее жёсткой изоляции настольных приложений, а открытая учётная запись превращает штатные механизмы восстановления и синхронизации в инструменты, которыми может воспользоваться вредоносное ПО.
<div class="articl-text-cover" style="position:relative;width:100%;max-width:800px;margin-left:auto;margin-right:auto;aspect-ratio:1200/676;margin-bottom:2rem;overflow:hidden">
<div itemprop="articleBody">Ключи доступа должны были избавить пользователей от одной из главных проблем паролей: секрет больше не приходится вводить на сайте, поэтому фишинговая страница не может просто перехватить его и повторно использовать для входа. Однако атака Pass-ta-key показала одну неприятную лазейку в Windows. Вредоносная программа на уже заражённом компьютере способна добраться до ключей доступа, сохранённых через Google Password Manager. Публикация вызвала споры ещё и потому, что многие считали такие ключи недоступными для обычных программ после сохранения в TPM.
Название Pass-ta-key обыгрывает английское passkey, выражение pass the key и созвучие с pasta. Атака рассчитана на Google Password Manager в Windows и позволяет получить хранящиеся в учётной записи ключи доступа после заражения компьютера. Важная деталь часто терялась в обсуждениях: Pass-ta-key не взламывает криптографию FIDO2 и не крадёт секреты с сервера Google через неизвестную уязвимость. Для начала злоумышленнику нужен уже скомпрометированный компьютер.
Отсюда возникает вопрос, который и вызвал основную путаницу. TPM, или доверенный платформенный модуль, представляет собой защищённый аппаратный компонент для криптографических операций и хранения чувствительных ключей. Если закрытый ключ нельзя извлечь из TPM, каким образом вредонос получает сразу набор ключей доступа?
Спецификации FIDO2 не требуют хранить каждый ключ доступа внутри TPM или другого аппаратного защищённого модуля. У разных платформ применяются собственные механизмы: Secure Enclave у Apple, доверенная среда выполнения TEE, StrongBox в Android и другие варианты. Аппаратная защита играет важную роль, но стандарт не привязывает все ключи доступа к одному обязательному типу хранилища.
В русской документации Microsoft для passkey используется термин «ключ доступа», поэтому дальше речь именно о ключах доступа FIDO2, а не о паролях или PIN-кодах. Microsoft также поддерживает привязанные к устройству и синхронизированные ключи доступа.
Жёсткая привязка каждого ключа к TPM создала бы серьёзную бытовую проблему. Пользователь покупает новый компьютер или телефон, а перенести уже созданные ключи невозможно. Пришлось бы заходить во все сервисы и создавать учётные данные заново. Массовая замена паролей при такой схеме быстро превратилась бы в неудобную процедуру обслуживания десятков или сотен учётных записей.
Поэтому разработчики операционных систем и менеджеров учётных данных перешли к синхронизации между устройствами. Ключи можно хранить локально в защищённом хранилище либо переносить через зашифрованную облачную инфраструктуру. Конкретная схема зависит от платформы и менеджера.
На macOS, iOS и Android безопасность локального хранилища во многом держится на строгом разделении приложений. Установленная программа не получает автоматически доступ к памяти и данным соседних приложений. Чтобы выйти за пределы выделенной области, вредоносному ПО обычно приходится обходить механизмы самой операционной системы, например эксплуатировать отдельную серьёзную уязвимость.
Windows исторически допускает гораздо более свободное взаимодействие программ, работающих с правами одного пользователя. Система поддерживает песочницы и другие средства изоляции, но обычное приложение вне песочницы в ряде сценариев располагает значительно более широким доступом к пользовательским данным, чем программа на мобильной платформе. Архитектуру сложно радикально изменить из-за многолетней обратной совместимости Windows со старым программным обеспечением.
Разработчики менеджеров ключей доступа учитывают эту особенность. Хранить весь набор закрытых ключей непосредственно на Windows-компьютере рискованно: после заражения вредонос уже работает внутри среды, которой пользователь доверяет собственные учётные записи и приложения. Поэтому Google Password Manager, 1Password, Dashlane и некоторые другие менеджеры используют для Windows облачную схему с шифрованием.
Google Password Manager хранит синхронизированные ключи доступа в учётной записи Google. Компания указывает, что ключи доступа в менеджере защищаются блокировкой Android-устройства либо PIN-кодом Google Password Manager. Поддержка предусмотрена в том числе для Windows 10 и более новых версий системы.
При входе на сайт через Google Password Manager компьютер проходит процедуру проверки, связанную с учётной записью и устройством. В Windows для части схемы используется ключ пользователя или устройства, защищённый TPM. После успешной проверки инфраструктура Google получает возможность сформировать криптографическое подтверждение для сайта.
Сайт не получает закрытый ключ. Серверу передаётся подписанное подтверждение, которое доказывает наличие нужных учётных данных. Закрытый ключ остаётся зашифрованным внутри инфраструктуры менеджера и используется для подписи в рамках предусмотренной процедуры. Многие сторонние менеджеры в Windows строят синхронизацию по близкому принципу.
На других платформах операция может выполняться непосредственно на устройстве. Защищённое локальное хранилище содержит закрытый ключ, а смартфон или компьютер самостоятельно подписывает запрос на вход. Сайт снова получает лишь криптографическое подтверждение, а не секрет, пригодный для копирования и повторного ввода.
Pass-ta-key атакует не криптографический алгоритм, а доверие к уже авторизованному Windows-компьютеру. Вредоносная программа использует доступ к учётной записи Google, а в отдельных вариантах дополнительно обращается к пользовательскому или привязанному к устройству ключу из TPM. Злоумышленник фактически действует изнутри системы, которая уже прошла часть необходимых проверок.
Исследователь описал три варианта Pass-ta-key. Самый мощный заставляет заражённый компьютер с Windows выдавать себя за iPhone. Google Password Manager после этого запускает штатный механизм синхронизации, предназначенный для переноса ключей доступа на новое устройство.
Механизм нужен именно для удобства владельца учётной записи. При покупке нового смартфона не приходится создавать отдельный ключ доступа для каждого сайта заново. Pass-ta-key использует эту полезную функцию против пользователя: заражённая Windows-машина имитирует новое доверенное устройство и получает синхронизированные ключи.
Результат выглядит серьёзно, но принципиально нового класса атак здесь нет. Полностью заражённый компьютер с открытой учётной записью давно считается крайне опасной ситуацией. Если пользователь уже разблокировал менеджер паролей, почту, облачное хранилище или другой чувствительный сервис, работающий с его правами вредонос получает гораздо больше возможностей, чем при атаке извне.
Менеджеры паролей сталкиваются с той же проблемой. Вредонос на разблокированном компьютере может пытаться читать доступные данные, инициировать вход на сайты или использовать штатные функции приложения. Конкретный результат зависит от защиты самого менеджера, разграничения процессов и возможностей вредоносной программы.
Отдельные менеджеры применяют дополнительные меры, чтобы усложнить кражу данных из памяти. Например, программа может использовать системные интерфейсы, ограничивающие чтение определённых областей памяти другими процессами. По описанию Pass-ta-key нельзя исключить, что Google Password Manager защищает некоторые участки слабее специализированных менеджеров вроде 1Password. Однако дополнительные барьеры не меняют основную модель угроз: полностью скомпрометированная и уже авторизованная система больше не считается надёжной средой.
Назначение ключей доступа находится в другой плоскости. Пароль приходится знать пользователю и проверяющему сервису в форме, позволяющей подтвердить совпадение секрета. Человек может ввести пароль на фишинговом сайте, вредонос может перехватить ввод, а утечка серверной базы создаёт материал для дальнейших атак.
Ключи доступа работают на основе пары криптографических ключей. Сервис хранит открытый ключ, а закрытый остаётся под контролем пользователя и его устройств или менеджера учётных данных. Для входа система подписывает запрос закрытым ключом, после чего сервер проверяет подпись открытым. Передавать сам секрет сайту не требуется.
Поэтому фальшивая страница не может просто показать привычную форму, получить ключ доступа в виде строки и затем вставить его на настоящем сайте. Пользователь ничего секретного не печатает и не копирует. Google прямо относит устойчивость к фишингу к преимуществам ключей доступа.
Pass-ta-key показывает другую границу защиты. Если вредонос уже выполняет команды на авторизованном Windows-компьютере, атакующему зачастую незачем ломать FIDO2 или пытаться вычислить закрытый ключ. Проще использовать законные функции синхронизации и права, которые система предоставляет владельцу учётной записи.
Поэтому Pass-ta-key не доказывает ненадёжность ключей доступа как замены паролям. Атака напоминает о более старой и неприятной проблеме: после полного заражения компьютера безопасность зависит уже не только от способа входа. На Windows последствия особенно серьёзны из-за менее жёсткой изоляции настольных приложений, а открытая учётная запись превращает штатные механизмы восстановления и синхронизации в инструменты, которыми может воспользоваться вредоносное ПО.
- Источник новости
- www.securitylab.ru
