04.08.2026
1 хв
10
Ключі доступу поступово замінюють традиційні паролі, оскільки забезпечують кращий захист від фішингу. Їх не можна просто викрасти, перехопити або випадково розкрити під час введення. Водночас, якщо пристрій заражений шкідливим програмним забезпеченням, зловмисники можуть використовувати ключі доступу без введення PIN-коду, підтвердження за допомогою біометрії чи інших способів автентифікації, фактично обходячи багатофакторний захист.
Під час дослідження фахівці розробили три окремі сценарії захоплення облікового запису. Найнебезпечніший із них дозволив повністю отримати доступ до всіх синхронізованих ключів доступу жертви.
Втім, для успішної атаки є важлива умова: на пристрої вже має працювати шкідливе програмне забезпечення. Дослідники зазначають, що це часто досягається за допомогою масових автоматизованих фішингових кампаній, зокрема атак типу ClickFix.
«Зловмисник може захопити обліковий запис, захищений синхронізованим через Google ключем доступу, використовуючи шкідливе програмне забезпечення, яке працює на пристрої жертви. Для цього не потрібні підвищені привілеї, розблокування пристрою або будь-яка взаємодія з боку користувача», – попереджає Unit 42 у своєму новому звіті.
Може здатися, що шкідливе програмне забезпечення так само легко може викрасти всі паролі, які зберігаються на комп’ютері користувача. Однак у більшості випадків для входу до облікового запису все одно потрібно пройти другий етап автентифікації, наприклад підтвердити вхід через смартфон. Це означає, що зловмисник не отримує повного контролю над акаунтом одразу.
Із ключами доступу ситуація інша. Багато онлайн-сервісів довіряють Passkeys і не перевіряють, чи користувач справді пройшов другий етап автентифікації. У своєму дослідженні фахівці зосередилися на широко поширеній реалізації синхронізованих ключів доступу Google. Якщо на пристрої вже працює шкідливе програмне забезпечення, воно може отримати доступ до того, як використовуються ключі доступу в обліковому записі жертви.
«Chrome локально зберігає синхронізовані дані ключів доступу як частину процесу синхронізації», – пояснюють дослідники Unit 42.
При цьому доступ до цих записів не потребує підвищених привілеїв. У результаті зловмисник може побачити, на яких сервісах користувач використовує Passkeys, а також пов’язані імена користувачів, ідентифікатори облікових даних і зашифровані закриті ключі.
Самі ключі доступу Google генерує та зберігає в ізольованому хмарному середовищі, звідки вони ніколи не залишаються у відкритому вигляді. Для доступу до них пристрій використовує два апаратно захищені ключі, що зберігаються в модулі TPM або Secure Enclave.
Під час входу до сервісу біометрична автентифікація або PIN-код розблоковують перший ключ – User Verification (UV). Другий ключ – Identifier (ID) – підтверджує, що запит надходить саме з довіреного пристрою.
Після цього обидва ключі передаються до хмарного автентифікатора Google, який перевіряє їх і використовує відповідний ключ доступу для входу в обліковий запис.
Єдиний захист, який не дозволяє шкідливому програмному забезпеченню просто викрасти ці два ключі, полягає в тому, що вони зберігаються всередині чипа TPM і ніколи не залишають його у придатному для використання вигляді. Тому шкідливе ПЗ може лише надсилати TPM запити на підписування даних.
За словами дослідників, отримати ідентифікаційний ключ значно простіше. Шкідливе програмне забезпечення може згенерувати необхідний підпис, імітуючи роботу Chrome.
«Chrome створює умови, за яких може запитувати підпис від імені користувача без підвищених привілеїв і без спрацювання механізмів захисту, пов’язаних із розблокуванням пристрою», – зазначають дослідники.
У першому сценарії атаки, який отримав назву Pass-ta-key, дослідники взагалі не використовували ключ UV. Вони ініціювали вхід на одному з вебсервісів, отримали ідентифікаційний ключ і передали його до Google Cloud Authenticator. Виявилося, що одного лише підпису TPM було достатньо, щоб скомпрометувати обліковий запис.
«З погляду хмарного автентифікатора запит виглядає так, ніби його надіслав довірений пристрій, який виконує легітимний запит. У результаті сервіс формує дійсну відповідь для автентифікації, яка передається сторонньому сервісу, завершуючи процес входу та надаючи зловмиснику повний контроль над обліковим записом жертви», – йдеться у звіті.
Дослідники також з’ясували, що багато онлайн-сервісів, зокрема eBay, не перевіряли, чи користувач справді пройшов перевірку особи. Вони просто довіряли прапорцю User Verified (UV) зі значенням true, який шкідливе програмне забезпечення могло підробити. Після повідомлення про проблему eBay уже усунув цю вразливість.
«Ми виявили сторони, що довіряють, які приймали автентифікацію, оскільки вони не належним чином перевіряли UV-прапорець. Це дозволило атаці успішно завершитися, незважаючи на відсутність перевірки користувача».
Дослідники пішли ще далі й продемонстрували, що можна скомпрометувати також UV-ключ. Це відкриває можливість повного захоплення облікового запису навіть у сервісах, які застосовують суворіші механізми автентифікації.
Другий сценарій атаки ґрунтується на тому, щоб обманути Google Cloud Authenticator і змусити його повірити, що користувач успішно розблокував свій пристрій.
Замість того щоб отримувати справжній UV-підпис, шкідливе програмне забезпечення може змусити пристрій повторно зареєструватися в Google за допомогою команди device/forget. У результаті чинний UV-ключ стає недійсним.
Після цього шкідливе ПЗ створює новий UV-ключ, який Google Cloud Authenticator приймає та прив’язує до пристрою, не перевіряючи, чи був він підписаний справжнім апаратним модулем безпеки.
За словами дослідників, такий сценарій дає змогу отримати доступ навіть до особливо чутливих облікових записів, зокрема банківських сервісів і державних інформаційних систем.
Третій сценарій атаки виявився ще небезпечнішим. Він дозволяє зловмисникам викрасти та розшифрувати всі ключі доступу, синхронізовані через Google.
Для їхнього захисту Google використовує так званий головний ключ, відомий як Security Domain Secret (SDS). Прямого доступу до нього немає. На пристрої зберігається лише його зашифрована версія, а розшифрувати її може лише хмарна інфраструктура Google.
«Якщо зловмисник отримає SDS, він зможе розшифрувати всі синхронізовані ключі доступу, пов’язані з цим обліковим записом. Це дозволить йому проходити автентифікацію як повністю перевірений користувач і отримати доступ до всіх сервісів, де жертва використовує ключі доступу», – зазначають дослідники.
Найбільш несподіваним стало те, як саме фахівцям вдалося отримати SDS. Вони виявили, що секрет зберігався у журналах Chrome.
Фактично найважливіший секретний ключ опинився записаним у відкритому вигляді під час процесу реєстрації пристрою.
Після звіту Unit 42 компанія Google прибрала цей секрет із журналів Chrome. Водночас дослідники зазначають, що SDS і досі передається клієнту та тимчасово зберігається в пам’яті процесу Chrome під час процедури відновлення. Через це, на їхню думку, вразливість усе ще може бути використана для викрадення синхронізованих ключів доступу.
«Якщо зловмисник змусить жертву повторно зареєструватися в хмарному автентифікаторі та знатиме, який шаблон шукати, він зможе витягти SDS безпосередньо з пам’яті», – зазначають автори дослідження.
У своєму звіті фахівці рекомендують онлайн-сервісам більше не покладатися лише на прапорець User Verified (UV) та впровадити повноцінну перевірку того, що автентифікація користувача справді відбулася. Водночас Google, на їхню думку, має перевіряти справжність нових пристроїв і UV-ключів ще до їхньої реєстрації. Дослідники також радять посилити механізми реєстрації та відновлення ключів доступу й запропонували низку інших заходів для підвищення безпеки.
Попри те що Passkeys значно ускладнюють традиційні атаки, спрямовані на викрадення облікових записів, вони не усувають ризик повністю. Дослідники вважають, що зловмисники поступово переходитимуть до нових способів атак, орієнтованих саме на цю технологію.
«Головний висновок полягає в тому, що компрометація кінцевого пристрою залишається одним із ключових елементів сучасної моделі загроз», – підсумували автори дослідження.
