Vaultjacking: gdy phishing próbuje otworzyć cały sejf haseł

To nie jest kolejny artykuł o „fałszywym logowaniu”

Klasyczny phishing próbuje zdobyć jedno hasło. Nowszy atak może celować w moment, w którym przeglądarka prosi o dodatkową zgodę: PIN, kod urządzenia albo ponowne odblokowanie magazynu haseł. Jeśli ofiara poda te dane na stronie kontrolowanej przez napastnika, stawką nie musi być jedno konto. Stawką staje się cały zbiór poświadczeń zgromadzonych przez lata.

Termin vaultjacking nie jest ustaloną nazwą klasy ataku. W tym artykule używamy go jako etykiety autora konkretnego posta, nie jako nazwy uznanej techniki. Pojawił się w poście na Reddit r/netsec jako określenie demonstracji, w której autor twierdzi, że strona AiTM ma udawać ekran Google Password Manager i nakłonić użytkownika do ujawnienia PIN-u.^[2] To rozróżnienie jest ważne: opis społecznościowy może być ciekawym sygnałem, ale nie zastępuje analizy kodu, komunikatu producenta ani niezależnej reprodukcji.

Jak wygląda łańcuch ataku?

W modelu AiTM, czyli adversary-in-the-middle, użytkownik trafia na stronę, która przekazuje żądania między nim a prawdziwą usługą. Zamiast prostej kopii ekranu napastnik może wyświetlić aktualny formularz, dopasować treść do urządzenia i prowadzić ofiarę przez cały proces logowania. Taki mechanizm bywa używany do przechwytywania haseł, kodów jednorazowych i ciasteczek sesyjnych.

1. Ofiara dostaje wiadomość albo reklamę prowadzącą do domeny łudząco podobnej do prawdziwej.
2. Strona prosi o hasło lub rozpoczęcie logowania, a następnie wyświetla komunikat o konieczności „odblokowania sejfu”.
3. Użytkownik wpisuje PIN w niewłaściwym miejscu albo zatwierdza zgodę, której nie rozumie.
4. Napastnik próbuje użyć uzyskanej sesji lub odczytać poświadczenia dostępne w danym modelu synchronizacji.

Najbardziej interesujący jest trzeci krok. Użytkownik nie musi uznać go za podejrzany, bo przeglądarki regularnie proszą o ponowne uwierzytelnienie. Bezpieczeństwo zależy więc nie tylko od kryptografii, lecz także od tego, czy interfejs potrafi przekonać człowieka, że wykonuje normalną czynność.

Passkey nie rozwiązuje całego problemu

Passkey korzystający z WebAuthn wiąże podpis z domeną usługi. Google opisuje tę właściwość wprost: przeglądarka lub system operacyjny pozwala użyć passkey tylko w witrynie lub aplikacji, która go utworzyła.^[1] Fałszywa domena nie powinna dostać poprawnego podpisu dla domeny banku czy poczty. To duża przewaga nad hasłem. Nie oznacza jednak, że każde zagrożenie znika.

Trzeba oddzielić trzy rzeczy: sam klucz, proces logowania oraz magazyn, który przechowuje poświadczenia i może je synchronizować. Sprzętowy klucz FIDO2 ma inny profil ryzyka niż passkey zsynchronizowany przez ekosystem chmurowy. W pierwszym przypadku prywatny klucz pozostaje związany z urządzeniem. W drugim bezpieczeństwo zależy również od konta synchronizacji, przeglądarki, mechanizmu odblokowania i polityk dostawcy.

To nie jest argument przeciw passkeys. To argument przeciw zdaniu „włączyliśmy passkeys, więc temat bezpieczeństwa tożsamości jest zamknięty”. Obrona działa warstwowo. Jeśli jedna warstwa chroni logowanie, kolejna musi chronić magazyn i sesję.

Czego nie wiemy?

• Nie mamy tu niezależnego potwierdzenia, że opisany mechanizm działa w każdej konfiguracji Google Password Manager.
• Nie należy przenosić wyników demonstracji na wszystkie menedżery haseł ani wszystkie passkeys.
• Nie każda prośba o PIN oznacza atak. Liczy się domena, kontekst i to, czy sam rozpocząłeś operację.
• Przejęcie sesji, malware na urządzeniu i wyłudzenie PIN-u to różne scenariusze; mają inne zabezpieczenia i inne ślady.

Jak ograniczyć skutki?

Użytkownik powinien zatrzymać się przed wpisaniem sekretu po kliknięciu w link z wiadomości. Otwórz usługę z własnego zakładki albo wpisz adres ręcznie. Sprawdź domenę, ale nie traktuj samej kłódki HTTPS jako dowodu autentyczności.

W organizacji warto rozdzielić poświadczenia prywatne od administracyjnych, ograniczyć możliwość zapisywania sekretów produkcyjnych w przeglądarce i prowadzić ewidencję kont o wysokim wpływie. Po podejrzeniu przejęcia magazynu nie wystarczy zmienić hasła do poczty. Trzeba ustalić, jakie konta były w sejfie, unieważnić sesje i rotować klucze API, tokeny oraz hasła uprzywilejowane.