--- title: "Ataki na Google Password Manager mogą przejąć konta chronione passkeyami" description: "Badacze Unit 42 opisali trzy techniki ataku na Google Password Manager w Chrome, które mogą prowadzić do użycia lub przejęcia zsynchronizowanych passkeyów. Wszystkie wymagają wcześniejszego uruchomienia złośliwego oprogramowania na komputerze ofiary z systemem Windows." publisher: "Najnowsze Informacje" language: "pl-PL" canonical_url: "https://najnowsze-informacje.pl/cyberbezpieczenstwo/ataki-na-google-password-manager-moga-przejac-konta-chronione-passkeyami" markdown_url: "https://najnowsze-informacje.pl/cyberbezpieczenstwo/ataki-na-google-password-manager-moga-przejac-konta-chronione-passkeyami/index.md" date_published: "2026-08-05T12:26:46.516Z" date_modified: "2026-08-05T12:27:04.360Z" author: "Redakcja" category: "Cyberbezpieczeństwo" tags: - "cyberbezpieczeństwo" - "passkeys" - "chrome" - "google password manager" - "złośliwe oprogramowanie" source_url: "https://thehackernews.com/2026/08/google-password-manager-attacks-could.html" source_name: "The Hacker News" --- # Ataki na Google Password Manager mogą przejąć konta chronione passkeyami > Złośliwe oprogramowanie na Windows może ominąć ekranową weryfikację i uzyskać dostęp do kont chronionych passkeyami. Unit 42 opisał trzy ścieżki ataku. ## Kluczowe informacje - Opisane techniki nie łamią kryptografii passkeyów, lecz wykorzystują sposób działania Chrome i Google Password Manager. - Każda ścieżka wymaga, aby złośliwe oprogramowanie działało już na komputerze ofiary. - Jedna z metod może wygenerować asercję bez potwierdzenia obecności użytkownika, a dwie pozostałe mogą prowadzić do trwałego dostępu. - Serwisy powinny wymagać flagi User Verified i sprawdzać ją w otrzymanej asercji. Złośliwe oprogramowanie działające z uprawnieniami zwykłego użytkownika na komputerze z Windowsem może, według badania Unit 42, zalogować się do kont chronionych passkeyami bez odcisku palca, kodu PIN i bez wyświetlenia czegokolwiek na ekranie ofiary. Badacze opisali trzy ścieżki ataku na chmurowy moduł uwierzytelniający Google Password Manager w przeglądarce Chrome. Nazwali je Pass-ta-key, Silver Pass-ta-key i Golden Pass-ta-key. Najpoważniejsza z nich dotyczy sekretu chroniącego zsynchronizowane prywatne klucze passkeyów. ## To nie jest złamanie kryptografii passkeyów Opisane techniki nie polegają na matematycznym przełamaniu zabezpieczeń passkeyów. Wykorzystują elementy otaczające sam mechanizm kryptograficzny: sposób, w jaki Chrome przechowuje klucze urządzenia, proces ponownego rejestrowania urządzenia po utracie jego wcześniejszego stanu oraz to, jak serwis docelowy sprawdza, czy logowaniu rzeczywiście towarzyszyła weryfikacja człowieka. W zależności od wybranej ścieżki napastnik może uzyskać prawidłową asercję uwierzytelniającą, zarejestrować własny klucz weryfikacji użytkownika albo pozyskać Security Domain Secret, czyli SDS, używany do odszyfrowania zsynchronizowanych prywatnych kluczy. Zakres badania jest ograniczony do Google Password Manager w Chrome na komputerach z Windowsem wyposażonych w Trusted Platform Module, czyli TPM. Każda z technik zaczyna się dopiero wtedy, gdy złośliwe oprogramowanie działa już na urządzeniu ofiary. Są to więc metody po przełamaniu zabezpieczeń, określane jako post-compromise. Nie wyjaśniają, w jaki sposób napastnik zdobył dostęp do komputera, lecz pokazują, co może próbować osiągnąć po udanej infekcji. Materiał nie opisuje wykorzystania tych technik w realnych atakach, nie podaje identyfikatorów CVE, listy podatnych wersji Chrome ani kompletnego statusu działań naprawczych. - Lokalne rozpoznanie pozwala złośliwemu procesowi odczytać z profilu Chrome metadane dotyczące usług, nazw użytkowników, identyfikatorów poświadczeń i zaszyfrowanego materiału kluczowego. - Pass-ta-key może doprowadzić do uzyskania asercji z nieustawioną flagą User Verified, jeśli serwis nie wymaga jej i nie sprawdza jej wartości. - Silver Pass-ta-key dotyczy ponownej rejestracji urządzenia i możliwości zastąpienia klucza weryfikacji kluczem kontrolowanym przez napastnika. - Golden Pass-ta-key koncentruje się na SDS, który w określonym momencie znajduje się w pamięci procesu Chrome i służy do odszyfrowywania zsynchronizowanych prywatnych kluczy. ## Pierwsza ścieżka wykorzystuje brak sprawdzenia flagi UV W przypadku Pass-ta-key złośliwe oprogramowanie odczytuje z lokalnego profilu Chrome informacje wystarczające do ustalenia, z jakimi usługami i nazwami użytkowników powiązane są passkeys ofiary. Następnie wykorzystuje zapisany przez Chrome, opakowany klucz tożsamości urządzenia do podpisania przygotowanego żądania za pośrednictwem mechanizmów kryptograficznych Windows. Unit 42 wskazuje, że Chrome tworzy ten klucz bez nazwy, eksportuje go jako nieprzejrzysty obiekt i może później ponownie załadować bez wyświetlania monitu. W kodzie Chromium znajduje się komentarz wyjaśniający takie zachowanie oraz zadanie dotyczące oznaczania tych kluczy w przyszłości. Sam kod potwierdza część architektury, ale nie dowodzi, że najnowsza stabilna wersja Chrome nadal jest podatna na opisaną metodę. Rezultatem może być ważna asercja zwrócona przez Google Cloud Authenticator. Od asercji utworzonej po realnej weryfikacji użytkownika ma ją odróżniać flaga User Verified, czyli UV, pozostawiona bez ustawienia. Specyfikacja WebAuthn przewiduje, że serwis, który wymaga userVerification o wartości required, powinien odrzucić ceremonię bez tej flagi. Badacze podali, że GitHub przeprowadzał takie sprawdzenie, natomiast eBay początkowo zaakceptował testową asercję i po ujawnieniu problemu poprawił walidację. Ta ścieżka zależy więc od kontroli po stronie serwisu. Relying party, czyli usługa przyjmująca logowanie, może zablokować ją niezależnie od zachowania usługi chmurowej, o ile sprawdza nie tylko ustawienie żądania, lecz także wynikową asercję. ## Silver Pass-ta-key dotyczy ponownej rejestracji urządzenia Druga metoda celuje w proces ponownego rejestrowania urządzenia w Chrome. Według Unit 42 Chrome nie tworzy klucza weryfikacji użytkownika natychmiast po rozpoczęciu tego procesu. W powstałym oknie złośliwe oprogramowanie może doprowadzić do zarejestrowania własnego klucza. Badacze twierdzą, że usługa nie sprawdza, czy nowy klucz pochodzi z bezpiecznego sprzętu. Późniejsze asercje podpisane takim kluczem zawierają flagę UV, dlatego serwis może uznać je za wynik prawidłowej weryfikacji i dopuścić logowanie bez urządzenia ofiary. W tej wersji scenariusza początkowe przejęcie komputera może więc stworzyć napastnikowi możliwość dalszego dostępu z jego własnego środowiska. Publicznie dostępny kod Chromium potwierdza, że nowo rejestrowane urządzenia mogą przechodzić przez stan odroczonego utworzenia klucza weryfikacji. Nie potwierdza jednak samodzielnie opisanego przez Unit 42 serwerowego podstawienia klucza w najnowszej stabilnej wersji Chrome. Ujawnienie nie rozstrzyga też, czy produkcyjna usługa sprawdza obecnie atestację sprzętową przed zaakceptowaniem klucza zastępczego. Właśnie taką kontrolę badacze wskazują jako sposób ograniczenia tej ścieżki. Różnica między tym, co wynika z publicznego kodu, a tym, co dotyczy działania usługi po stronie serwera, jest istotna przy ocenie bieżącego ryzyka. ## Golden Pass-ta-key sięga po sekret w pamięci Chrome Najsilniejsza z opisanych metod, Golden Pass-ta-key, dotyczy bezpośrednio Security Domain Secret. Unit 42 twierdzi, że złośliwe oprogramowanie może wywołać ponowną rejestrację urządzenia, a następnie odczytać SDS z pamięci procesu Chrome w krótkim okresie, gdy sekret występuje tam w postaci jawnej. Pozyskany 32-bajtowy materiał ma służyć do odzyskania zsynchronizowanych prywatnych kluczy passkeyów. Według badaczy może to zapewnić dostęp możliwy do ponownego wykorzystania z infrastruktury napastnika, już poza początkowo zainfekowanym komputerem. Analiza kodu Chromium potwierdza podstawowy fakt, że sekrety domeny bezpieczeństwa są tworzone lub odbierane w strukturach danych procesu klienta Chrome, a więc trafiają do jego pamięci. Nie jest to jednak samodzielne potwierdzenie niezawodnego wydobycia sekretu, przejęcia konta ani utrzymania dostępu po kolejnych zmianach sekretu. Te elementy pozostają oparte na ustaleniach Unit 42 albo nierozstrzygnięte. Badacze poinformowali, że Google usunął wcześniejsze ujawnienie SDS z logów FIDO, a eBay zaczął sprawdzać flagę UV. Zmiana w logowaniu nie usuwa jednak ścieżki opisanej jako odczyt sekretu z pamięci Chrome. Nie ma publicznego potwierdzenia, że wszystkie trzy ścieżki zostały zamknięte. Według informacji zawartych w materiale, na 3 sierpnia 2026 roku wyszukiwanie w National Vulnerability Database nie wskazywało CVE odpowiadającego trzem nazwanym technikom. Przegląd publicznych materiałów Google dotyczących Chrome oraz stron pomocy i informacji prasowych eBay nie ujawnił komunikatu opisującego pełny zakres zmian. Dokumentacja Google pozwala zmienić PIN Google Password Manager lub usunąć wszystkie dane menedżera, ale nie opisuje osobnego mechanizmu rotacji albo unieważnienia SDS. Nie rozstrzygnięto również, czy zmiana PIN-u unieważnia sekret, który napastnik mógł już wcześniej pozyskać. Najważniejsze zabezpieczenia powinny działać na kilku poziomach. Serwisy korzystające z passkeyów powinny ustawiać wymóg userVerification na required i sprawdzać zwróconą flagę UV, zamiast ufać wyłącznie parametrom żądania. Dostawcy menedżerów poświadczeń powinni wzmacniać proces ponownej rejestracji i odzyskiwania dostępu, weryfikować pochodzenie nowo rejestrowanych kluczy oraz ograniczać dostęp do lokalnego stanu passkeyów. Powinni także unikać umieszczania sekretów głównych w logach i minimalizować ich obecność w pamięci procesu. Użytkownik, który podejrzewa infekcję, powinien potraktować urządzenie jako potencjalnie przejęte, ale publiczne materiały nie dają obecnie pewnej odpowiedzi, czy sama zmiana PIN-u lub usunięcie danych Google Password Manager unieważnia wcześniej skradziony SDS. ## Wyjaśnienie pojęć ### [Security Domain Secret (SDS)](https://najnowsze-informacje.pl/definicje/security-domain-secret-sds) SDS to 32-bajtowy sekret używany przez Google Password Manager do odszyfrowywania zsynchronizowanych prywatnych kluczy passkeyów. ### [Trusted Platform Module (TPM)](https://najnowsze-informacje.pl/definicje/trusted-platform-module-tpm) TPM to układ sprzętowy przeznaczony między innymi do przechowywania i używania kluczy kryptograficznych. W opisywanym badaniu jest elementem konfiguracji komputera z Windowsem. ### [Passkey](https://najnowsze-informacje.pl/definicje/passkey) Passkey to poświadczenie używane do logowania bez wpisywania hasła. Opiera się na parze kluczy kryptograficznych, z których prywatny pozostaje pod kontrolą urządzenia lub menedżera poświadczeń. ## Źródło pierwotne [The Hacker News](https://thehackernews.com/2026/08/google-password-manager-attacks-could.html) --- ## Informacje do cytowania - **Autor:** Redakcja - **Data publikacji:** 2026-08-05T12:26:46.516Z - **Ostatnia aktualizacja:** 2026-08-05T12:27:04.360Z - **Kategoria:** Cyberbezpieczeństwo - **Adres kanoniczny:** [https://najnowsze-informacje.pl/cyberbezpieczenstwo/ataki-na-google-password-manager-moga-przejac-konta-chronione-passkeyami](https://najnowsze-informacje.pl/cyberbezpieczenstwo/ataki-na-google-password-manager-moga-przejac-konta-chronione-passkeyami) - **Wersja Markdown:** [https://najnowsze-informacje.pl/cyberbezpieczenstwo/ataki-na-google-password-manager-moga-przejac-konta-chronione-passkeyami/index.md](https://najnowsze-informacje.pl/cyberbezpieczenstwo/ataki-na-google-password-manager-moga-przejac-konta-chronione-passkeyami/index.md) **Sugerowane cytowanie:** > Najnowsze Informacje, „Ataki na Google Password Manager mogą przejąć konta chronione passkeyami”, 2026-08-05, https://najnowsze-informacje.pl/cyberbezpieczenstwo/ataki-na-google-password-manager-moga-przejac-konta-chronione-passkeyami