Зловреден софтуер, работещ с правата на обикновен потребител на операционна система Windows, може да се впише в защитените с passkey профили на жертвата без необходимост от пръстов отпечатък, ПИН код или каквото и да е известие на екрана на потребителя.

Екипът на Unit 42 детайлизира три пътя за атака срещу облачния инструмент за удостоверяване на Google Password Manager в Chrome, наречени съответно „Pass-ta-key“, „Silver Pass-ta-key“ и „Golden Pass-ta-key“. Най-опасният от тях е насочен към главния ключ (master key), който защитава синхронизираните passkeys на потребителя.

Никоя от тези атаки не компрометира самата криптография. Те са насочени към софтуерния код около технологията passkey: начина, по който Chrome съхранява своите ключове за устройството, как регистрира повторно устройство, след като това състояние изчезне, и дали уебсайтът, в който се вписвате, изобщо проверява дали е извършена проверка на реалния потребител.

Атаките могат скрито да придобият валидно твърдение за удостоверяване (authentication assertion), да инсталират контролиран от атакуващия ключ за проверка на потребителя или да извлекат 32-байтовата тайна на домена за сигурност (Security Domain Secret - SDS), използвана за декриптиране на синхронизираните частни ключове за passkey.

Изследователите споделят, че последните два пътя могат да осигурят възможност за многократен достъп от собствената среда на атакуващия след първоначалното компрометиране на крайната точка. Докладът не описва реално използване на тези атаки (exploitation in the wild) и не предоставя идентификатори на CVE уязвимости, засегнати версии на Chrome или пълна информация за отстраняване на уязвимостта.

При търсене в Националната база данни за уязвимости (NVD) към 3 август 2026 г. не бе открито съответствие за CVE с трите посочени техники.

Проучването е ограничено до Google Password Manager в Chrome на Windows системи, оборудвани с доверен платформен модул (TPM), като всеки път на атака започва със зловреден софтуер, който вече е стартиран на устройството на жертвата.

Изходният код на Chromium към 3 август потвърждава части от архитектурата, но това не доказва, че последната стабилна версия на Chrome остава уязвима. Това са техники за след-компрометиране (post-compromise). Те описват до какво може да достигне атакуващият на вече компрометирана машина, а не как е компрометирана самата машина.

Атаката започва с локално разузнаване. Chrome съхранява синхронизираните записи на идентификационни данни в директорията %LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB. Изследователите твърдят, че процес без администраторски права може да прочете достатъчно метаданни, за да идентифицира уебсайтовете и потребителските имена, свързани с passkeys на жертвата, заедно с идентификаторите на данните и шифрованите частни ключове.

Първата техника, наречена „Pass-ta-key“, извлича обвития идентификационен ключ на Chrome за устройството и изисква от същия TPM да подпише контролирана от атакуващия заявка чрез повиквания към Windows Cryptography API: Next Generation (CNG).

Текущият изходен код на Chromium показва защо този блок с данни (blob) е многократно използваем: Chrome създава TPM ключа без име, което според коментар в кода предотвратява неговото записване на диска. Chrome след това експортира ключа като непрозрачен блок с данни и го презарежда по-късно под флаг, който потиска всякакви подкани към потребителя. Бележка тип TODO в същия файл сочи към проблем в Chromium с номер 398125799, предлагащ тези ключове вместо това да бъдат именувани.

Google Cloud Authenticator връща валидно твърдение, като единствената разлика спрямо твърдение, генерирано след реална проверка на потребителя, е един бит – флагът за потвърден потребител (User Verified - UV), който остава незададен. Текущата спецификация за уеб удостоверяване (Web Authentication) изисква приемащата страна, която е задала изискване за проверка на потребителя (userVerification) като задължително (required), да прекрати процедурата, ако този бит липсва.

Изследователите посочват, че GitHub прилага тази проверка изключително стриктно, докато eBay е приемал тяхното тестово твърдение, докато компанията не коригира уязвимостта във валидирането след разкриването на информацията. От трите пътя за атака, този зависи изцяло от проверката, контролирана от уебсайта, така че даден сайт може да отхвърли заявката независимо от поведението на облачната услуга – и от двата посочени примера от Unit 42, един е бил уязвим.

„Silver Pass-ta-key“ е насочена към следващото ниво. Зловредният софтуер принуждава Chrome да регистрира повторно устройството. Chrome не създава своя ключ за проверка на потребителя веднага и в този времеви прозорец атакуващият може да регистрира свой собствен ключ.

От Unit 42 заявяват, че услугата не проверява дали новорегистрираният ключ идва от защитен хардуер. Твърденията, подписани с този ключ, носят флага UV, което според изследователите позволява последващи влизания без наличието на устройството на жертвата. Текущият изходен код на Chromium независимо потвърждава, че новорегистрираните устройства могат да запазят състояние на отложена регистрация (deferred_uv_key_creation), но само публичният код не потвърждава докладваната атака с подмяна на ключове на сървърно ниво спрямо последната стабилна версия на Chrome.

Публикуваната информация не уточнява дали производствената услуга вече извършва хардуерно удостоверяване преди приемането на заместващ ключ – мярка, която Unit 42 препоръчва за ограничаване на този път за атака.

„Golden Pass-ta-key“ е насочена към самата тайна на домена за сигурност (SDS). Unit 42 твърди, че зловредният софтуер може да предизвика повторна регистрация, да прочете тайната от паметта на процеса на Chrome, докато тя временно се намира там в некриптиран вид, и да я използва за възстановяване на синхронизираните частни ключове за passkey.

Текущият изходен код на Chromium потвърждава базовото излагане на риск: Chrome създава или получава 32-байтови тайни на домена за сигурност в структурите от данни на клиентския процес. Това доказва, че тайната попада в паметта на Chrome, въпреки че надеждното извличане, превземането на профили и персистентността при бъдещи промени на тайните остават твърдения на Unit 42 или са все още нерешени въпроси.

Изследователите споделят, че Google е премахнала предишно излагане на SDS от Chrome...