Badacze bezpieczeństwa odkryli trzy techniki ataku, które mogą pozwolić złośliwemu oprogramowaniu na zaatakowanym komputerze z Windows na ciche uzyskanie dostępu do kont chronionych kluczami zapisywanymi w Google Password Manager, potencjalnie omijając weryfikację za pomocą odcisku palca, rozpoznawania twarzy lub PIN-u, której użytkownicy oczekują przy logowaniu bezhasłowym.
Ataki celują w szerszą infrastrukturę wokół zsynchronizowanych kluczy, zamiast łamać samą kryptografię klucza publicznego. Wykorzystują sposób, w jaki Google Chrome przechowuje dane poświadczeń urządzenia, komunikuje się z chmurowym autoryzatorem Google, ponownie rejestruje urządzenia i obsługuje główny sekret używany do szyfrowania zsynchronizowanych kluczy.
Badacze z Unit 42 w Palo Alto Networks nazwali te techniki „Pass-ta-key”, „Silver Pass-ta-key” i „Golden Pass-ta-key”. Każdy z nich reprezentuje coraz poważniejszą formę dostępu po naruszeniu bezpieczeństwa, począwszy od cichego generowania prawidłowej odpowiedzi logowania na komputerze ofiary, aż po wydobywanie prywatnych kluczy passkey do użycia na systemach kontrolowanych przez atakującego. Najpoważniejszy atak mógłby ujawnić 32-bajtowy Sekretny Klucz Domeny Bezpieczeństwa, czyli SDS, który chroni zaszyfrowane prywatne klucze związane z zsynchronizowanymi passkey Google’a. Unit 42 stwierdził, że posiadanie tego sekretu mogłoby pozwolić atakującemu na odszyfrowanie istniejących danych uwierzytelniających — a potencjalnie także passkey utworzonych w przyszłości — bez utrzymywania dostępu do oryginalnego komputera. Badania Unit 42 opisują SDS jako główny klucz kryptograficzny będący w centrum architektury synchronizacji Google’a.
Odkrycia nie oznaczają, że atakujący mogą zdalnie włamać się na dowolne konto chronione kluczem dostępu. Każda z zaprezentowanych dróg zaczyna się od tego, że złośliwe oprogramowanie już działa na komputerze ofiary z systemem Windows, a badania skupiały się konkretnie na Chrome, Google Password Manager i systemach wyposażonych w Trusted Platform Module.
Nie ma też żadnych wskazówek, że techniki te były wykorzystywane w rzeczywistych atakach. Unit 42 nie powiązał ich z żadną znaną grupą zagrożeniową ani rodziną malware, a badacze nie opublikowali identyfikatorów CVE ani pełnej listy wersji Chrome, które mogą być podatne.
Nie zmienia to jednak faktu, że praca podkreśla ważną zmianę w świecie bezpieczeństwa bez haseł: klucze dostępu mogą eliminować phishing i ponowne używanie haseł, ale zsynchronizowane implementacje nadal zależą od lokalnego oprogramowania, systemów odzyskiwania w chmurze oraz procesów rejestracji urządzeń, które same w sobie mogą stać się celem.
Klucze dostępu zastępują hasła parą kluczy kryptograficznych asymetrycznych. Strona internetowa przechowuje klucz publiczny, podczas gdy odpowiadający mu klucz prywatny jest kontrolowany przez autoryzator. Podczas logowania serwis wysyła jednorazowe wyzwanie, które musi zostać podpisane kluczem prywatnym.
Ponieważ klucz prywatny nie jest wpisywany na stronie ani przesyłany jako wielokrotnego użytku sekret, tradycyjne strony wyłudzające dane logowania nie mogą go po prostu przechwycić. Klucz dostępu jest też powiązany z identyfikatorem strony polegającej, co uniemożliwia użycie poświadczeń stworzonych dla jednej legalnej domeny na stronie imitującej.
Specyfikacja W3C Web Authentication definiuje ceremonie rejestracji i uwierzytelniania używane do tworzenia i używania tych poświadczeń. Zakłada ona, że prywatne klucze poświadczeń pozostają pod kontrolą autoryzatora i nie są udostępniane innym stronom.
Zsynchronizowane klucze dostępu zwiększają wygodę, ponieważ pozwalają na korzystanie z poświadczenia na kilku autoryzowanych urządzeniach. Wymaga to jednak dodatkowego systemu zabezpieczeń wokół klucza prywatnego. Poświadczenie musi być zaszyfrowane, zsynchronizowane, odzyskane i udostępnione przy logowaniu na nowym urządzeniu.
To właśnie ten otaczający system — a nie algorytm podpisu czy powiązanie domeny w WebAuthn — jest celem ataków Unit 42.
Na obsługiwanym komputerze z systemem Windows, Chrome rejestruje maszynę w chmurze uwierzytelniającej Google i generuje dwie pary kluczy wspierane sprzętowo.
Pierwszy to klucz tożsamości urządzenia, który pokazuje, że żądanie pochodzi z zarejestrowanego komputera. Drugi to klucz weryfikacji użytkownika powiązany z Windows Hello, który ma wskazywać, że użytkownik odblokował urządzenie przy użyciu kodu PIN lub sprawdzenia biometrycznego.
Chrome rejestruje publiczne części tych kluczy w usłudze w chmurze. System Google następnie tworzy domenę bezpieczeństwa dla konta i tworzy lub odzyskuje SDS używany do szyfrowania prywatnych kluczy należących do zsynchronizowanych kluczy dostępu.
Według wcześniejszej analizy technicznej przeprowadzonej przez Unit 42 dotyczącej uwierzytelniania w chmurze Google, Chrome przechowuje wynikowe informacje o rejestracji w pliku passkey_enclave_state w profilu przeglądarki. Zawiera to opakowany klucz tożsamości urządzenia, publiczne informacje klucza weryfikacji użytkownika, opakowaną kopię SDS oraz informacje wspierające odzyskiwanie PIN-u Menedżera Haseł Google.
Usługa cloud Google’a przechowuje też klucz opakowujący przypisany do konkretnego urządzenia. Podczas normalnej operacji passkey, usługa używa tego klucza, żeby odzyskać SDS, a potem używa SDS do odszyfrowania potrzebnego prywatnego klucza passkey.
W efekcie prywatny klucz może pozostać zaszyfrowany podczas synchronizacji między urządzeniami, a PIN użytkownika w Google Password Manager daje możliwość przywrócenia dostępu na nowym urządzeniu w tym samym środowisku bezpieczeństwa.
Ten hybrydowy projekt próbuje połączyć synchronizację w chmurze z ochroną zależną od urządzenia. Badania Unit 42 pokazują, że słabości w granicach między tymi warstwami mogą podważyć właściwości bezpieczeństwa, które użytkownicy kojarzą z passkey.
Zanim spróbuje się przejąć konto, malware musi najpierw sprawdzić, które klucze dostępu są dostępne.
Chrome przechowuje zsynchronizowane rekordy poświadczeń WebAuthn w bazie danych LevelDB w lokalnym profilu Chrome użytkownika. Unit 42 podkreślił, że proces działający z tymi samymi uprawnieniami co zalogowany użytkownik Windows może przeglądać te rekordy bez dostępu administratora.
Przechowywane informacje nie ujawniają od razu użytecznych kluczy prywatnych w postaci jawnej. Mogą jednak ujawnić wystarczająco dużo metadanych, żeby odwzorować ślad kluczy ofiary, w tym identyfikatory strony korzystającej, nazwy użytkowników, identyfikatory poświadczeń i zaszyfrowany materiał klucza.
Taki rekonesans może powiedzieć atakującemu, że ofiara ma klucz dostępu np. do giełdy kryptowalut, platformy deweloperskiej, sklepu internetowego, firmowego dostawcy tożsamości lub innej cennej usługi.
Pokazuje to również szersze ograniczenie bezpieczeństwa punktów końcowych. Szyfrowanie może chronić sam klucz prywatny, ale otaczające metadane mogą nadal pomóc złośliwemu oprogramowaniu w priorytetyzowaniu celów i zebrania informacji potrzebnych do późniejszych prób uwierzytelnienia.
Pierwsza technika celuje w sprzętowy klucz tożsamości używany przez Chrome do udowodnienia, że żądanie pochodzi z zarejestrowanego urządzenia.
Chrome tworzy klucz tożsamości za pomocą Windows Cryptography API: Next Generation, czyli CNG, korzystając z TPM komputera. Zamiast przechowywać klucz pod konwencjonalną nazwą, Chrome eksportuje go jako nieprzejrzysty obiekt klucza owinięty przez TPM i ładuje go ponownie, gdy klucz jest potrzebny.
Klucz prywatny nie jest ujawniany w postaci jawnej, a owinięty obiekt zwykle nie może być użyty na innym TPM. Ochrona jest więc skuteczna przeciwko prostemu kopiowaniu obiektu na inny komputer.
Jednak złośliwe oprogramowanie już działające na uprawnionym komputerze nie musi usuwać klucza prywatnego z TPM. Jednostka 42 odkryła, że można pobrać owinięty obiekt, zaimportować go przez standardowe interfejsy kryptograficzne Windows i poprosić oryginalny TPM o podpisanie danych dostarczonych przez atakującego.
Ponieważ warunki dostępu Chrome nie wymagają wyskakującego okienka Windows Hello dla klucza tożsamości, podobno operacja może się odbyć na zwykłym koncie użytkownika bez pokazywania odcisku palca, PIN-u czy prośby o zatwierdzenie.
Atakujący może zainicjować logowanie przy użyciu passkey, otrzymać nowe wyzwanie z docelowej strony internetowej i komunikować się z chmurowym uwierzytelniającym Google. Złośliwe oprogramowanie na komputerze ofiary używa następnie prawidłowego TPM, aby podpisać informacje wymagane przez usługę w chmurze.
Chmurowy uwierzytelniacz rozpoznaje podpis jako pochodzący z zarejestrowanego urządzenia i zwraca kryptograficznie poprawne potwierdzenie WebAuthn.
Jest jednak istotne ograniczenie. Ponieważ atak używa klucza tożsamości, a nie klucza weryfikacji użytkownika, flaga „User Verified” w potwierdzeniu nie jest ustawiona. Strona internetowa, która jest poprawnie zaimplementowana i wymaga uwierzytelnienia zweryfikowanego użytkownika, powinna go odrzucić.
WebAuthn rozróżnia między dowodem, że uwierzytelniający brał udział w ceremonii, a dowodem, że użytkownik został zweryfikowany lokalnie.
To drugie jest reprezentowane przez bit UV w danych uwierzytelniającego. Wartość jeden oznacza, że uwierzytelniający zweryfikował użytkownika za pomocą zatwierdzonej metody, takiej jak Windows Hello, PIN urządzenia lub rozpoznawanie biometryczne.
Strona polegająca może żądać userVerification: „required”, ale serwer musi też sprawdzić zwrócone dane uwierzytelniającego i potwierdzić, że bit UV jest ustawiony. Samo wpisanie „required” w żądaniu przeglądarki nie zastępuje walidacji po stronie serwera.
Wskazówki dla deweloperów WebAuthn od Google zalecają, aby strony polegające sprawdzały zarówno flagi obecności użytkownika, jak i weryfikacji użytkownika. Zauważają, że userVerification: „preferred” może poprawnie zwrócić asercję z UV ustawionym na false, podczas gdy serwisy wymagające silnej lokalnej weryfikacji powinny użyć „required” i upewnić się, że serwer potwierdza wynik.
Jednostka 42 przetestowała pierwszy atak na GitHub i eBay. GitHub odrzucił twierdzenie, ponieważ nie przeprowadzono weryfikacji użytkownika. Podobno eBay wymagał wymaganej weryfikacji, ale w czasie testów nie poprawnie sprawdził zwrócony bit i zaakceptował logowanie.
Jednostka 42 ujawniła problem eBayowi, który poprawił lukę w weryfikacji przed publikacją, według badaczy.
Porównanie pokazuje, dlaczego bezpieczeństwo kluczy dostępu jest współdzielone między różnymi komponentami. Chmura uwierzytelniająca może zwrócić technicznie poprawne informacje, ale strona internetowa nadal musi wymuszać właściwości uwierzytelniania, o które sama prosiła.
Drugi atak próbuje obejść weryfikację UV, zastępując sam klucz weryfikacyjny.
Unit 42 odkrył, że proces dodawania urządzenia w Chrome niekoniecznie kończy się podczas pierwszej operacji passkey na komputerze z Windows. Przeglądarka może wejść w stan przejściowy, w którym urządzenie zostało zarejestrowane, ale tworzenie klucza weryfikacyjnego wspieranego sprzętowo jest nadal odroczone.
Badacze twierdzą, że malware może manipulować lokalnym stanem rejestracji i spowodować, że Chrome zarejestruje urządzenie ponownie. W tym czasie atakujący dostarcza nowo wygenerowany klucz weryfikacyjny, nad którym ma kontrolę.
Według raportu, chmurowy autentyfikator Google zaakceptował zamienny klucz, nie sprawdzając, czy pochodził on z odpowiednio chronionego sprzętowego autentyfikatora. Po zarejestrowaniu, żądania podpisane kluczem atakującego były traktowane tak, jakby ofiara przeszła weryfikację Windows Hello.
Twierdzenia uzyskane tą drogą mają flagę UV. W efekcie poprawnie skonfigurowane strony, które odrzuciły pierwszą technikę Pass-ta-key, mogłyby zaakceptować silniejszy atak Silver, ponieważ sam uwierzytelniający w chmurze stwierdza, że weryfikacja użytkownika miała miejsce.
Atakujący nie potrzebowałby już komputera ofiary przy każdym kolejnym logowaniu. Po zarejestrowaniu klucza zastępczego, uwierzytelnianie mogłoby być przeprowadzane z infrastruktury kontrolowanej przez atakującego.
To zmienia tymczasowe zakażenie punktu końcowego w wielokrotne logowanie do konta i sprawia, że technika jest bardziej istotna niż ciche pośrednictwo pojedynczego logowania z zainfekowanego urządzenia.
Unit 42 zaleca, aby dostawcy poświadczeń weryfikowali pochodzenie i świadectwa nowo zarejestrowanych kluczy tożsamości i weryfikacji. Ponowna rejestracja powinna również wymagać dodatkowego potwierdzenia, zamiast polegać wyłącznie na stanie, który złośliwe oprogramowanie uruchomione przez użytkownika może usunąć lub zmodyfikować.
Trzecia i najbardziej poważna technika atakuje SDS bezpośrednio.
Jednostka 42 początkowo odkryła, że Chrome ujawniał sekret w postaci czystego tekstu przez logi diagnostyczne FIDO podczas rejestracji w chmurze. Google usunęło to ujawnienie po zgłoszeniu przez badaczy.
Badacze stwierdzili jednak, że problem architektoniczny pozostał, ponieważ SDS nadal był przekazywany do Chrome i tymczasowo istniał w pamięci procesu przeglądarki podczas odzyskiwania urządzenia lub ponownej rejestracji.
Rzekomo złośliwe oprogramowanie może zmusić Chrome do przejścia przez nową sekwencję startową, monitorować zmiany w pliku passkey_enclave_state i przechwytywać pamięć przeglądarki, gdy sekret jest obecny. Następnie może przeszukać przechwycone dane w poszukiwaniu oczekiwanego, 32-bajtowego SDS.
Połączenie tego głównego sekretu z zaszyfrowanymi rekordami WebAuthn z bazy synchronizacji Chrome pozwoliłoby atakującemu odzyskać klucze prywatne powiązane z zsynchronizowanymi kluczami dostępu ofiary.
W tym momencie atakujący nie potrzebuje już chmurowego uwierzytelniania Google, oryginalnego TPM ani dalszego dostępu do zainfekowanego urządzenia. Wyodrębnione klucze prywatne mogą być użyte przez uwierzytelnianie kontrolowane przez atakującego do odpowiadania na wyzwania z odpowiadających im stron internetowych.
Unit 42 pokazał tę technikę, używając odzyskanego materiału do uwierzytelnienia się na giełdzie kryptowalut.
Badacze dodatkowo ostrzegli, że obecny projekt Google używa tego samego SDS do ochrony poświadczeń w całym obszarze bezpieczeństwa. W ich raporcie stwierdzono, że nie ma ujawnionego mechanizmu rotacji ani unieważniania tego sekretu, co stwarza możliwość, że atakujący, który go zdobył, w przyszłości może odszyfrować poświadczenia synchronizowane pod tym samym kluczem głównym.
To twierdzenie o trwałości jest szczególnie poważne, ale obecnie opiera się na analizie Unit 42. Publiczna dokumentacja Google’a nie wyjaśnia cyklu życia SDS w wystarczających szczegółach, żeby użytkownicy czy administratorzy mogli stwierdzić, czy zmiana PIN-u Menedżera Haseł zastępuje podstawowy sekret główny.
Google pozwala użytkownikom komputerów na zmianę PIN-u Menedżera Haseł Google, otwierając ustawienia menedżera haseł w Chrome i ponownie się uwierzytelniając. Firma twierdzi, że PIN pomaga użytkownikom w dostępie do kluczy dostępu na nowych urządzeniach, chroni zaszyfrowane dane przed Google i weryfikuje użytkownika podczas operacji z kluczami dostępu. Dokumentacja wsparcia Google nie mówi, że zmiana PIN-u powoduje rotację SDS.
Użytkownicy mogą również usuwać pojedyncze klucze dostępu lub usuwać wszystkie dane Menedżera Haseł Google. Jednak Google publicznie nie udokumentowało procesu unieważniania specyficznego dla SDS ani nie wyjaśniło, czy usunięcie zapisanych kluczy dostępu unieważnia materiał klucza prywatnego już wyekstrahowany przez atakującego.
Usunięcie klucza dostępu u podmiotu polegającego pozostaje ważne, ponieważ strona internetowa może unieważnić powiązany zapis publicznego poświadczenia. Po jego usunięciu z konta podpisy tworzone skradzionym kluczem prywatnym nie powinny być już akceptowane.
W przypadku podejrzenia naruszenia bezpieczeństwa, unieważnienie po stronie korzystającego jest prawdopodobnie bardziej niezawodne niż zakładanie, że samo zmienienie PIN-u w Menedżerze Haseł unieważnia ujawnione materiały kryptograficzne.
Badanie opisuje techniki po naruszeniu bezpieczeństwa, a nie początkową metodę infekcji. Aby atakujący mogli rozpocząć działanie, musieliby najpierw uruchomić złośliwe oprogramowanie w sesji Windows ofiary przez inny kanał, na przykład phishing, złośliwe pobrania, luki w oprogramowaniu lub kompromitację łańcucha dostaw.
Ten warunek w znacznym stopniu ogranicza atak, ale nie sprawia, że wnioski są bez znaczenia. Złośliwe oprogramowanie kradnące dane logowania już działa z uprawnieniami zwykłego użytkownika i rutynowo wyciąga ciasteczka przeglądarki, hasła, tokeny i dane portfeli kryptowalutowych.
Oczekiwano, że klucze logowania (passkeys) ograniczą znaczenie kradzieży danych logowania z urządzeń końcowych, ponieważ nie ma żadnego hasła do ponownego użycia, które można by ukraść. Prace Unit 42 sugerują, że atakujący mogliby się dostosować, celując w klucze identyfikacyjne urządzenia, stan rejestracji i tajne dane synchronizacji.
Nie przedstawiono żadnych dowodów na to, że kradzieże informacji o towarach obecnie wykorzystują te konkretne metody. Opracowanie niezawodnych wersji wymagałoby też szczegółowej wiedzy o strukturach danych Chrome’a, protokole chmury Google i czasie operacji rejestracji.
Potencjalna nagroda jest jednak spora. Pomyślna implementacja mogłaby dać twórcom złośliwego oprogramowania sposób na zarabianie na passkeyach poprzez ponowne użycie dostępu do konta lub odsprzedaż wyciągniętych prywatnych kluczy.
Organizacje prowadzące strony internetowe z uwierzytelnianiem za pomocą passkey powinny przyjrzeć się działaniu po stronie serwera swoich implementacji WebAuthn. Usługi wrażliwe powinny używać userVerification: „required” i odrzucać każdą odpowiedź, w której bit UV nie jest ustawiony.
Deweloperzy nie powinni zakładać, że przeglądarka lub urządzenie uwierzytelniające automatycznie wymuszają politykę zamierzoną przez stronę zależną. Weryfikacja musi odbywać się po sparsowaniu podpisanych danych uwierzytelniających po stronie serwera.
Dostawcy poświadczeń powinni wymagać poświadczenia lub równoważnego dowodu kryptograficznego przy rejestrowaniu lub wymianie kluczy tożsamości i weryfikacji użytkownika. Odzyskiwanie i ponowna rejestracja powinny być traktowane jako operacje uprzywilejowane, z dodatkowymi weryfikacjami i powiadomieniami dla istniejących zaufanych urządzeń.
Obrońcy punktów końcowych mogą monitorować nieoczekiwane usunięcie lub zmianę stanu kluczy Chrome, podejrzany dostęp do jego bazy danych synchronizacji, nietypowe zbieranie pamięci przeglądarki oraz nietypowe procesy wywołujące operacje podpisywania CNG oparte na TPM.
Firmy powinny również rozważyć użycie sprzętowych kluczy bezpieczeństwa powiązanych z urządzeniem dla administratorów, programistów, pracowników finansowych i innych użytkowników o wysokim ryzyku. Synchronizowane klucze zapewniają dużą wygodę, ale wrażliwe konta mogą zyskać dzięki poświadczeniom, które nie mogą być eksportowane ani odzyskiwane przez chmurę synchronizacyjną.
Użytkownicy, którzy podejrzewają infekcję, powinni odizolować i odbudować dotknięty punkt końcowy, sprawdzić urządzenia i sesje zalogowane na konto Google, usunąć nieznane urządzenia i unieważnić dotknięte klucze bezpośrednio z każdego ważnego konta. Powinni też utworzyć nowe poświadczenia z systemu, który jest znany jako czysty.
Wyniki nie podważają bezpieczeństwa passkeyów. Nadal są bardzo odporne na phishing, ataki typu credential stuffing, password spraying i wycieki baz danych, a ich kryptograficzna konstrukcja zapobiega ujawnieniu powtarzalnego hasła przez skompromitowaną stronę internetową.
Badania pokazują jednak, że powierzchnia ataku się przesuwa.
Gdy dostawcy uwierzytelniania synchronizują dane logowania między urządzeniami, muszą tworzyć systemy odzyskiwania, onboardingu i zarządzania kluczami w chmurze w oparciu o podstawowy protokół WebAuthn. Te systemy mogą wprowadzać z powrotem formy przenośnego zaufania, których urządzeniom przypisane passkeye miały unikać.
Główna lekcja jest taka, że bezpieczeństwo kluczy dostępu zależy od całego łańcucha: punktu końcowego, kluczy wspieranych sprzętowo, implementacji w przeglądarce, uwierzytelniania w chmurze, procedury odzyskiwania i strony internetowej, która sprawdza końcowe potwierdzenie.
Jeśli któraś warstwa myli posiadanie urządzenia z weryfikacją użytkownika, akceptuje niezatwierdzony klucz zastępczy albo ujawnia główny sekret w skompromitowanym oprogramowaniu, sama silna kryptografia nie zapewni oczekiwanego poziomu bezpieczeństwa.
