Введение: иллюзия абсолютной защиты и новые вызовы безопасности

Мир информационной безопасности долгое время двигался в сторону полного отказа от паролей. Концепция беспарольной аутентификации на базе стандарта WebAuthn и FIDO2 преподносилась разработчикам как серебряная пуля против фишинга, утечек баз данных и брутфорса. Паскеи (passkeys) казались непреодолимой преградой: закрытый ключ надежно заперт на аппаратном уровне, и даже при глубоком заражении рабочей станции украсть его невозможно.

Однако исследование специалиста из Palo Alto Networks Арье Ольшейна (Arie Olshtein) перевернуло эти представления. Новая атака Pass-ta-key продемонстрировала возможность извлечения паскеев из приложения Google Password Manager (GPM) для Windows на уже скомпрометированном хосте.

Это открытие вызвало серьезные дискуссии в IT-сообществе. Разберем механику атаки Pass-ta-key, развенчаем мифы об абсолютной изоляции ключей и оценим реальные риски для корпоративной и пользовательской безопасности.

Анатомия атаки Pass-ta-key: как работает эксплойт

Название Pass-ta-key объединяет термины passkey, концепцию атак «pass the key» и специфику работы с программными хранилищами. Главной мишенью исследования стало приложение Google Password Manager (GPM) для Windows.

В экосистеме Windows пользователи активно используют десктопные клиенты и браузеры для синхронизации учетных данных. Когда создается паскей, менеджер паролей сохраняет его для бесшовного входа. Стандартный инфостилер при заражении ПК ищет куки, токены сессий и пароли. В случае с Pass-ta-key малварь нацеливается на программные хранилища GPM, извлекая приватные ключи до того, как они будут задействованы в криптографическом вызове.

Программные vs Аппаратные паскеи: где проходит грань уязвимости

Важно понимать критическую разницу между двумя подходами к хранению паскеев:

  • Аппаратные ключи (Hardware-bound): Ключи хранятся на физических токенах (YubiKey) или в защищенных модулях (TPM 2.0, Apple Secure Enclave, Android StrongBox). Извлечь их оттуда программным путем физически невозможно — подпись транзакции происходит внутри чипа.
  • Программные ключи (Software-bound): Ключи синхронизируются через облачные сервисы (iCloud Keychain, Google Password Manager, Bitwarden) и хранятся в зашифрованном виде на диске устройства. Именно этот уровень удобства становится уязвимым на зараженной ОС.

Атака Pass-ta-key бьет именно по программным паскеям в средах вроде Windows, где безопасность конечного приложения зависит от целостности всей операционной системы.

Пример из практики: как вредоносное ПО обращается к данным

Чтобы понять вектор атаки, посмотрим, как вредоносный код может взаимодействовать с локальной файловой системой Windows при компрометации уровня пользователя (конечно, если у малвари нет прав администратора, она просто поплачет в логи, но мы-то знаем, под чьей учеткой обычно запускают всё подряд):

import os
import sqlite3

def scan_gpm_storage():
    # Типичный путь к данным профиля Google Chrome / GPM в Windows
    local_app_data = os.environ.get('LOCALAPPDATA')
    gpm_path = os.path.join(local_app_data, r'Google\Chrome\User Data\Default')
    
    if os.path.exists(gpm_path):
        print('[+] Обнаружена директория профиля Google. Запуск анализа хранилищ...')
        # В реальности малварь производит поиск специфических баз данных LevelDB и SQLite
    else:
        print('[-] Целевой профиль не найден.')

scan_gpm_storage()

Получив доступ к зашифрованным файлам локального хранилища при наличии прав текущего пользователя (и ключей шифрования DPAPI, привязанных к сеансу Windows), продвинутый стилер может сдампить данные в момент их расшифровки.

Заключение: стоит ли отказываться от паскеев?

Атака Pass-ta-key — это не уязвимость самого протокола FIDO2 или спецификации WebAuthn. Это демонстрация классической аксиомы информационной безопасности: если ваш хос