Дослідники Palo Alto Networks Unit 42 опублікували дослідження трьох постексплуатаційних технік, які дають змогу шкідливому ПЗ, що працює з правами звичайного користувача на Windows-системі з TPM, виконувати автентифікацію в облікових записах жертви, захищених passkey, — без біометрії, PIN-коду та будь-яких повідомлень на екрані. Атаки спрямовані проти Google Password Manager у браузері Chrome і не ламають криптографію WebAuthn, а експлуатують особливості зберігання ключів, логіку повторної реєстрації пристрою та перевірки прапорця верифікації користувача на стороні вебсервісів. Випадків експлуатації в реальних атаках не зафіксовано, CVE-ідентифікатори не присвоєні, а повний статус виправлень залишається невідомим.
Архітектурні передумови атак
Усі три методи — Pass-ta-key, Silver Pass-ta-key і Golden Pass-ta-key — вимагають попереднього запуску шкідливого коду на пристрої жертви. Це постексплуатаційні техніки: вони описують, що зловмисник може зробити вже на скомпрометованій машині, а не спосіб початкового проникнення.
За даними дослідників, Chrome зберігає синхронізовані облікові дані в каталозі %LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB, і непривілейований процес здатен прочитати метадані, включно з ідентифікаторами сервісів (relying party), іменами користувачів, ідентифікаторами облікових даних і зашифрованим матеріалом закритих ключів.
Ключова архітектурна особливість підтверджується вихідним кодом Chromium: Chrome створює TPM-ключ без імені (що, згідно з коментарем у коді, запобігає його збереженню на диск), експортує його як непрозорий blob, а потім повторно завантажує. Під час підписання використовується прапорець NCryptSignHash, який придушує будь-які запити до користувача. У тому ж файлі є TODO-коментар із посиланням на задачу Chromium 398125799, що пропонує маркувати такі ключі.
Три вектори атаки
Pass-ta-key: обхід без верифікації користувача
Перший метод витягує обгорнутий ключ ідентифікації пристрою Chrome і через Windows CNG API запитує в того самого TPM підпис для запиту, який контролює зловмисник. Хмарний аутентифікатор Google повертає коректне ствердження (assertion), що відрізняється від легітимного лише одним бітом — прапорцем User Verified (UV), який залишається невстановленим.
Відповідно до специфікації Web Authentication Level 3, якщо сервіс встановлює параметр userVerification у значення «required», він зобов’язаний відхилити автентифікацію за відсутності UV-біта. За даними Unit 42, GitHub коректно виконував цю перевірку, тоді як eBay приймав такі ствердження доти, доки не усунув проблему після розкриття інформації.
Silver Pass-ta-key: підміна ключа верифікації
Другий метод націлений на процес повторної реєстрації пристрою. Шкідливе ПЗ примусово ініціює перереєстрацію Chrome, і в отриманому часовому вікні — коли браузер ще не створив ключ верифікації користувача — зловмисник реєструє власний ключ. Вихідний код Chromium підтверджує існування стану deferred_uv_key_creation для щойно зареєстрованих пристроїв.
За твердженням дослідників, серверна сторона не перевіряє, чи був щойно зареєстрований ключ отриманий від апаратного модуля безпеки. Ствердження, підписані підставним ключем, мають встановлений UV-прапорець, що, за повідомленням, дає змогу виконувати автентифікацію з пристрою зловмисника без доступу до машини жертви. Втім, публічний код Chromium не дає змоги незалежно верифікувати серверну частину цієї атаки для поточної стабільної версії Chrome.
Golden Pass-ta-key: вилучення майстер-секрету
Найсерйозніший третій метод націлений на 32-байтовий Security Domain Secret (SDS) — майстер-ключ, який використовують для розшифрування синхронізованих закритих ключів passkey. За даними Unit 42, шкідливе ПЗ ініціює перереєстрацію й зчитує секрет із пам’яті процесу Chrome в момент, коли він нетривалий час перебуває там у відкритому вигляді.
Вихідний код Chromium підтверджує, що Chrome створює або отримує 32-байтові секрети домена безпеки в структурах даних клієнтського процесу. Втім, надійність вилучення, можливість захоплення облікового запису та збереження доступу під час зміни епох секрету залишаються непідтвердженими незалежними джерелами.
Дослідники повідомляють, що Google усунув раніше наявний витік SDS через FIDO-логи Chrome, однак секрет і надалі потрапляє в пам’ять клієнта, що не закриває описаний вектор.
Невизначеність зі статусом виправлень
Розкриття не уточнює, чи закриті всі три вектори атаки. Дослідження не містить CVE-ідентифікаторів, переліку уражених версій Chrome і повного статусу виправлень. Публічна документація Google дозволяє користувачам змінити PIN-код Google Password Manager або видалити всі дані менеджера паролів, але не описує механізм ротації чи відкликання SDS. Залишається відкритим критичне питання: чи анулює зміна PIN-коду або видалення даних секрет, уже вилучений зловмисником.
Оцінка впливу
Сфера впливу обмежена користувачами Chrome на Windows з TPM, які використовують Google Password Manager для синхронізації passkey. Два з трьох методів (Silver і Golden Pass-ta-key), за даними дослідників, забезпечують повторний доступ із середовища зловмисника після початкової компрометації — це перетворює разовий інцидент на стійкий канал доступу до облікових записів жертви.
Важливо враховувати контекст: усі техніки вимагають попереднього виконання коду на пристрої. Це не віддалена атака на passkey як технологію, а розширення можливостей зловмисника, який уже закріпився в системі. Втім, для організацій, що розглядають passkey як заміну паролям із підвищеною стійкістю до компрометації, ці знахідки демонструють, що постексплуатаційний ландшафт складніший, ніж припускалося.
Рекомендації
Для операторів вебсервісів (relying party):
- Встановити параметр userVerification у значення required і перевіряти наявність UV-біта в повернутому ствердженні — це єдиний захід, повністю контрольований на стороні сервісу й такий, що блокує перший вектор атаки.
- Не покладатися виключно на налаштування запиту — перевіряти фактичну відповідь аутентифікатора.
Для постачальників облікових даних (credential providers):
- Перевіряти апаратну атестацію під час реєстрації нових ключів верифікації.
- Посилити перевірки під час повторної реєстрації та відновлення пристроїв.
- Обмежити доступ до локального стану passkey та унеможливити потрапляння майстер-секретів у логи та доступну пам’ять.
Для кінцевих користувачів:
- Забезпечити захист кінцевих точок від шкідливого ПЗ — це обов’язкова умова для всіх трьох атак.
- У разі підозри на компрометацію пристрою — змінити PIN-код Google Password Manager і розглянути видалення даних менеджера паролів, хоча ефективність цих заходів щодо вже вилученого SDS не підтверджена документацією Google.
Дослідження Unit 42 виявляє системну проблему: безпека passkey залежить не лише від криптографії, а й від усієї ланки — від зберігання ключів на пристрої до серверної валідації. Поки Google не опублікує офіційну відповідь з підтвердженням статусу виправлень і механізму ротації SDS, організаціям слід принаймні переконатися, що їхні вебсервіси суворо перевіряють UV-прапорець, а користувачам — підтримувати актуальну версію Chrome та контролювати захист кінцевих точок.
