Na konferencji DEF CON 33 zaprezentowano metodę ataku na dodatki przeglądarkowe, które wprowadzają swoje elementy interfejsu na odwiedzaną stronę. Zastosowanie ataku do dodatków z menedżerami haseł może prowadzić do ujawnienia przechowywanych w menedżerach haseł informacji, takich jak dane uwierzytelniające, dane kart kredytowych, dane osobowe oraz jednorazowe hasła do uwierzytelniania dwuetapowego. Problem dotyczy wszystkich przetestowanych menedżerów haseł, w tym 1Password, Bitwarden, LastPass, KeePassXC-Browser, NordPass, ProtonPass i Keeper.
Metoda ataku opiera się na tym, że dodatki przeglądarkowe wprowadzają dialog z prośbą o autouzupełnienie hasła bezpośrednio na wyświetlaną stronę, integrując swoje elementy w DOM (Document Object Model) tej strony. Jeśli atakujący ma możliwość wykonania swojego kodu JavaScript na stronie, na przykład wykorzystując lukę XSS na stronie, może manipulować wszystkimi elementami w DOM, w tym dodatkami przeglądarkowymi.
Między innymi istnieje możliwość uczynienia dialogu potwierdzenia przezroczystym i przestrzennie zintegrowania przycisku w tym dialogu z przyciskiem podszywającego się dialogu stworzonego przez atakującego, zachęcającym użytkownika do kliknięcia. Jako takie podszywające się dialogi mogą być używane fałszywe prośby o uprawnienia do Cookies, banery reklamowe lub formularze z CAPTCHA. Umieszczając podszywający się dialog pod przezroczystym dialogiem menedżera haseł i synchronizując lokalizację przycisków na ekranie, można osiągnąć, że kliknięcie użytkownika trafi na przycisk potwierdzenia wypełnienia danych uwierzytelniających w dialogu menedżera haseł, mimo że użytkownik będzie sądził, że kliknął na przykład przycisk zamknięcia okna z reklamą.
Atak polega na następujących krokach:
- Tworzenie nachalnego elementu na stronie, zachęcającego do kliknięcia.
- Dodanie do strony formularza webowego do logowania lub wypełnienia danych osobowych.
- Ustawienie przezroczystości dla formularza webowego ("opacity: 0.001" w CSS).
- Wykorzystanie metody focus() do ustawienia fokusu na polu w formularzu, co prowadzi do aktywacji dialogu autouzupełnienia menedżera haseł.
- Wyszukiwanie pojawiającego się dialogu menedżera haseł w DOM i ustawienie dla niego przezroczystości.
- Oczekiwanie na kliknięcie użytkownika na widocznym, natarczywym elemencie na stronie, które przy odpowiednim zestawieniu widocznych i niewidocznych elementów doprowadzi do naciśnięcia przycisku w przezroczystym oknie dialogowym oraz wypełnienia pól przez menedżera haseł.
- Ekstrakcja danych z wypełnionego formularza webowego i wysłanie ich na serwer atakującego.
Ponieważ automatyczne uzupełnianie parametrów uwierzytelnienia w menedżerze haseł aktywowane jest tylko dla stron, na których te parametry zostały zapisane, do przeprowadzenia ataku należy mieć możliwość uruchomienia swojego kodu JavaScript na atakowanej stronie lub poddomenie. W ten sposób do przeprowadzenia ataku konieczne jest albo uzyskanie poddomeny w tej samej domenie, co atakowana strona, albo znalezienie luki XSS na stronie, pozwalającej na wstrzyknięcie własnego kodu do wyświetlanej użytkownikowi treści.
Zauważono, że wielu użytkowników korzysta z jednego menedżera haseł zarówno do przechowywania danych logowania, jak i do generowania jednorazowych haseł do uwierzytelniania dwuetapowego, co pozwala na wykorzystanie omawianej metody ataku podczas automatycznego uzupełniania jednorazowych haseł. Jako przykład pokazano atak na stronę issuetracker.google.com, która zawiera lukę XSS. Aby uzyskać dane logowania oraz kod do uwierzytelniania dwuetapowego, wystarczy wysłać użytkownikowi link wykorzystujący lukę XSS i doprowadzić do trzech kliknięć poprzez podstawienie fikcyjnych, natarczywych żądań (zezwolenie na przetwarzanie ciasteczek, zezwolenie na personalizację oraz zgoda na politykę prywatności).
Oprócz stron z lukami XSS atak może być przeprowadzony na serwisy, które oferują poddomeny wszystkim chętnym — większość menedżerów haseł w konfiguracji domyślnej wypełnia dane logowania nie tylko dla głównej domeny, lecz także dla poddomen.
Atak może być również wykorzystywana do uzyskania dostępu do zapisanych w menedżerze haseł danych osobowych użytkownika oraz informacji o kartach kredytowych. W takim przypadku do wycieku takich danych nie jest konieczne uruchamianie kodu JavaScript w kontekście obcej strony, wystarczy skusić ofiarę na stronę na witrynie atakującego — w przypadku danych osobowych wypełnianie formularzy internetowych odbywa się na podstawie ich rodzaju (adres, numer karty kredytowej, imię i nazwisko), bez odniesienia do domeny. Najbardziej niebezpieczne jest wyciek parametrów kart kredytowych, ponieważ menedżery haseł podają nie tylko numer karty, ale również datę jej ważności oraz kod weryfikacyjny.
Badacz, który zidentyfikował problem, przetestował 11 dodatków przeglądarki z menedżerami haseł, które łącznie miały 39,7 mln aktywnych instalacji, i wszystkie okazały się narażone na tego typu ataki. Niektórzy producenci wydali aktualizacje (NordPass 5.13.24, ProtonPass 1.31.6, RoboForm 9.7.6, Dashlane 6.2531.1, Keeper 17.2.0, Enpass 6.11.6, Bitwarden 2025.8.1), w których obejściem próbowali zablokować przeprowadzenie ataku. Inne dodatki (KeePassXC-Browser, 1Password, iCloud Passwords, Enpass, LastPass, LogMeOnce) dotychczas pozostają bez poprawek. W celu sprawdzenia występowania podatności w różnych menedżerach haseł opublikowano zestaw stron testowych.
Stanowisko twórców 1Password, którzy nie wydali poprawki, polega na tym, że podatność jest fundamentalna i nie jest bezpośrednio związana z konkretnym dodatkiem przeglądarki, dlatego próby jej usunięcia po stronie dodatku jedynie blokują poszczególne wektory ataku, ale nie eliminują samego problemu, który należy rozwiązać w przeglądarce lub wniosku o oddzielne potwierdzenie przed automatycznym wypełnianiem pól. Wspomniano, że w 1Password już obsługiwane jest wyświetlanie zapytania o potwierdzenie przed automatycznym wypełnieniem parametrów płatności, a w następnej wersji zostanie dodana opcja do wyświetlania podobnego zapytania dla wszystkich typów automatycznie wypełnianych danych (z powodu zmniejszenia komfortu pracy taka opcja nie będzie domyślnie aktywowana).
Wśród metod ochrony, które autor badań wymienia, znajduje się śledzenie zmian stylów elementów wstawionych na stronę za pomocą API MutationObserver, blokowanie zmian poprzez Shadow DOM w trybie „closed”, monitorowanie przejrzystości elementów, użycie API Popover do wyświetlania dialogów, sprawdzanie nałożenia warstw oraz tymczasowe wyłączenie obsługi zdarzeń wskaźnika (pointer-events:none) we wszystkich pływających elementach podczas wyświetlania dialogu menedżera haseł. W tym celu, dla pełnego zablokowania opisanego klasy ataków zaleca się na poziomie przeglądarki wdrożenie oddzielnego API ochrony przed clickjackingiem.
Jako uniwersalną metodę ochrony w przeglądarkach opartych na silniku Chromium użytkownikom zaleca się włączenie trybu potwierdzenia dostępu dodatku do strony (Ustawienia dodatku → „dostęp do strony” → „po kliknięciu”), w którym dodatek uzyskuje dostęp do strony tylko po kliknięciu na ikonę po prawej stronie paska adresu. Jako alternatywna metoda ochrony wspomniane jest również wyłączenie automatycznego wypełniania formularzy oraz ręczne kopiowanie haseł przez schowek, co rodzi jednak problem wycieku danych z wspólnego schowka i ryzyko niezauważenia prób phishingu.
Źródło: opennet.ru
