Pass-ta-key: malware może przejąć synchronizowane passkeys Google

Passkeys miały usunąć z procesu logowania hasło, które można wyłudzić. Badacze Palo Alto Networks Unit 42 pokazali jednak, że malware działające już na komputerze z Windows może zaatakować implementację synchronizacji Google Password Managera. Rodzina technik nazwana Pass-ta-key nie łamie kryptografii FIDO i nie pozwala napastnikowi zdalnie „zgadnąć” klucza. Wykorzystuje zaufanie, jakie chmurowy magazyn passkeys i serwis docelowy przypisują zainfekowanemu urządzeniu.

To ważne rozróżnienie. Passkeys nadal chronią lepiej niż hasła przed klasycznym phishingiem, ale nie są tarczą przeciwko kompromitacji endpointu. Dla firm wniosek brzmi: odporne uwierzytelnianie trzeba połączyć z kontrolą urządzenia, poprawną walidacją user verification i planem odzyskania konta.

Trzy warianty tego samego problemu

Analiza Unit 42 opisuje testy Chrome na Windows z kluczami chronionymi przez TPM. Wszystkie scenariusze wymagają wykonania złośliwego kodu na urządzeniu użytkownika.

Pass-ta-key używa tożsamości urządzenia opartej na TPM do zażądania poprawnego podpisu dla istniejącej passkey. Badacze uzyskali asercję bez okna zgody, biometrii, PIN-u Windows Hello i uprawnień administratora. Asercja miała jednak flagę user verified ustawioną na fałsz. GitHub odrzucił ją, ponieważ sprawdzał tę właściwość; eBay początkowo zaakceptował logowanie, po czym poprawił walidację po zgłoszeniu.

Silver Pass-ta-key wymusza ponowną rejestrację urządzenia w domenie bezpieczeństwa Google. W jej trakcie napastnik może dodać kontrolowany przez siebie klucz weryfikacji użytkownika. Zdaniem badaczy usługa chmurowa nie sprawdzała, czy taki klucz rzeczywiście pochodzi z odpowiedniego mechanizmu sprzętowego. Efektem mogło być zatwierdzanie logowań również na innym urządzeniu.

Golden Pass-ta-key celuje w Security Domain Secret, czyli sekret służący do ochrony synchronizowanych kluczy prywatnych. Google usunęło wcześniejsze zapisywanie wrażliwych danych FIDO do logów, lecz podczas legalnego użycia sekret nadal pojawia się na krótko w pamięci procesu Chrome. Malware z dostępem do procesu może próbować go wydobyć, a następnie odszyfrować materiał kluczowy. Unit 42 zwraca też uwagę, że użytkownik nie ma dziś prostego mechanizmu rotacji całej domeny bezpieczeństwa podobnego do zmiany hasła.

Kto jest narażony

Opisane testy dotyczą konkretnej kombinacji: Google Password Manager, Chrome, Windows i synchronizowane passkeys. Nie oznacza to automatycznie podatności każdego menedżera, systemu operacyjnego lub tokena sprzętowego. Nie każdy serwis docelowy jest też równie podatny — przypadek GitHuba pokazuje, że prawidłowa walidacja właściwości asercji zatrzymuje pierwszy wariant.

Ryzyko jest największe, gdy:

• pracownik może uruchamiać niezatwierdzony kod, skrypty lub „narzędzia pomocnicze”;
• EDR nie chroni procesu przeglądarki i nie widzi prób odczytu jego pamięci;
• serwis akceptuje asercję bez wymaganej flagi weryfikacji użytkownika;
• odzyskanie konta i rejestracja nowego urządzenia są słabiej chronione niż samo logowanie;
• zespół zakłada, że wdrożenie passkeys kończy temat bezpieczeństwa tożsamości.

Co zrobić teraz

Dla użytkownika pierwszym krokiem jest aktualizacja Chrome i Windows oraz potraktowanie każdego podejrzenia malware jako kompromitacji sesji, passkeys i innych sekretów dostępnych na urządzeniu. Samo wyczyszczenie przeglądarki nie daje pewności. Potrzebne są izolacja hosta, analiza, unieważnienie sesji, przegląd zarejestrowanych urządzeń i bezpieczne ponowne ustanowienie uwierzytelniania z czystego systemu.

Zespoły tworzące usługi powinny wymagać właściwego poziomu user verification i testować negatywne warianty WebAuthn: nie tylko poprawny podpis, lecz także oczekiwane rpId, origin, challenge, licznik oraz flagi UV/UP. Procedury rejestracji i odzyskania urządzenia muszą wymagać co najmniej tak samo silnego dowodu jak codzienne logowanie.

Administratorzy mogą ograniczyć ryzyko przez allowlisting aplikacji, ochronę przeglądarek w EDR, odebranie lokalnego administratora, telemetrię rejestracji nowych urządzeń i alerty na nietypowe odzyskiwanie kont. Passkeys dla kont uprzywilejowanych warto oprzeć na kluczach sprzętowych bez synchronizacji, jeśli model ryzyka to uzasadnia.

Więcej o poprawnym wdrożeniu opisujemy w przewodniku passkeys i logowanie bez haseł oraz w materiale o kradzieży sesji przez infostealery.

Fakty źródłowe a wnioski Breachroad

Unit 42 potwierdza trzy scenariusze laboratoryjne, ich warunek wstępny — malware na urządzeniu — oraz odpowiedzialne zgłoszenie ustaleń Google i badanym serwisom. Google i eBay wprowadziły opisane przez badaczy zmiany. BleepingComputer opublikował niezależne omówienie odkrycia.

Wnioskiem Breachroad jest traktowanie synchronizowanej passkey jako sekretu zależnego od kondycji endpointu i procesu odzyskania, a nie jako izolowanego zamiennika hasła. Szkolenia z cyberbezpieczeństwa i phishingu pomagają użytkownikom rozpoznawać drogę do infekcji, a audyt bezpieczeństwa IT może sprawdzić polityki WebAuthn, urządzenia i reakcję na przejęcie tożsamości.