Pass-ta-key: малуер краде синхронизирани passkeys

Изследователите от Unit 42 на Palo Alto Networks публикуваха на 3 август 2026 г. три нови атаки срещу passkeys, синхронизирани през Google Password Manager. Наречени са Pass-ta-key, Silver Pass-ta-key и Golden Pass-ta-key, засягат Chrome върху Windows машини с TPM чип и позволяват на зловреден софтуер да влезе в чужд акаунт — без пръстов отпечатък, без PIN и без нищо да се появи на екрана на жертвата. Пълният технически разбор е в доклада на Unit 42.

Важното уточнение веднага: това не е пробив в криптографията на FIDO2/WebAuthn. И трите техники са post-compromise — изискват малуер, който вече работи на компютъра ви. Но не изискват администраторски права, а точно това ги прави неприятни.

Какво точно правят трите атаки

Pass-ta-key се захваща за файла passkey_enclave_state в профила на Chrome. В него стои обвитият (wrapped) частен ключ на устройството. Малуерът го изважда и през Windows CNG API — NCryptImportKey, NCryptSignHash и компания — кара TPM-а да подпише заявка на нападателя. Облачният автентикатор на Google връща валидна assertion. Уловката е, че флагът User Verified остава вдигнат в „не“, така че сайт, който проверява коректно, ще откаже влизането.

Silver Pass-ta-key заобикаля точно този проблем. Нападателят обезсилва съществуващия ключ за потребителска верификация, изчаква повторното записване на устройството и регистрира свой UV ключ. Google не проверява дали новият ключ идва от истински хардуер, така че оттам нататък влизането става и без устройството на жертвата.

Golden Pass-ta-key е най-тежката. Тя принуждава повторна регистрация и изчита 32-байтовия Security Domain Secret директно от паметта на процеса Chrome, докато той минава оттам в чист вид. Този SDS е главният ключ, с който са криптирани всички синхронизирани passkeys — с него нападателят разшифрова записите WebauthnCredentialSpecifics и се сдобива с частните ключове на целия набор.

Локалната база данни е отворена книга

Отделно от трите атаки, Unit 42 отбелязват нещо, което си струва да знаете: Chrome пази метаданните за синхронизираните passkeys в некриптирана LevelDB база в %LocalAppData%\Google\Chrome\User Data\<профил>\Sync Data\LevelDB. Тя се чете с обикновени потребителски права и дава на малуера готов списък с всички услуги, в които ползвате passkey — тоест карта накъде да атакува.

Реакцията на Google и сайтовете

Google е премахнала излагането на SDS в дневниците на Chrome (chrome://device-log/FIDO), заведено като Issue #464305542. Проблемът е, че секретът продължава да се изпраща към клиента и си остава достъпен в паметта на процеса — тоест Golden Pass-ta-key работи, само че вече без удобството на лог файл. Няма и механизъм за ротация на SDS, което значи, че веднъж изтекъл, той не може просто да бъде подменен.

По страна на сайтовете картината е смесена. Unit 42 са тествали eBay и GitHub: GitHub изисква и проверява потребителска верификация както трябва и издържа; eBay е бил уязвим и е поправил валидацията след разкриването. Към момента няма присвоени CVE идентификатори и Google не е публикувала цялостна поправка и за трите вектора — ситуация, която напомня на непълната поправка на N-able за N-central, където частичното запушване не спря атаките.

Какво следва от това за вас

Passkeys си остават значително по-добри от паролите — фишингът срещу тях не работи, а изтичане на база с хешове е без значение. Но тази изследване показва къде е границата: щом на машината ви върви малуер, синхронизираният passkey не е по-силен от процеса, който го пази. Кражбата на бисквитки за сесии и подхлъзването към фалшиви страници, каквото видяхме при атаките през хотелски Wi-Fi срещу Microsoft 365, сега получава ново попълнение.

Препоръките на Unit 42 към доставчиците са шест: стриктна проверка на флага за потребителска верификация; валидация на attestation при регистрация на нов ключ на устройство; втвърдяване на процедурите по възстановяване и повторна регистрация; главният ключ да не стига до клиентската среда; ограничаване на достъпа до локалните passkey данни; и по-добро засичане на необичайна употреба на passkeys.

Заключение

Pass-ta-key не отменя passkeys — тя показва, че сигурността им зависи не само от криптографията, а и от кода около нея: къде се пази ключът на устройството, какво се проверява при повторна регистрация и дали сайтът изобщо гледа дали е имало човек отсреща. За обикновения потребител изводът е познат и скучен, но верен: чистата машина си остава основата. За Google и за големите услуги топката е в тяхното поле — и част от нея все още не е ритната.