
1 poważna luka Microsoft Edge: hasła w czystym tekście
Microsoft Edge przechowuje wszystkie zapisane hasła w pamięci RAM w formie czystego tekstu, nawet gdy użytkownik z nich nie korzysta. Informację tę potwierdziło Microsoft Security Response Center (MSRC) w odpowiedzi na zgłoszenie badawcze. Hasła pozostają dostępne dla każdego procesu działającego w ramach tej samej sesji systemu Windows. To poważna luka architektoniczna.
TL;DR: Microsoft Edge trzyma wszystkie zapisane hasła w pamięci RAM jako jawny tekst, bez szyfrowania, nawet kiedy nie są używane. Microsoft Security Response Center potwierdził ten fakt, klasyfikując go jako „by design” – zamierzoną cechę produktu. Zgłoszenie badawcze ujawnia, że każdy proces w systemie może odczytać te dane, co dotyka setek milionów użytkowników przeglądarki na platformie Windows.
Dlaczego Edge trzyma hasła w czystym tekście w pamięci RAM?
Microsoft Edge wykorzystuje mechanizm Windows DPAPI (Data Protection API) wyłącznie do zabezpieczenia bazy haseł na dysku twardym. Gdy użytkownik uruchamia przeglądarkę i loguje się do swojego profilu, system operacyjny automatycznie deszyfruje bazę. Od tego momentu wszystkie poświadczenia rezydują w przestrzeni pamięci w pełni czytelnej formie. Microsoft potwierdził w odpowiedzi na zgłoszenie, że takie podejście jest celowe i pozwala uniknąć ciągłego odpytywania użytkownika o hasło główne. Architektura przeglądarki nie implementuje dodatkowej warstwy ochronnej dla pamięci operacyjnej. Hasła są ładowane w całości, niezależnie od tego, czy użytkownik planuje z nich korzystać w danej sesji.
Co więcej, taka konstrukcja ułatwia integrację z natywnymi mechanizmami synchronizacji konta Microsoft. Przeglądarka musi mieć stały dostęp do poświadczeń, aby automatycznie wypełniać formularze logowania na odwiedzanych stronach internetowych. W rezultacie rezygnacja z dodatkowego szyfrowania warstwy pamięci jest świadomym kompromisem pomiędzy wygodą a bezpieczeństwem. Podobne mechanizmy pamięci podręcznej omawiałem wcześniej w kontekście Anthropic skróciło TTL pamięci podręcznej 6 marca, gdzie czas przechowywania danych bezpośrednio wpływał na bezpieczeństwo operacyjne.
Jak wygląda proces wydobycia haseł z pamięci?
Zgłoszenie do MSRC szczegółowo opisuje techniczną stronę ataku na przeglądarkę. Badacze udowodnili, że do wydobycia poświadczeń wystarczy dostęp na poziomie zwykłego użytkownika w systemie Windows. Atakujący może użyć standardowych narzędzi diagnostycznych dostępnych w systemie, takich jak Procdump z pakietu Sysinternals. Narzędzie to tworzy zrzut pamięci procesu msedge.exe bez konieczności posiadania uprawnień administratora. Następnie plik zrzutu poddaje się analizie za pomocą edytora szesnastkowego lub prostego skryptu wyszukującego wzorce znaków odpowiadające strukturom URL oraz ciągom alfanumerycznym. Skrypt systematycznie skanuje zrzut pamięci.
Ponadto, istnieje możliwość bezpośredniego odczytu pamięci działającego procesu za pomocą funkcji API systemu Windows, takich jak ReadProcessMemory. Metoda ta nie wymaga tworzenia pliku zrzutu na dysku, co utrudnia detekcję przez oprogramowanie antywirusowe. Zgłoszenie wskazuje, że atakujący potrzebuje jedynie możliwości uruchomienia kodu w kontekście tego samego użytkownika, co ofiara. Poniższa tabela zestawia kluczowe parametry techniczne tej luki architektonicznej.
| Parametr | Opis techniczny | Wymagania atakującego |
|---|---|---|
| Miejsce przechowywania | Pamięć RAM procesu msedge.exe | Dostęp na poziomie usera |
| Szyfrowanie w pamięci | Brak (jawny tekst) | Zwykłe uprawnienia wystarczą |
| Metoda ekstrakcji | Zrzut pamięci (Procdump) lub API | Uruchomienie kodu w tej samej sesji |
| Ochrona Microsoftu | Brak (status: by design) | Brak mechanizmów obronnych |
| Liczba dotkniętych haseł | Wszystkie zapisane w profilu | Dostęp do konta Windows |
Czym różni się to od standardowych ataków na menedżery haseł?
Typowe ataki na menedżery haseł wymagają interakcji użytkownika lub obecności złośliwego oprogramowania ukierunkowanego na konkretną aplikację. Na przykład NWHStealer, opisywany przez badaczy Malwarebytes, infekuje system pod przykrywką fałszywych aplikacji i aktywnie poszukuje baz danych haseł na dysku. Z kolei sytuacja z Edge’em polega na pasywnym przechowywaniu jawnych tekstów w pamięci operacyjnej. Malware nie musi znać struktury plików bazy danych ani omijać szyfrowania dyskowego. Wystarczy zwykły zrzut pamięci uniwersalnym narzędziem systemowym. Różnica polega na braku konieczności wyspecjalizowanego ataku.
Jednakże, w przypadku dedykowanych menedżerów haseł, poświadczenia są deszyfrowane dopiero w momencie konkretnego żądania ze strony użytkownika i usuwane z pamięci natychmiast po użyciu. Architektura Edge’a ładowana jest do pamięci w całości podczas logowania do profilu. Taki model działania sprawia, że potencjalny obszar ataku jest znacznie większy i utrzymuje się przez cały czas działania przeglądarki. Temat zarządzania poświadczeniami i bezpieczeństwa łańcuchów dostaw poruszałem również w artykule o Łagodzenie kompromitacji łańcucha dostaw npm Axios, gdzie niewłaściwe zabezpieczenia pojedynczego komponentu wpływały na bezpieczeństwo całego ekosystemu.
Jakie są techniczne konsekwencje przechowywania jawnych haseł?
Techniczne implikacje tej luki architektonicznej dotykają zarówno użytkowników domowych, jak i środowisk korporacyjnych. Przede wszystkim, każdy proces złośliwy działający w ramach sesji użytkownika może odczytać wszystkie zapisane hasła bez wyzwalania alertów bezpieczeństwa. Obejmuje to skrypty makr w dokumentach, złośliwe pliki wykonywalne pobrane z internetu oraz rozszerzenia przeglądarki z odpowiednimi uprawnieniami. Skutkiem ataku jest całkowita kompromitacja cyfrowej tożsamości użytkownika.
Ponadto, w środowiskach współdzielonych, gdzie wielu użytkowników pracuje na jednym stanowisku, ryzyko rośnie proporcjonalnie do liczby zalogowanych profili. Atakujący z dostępem do jednego konta może potencjalnie pozyskać poświadczenia innych osób, jeśli ich procesy przeglądarkowe działają w tle. W rezultacie, dla organizacji opierających zabezpieczenia na Microsoft Copilot Cowork z Claude i ekosystemie Microsoftu, taka luka stanowi wektor ataku na infrastrukturę chmurową firmy. Hasła do usług firmowych pozostają narażone.
- Zwykły zrzut pamięci procesu ujawnia wszystkie zapisane hasła w formie jawnej
- Atak nie wymaga uprawnień administratora ani wyspecjalizowanego oprogramowania
- Hasła pozostają w pamięci przez cały czas działania przeglądarki Microsoft Edge
- Mechanizm DPAPI chroni wyłącznie plik na dysku, całkowicie ignorując pamięć RAM
- Złośliwe rozszerzenia mogą potencjalnie uzyskać dostęp do obszaru pamięci z poświadczeniami
- Synchronizacja konta Microsoft powoduje załadowanie do pamięci haseł ze wszystkich zsynchronizowanych urządzeń
- Status „by design” oznacza brak planów naprawy tej architektury ze strony producenta
- Środowiska współdzielone zwiększają ryzyko ze względu na wiele działających procesów przeglądarkowych
Jakie kroki zaradcze mogą zastosować użytkownicy Edge’a?
Microsoft sklasyfikował przechowywanie jawnych haseł w pamięci jako zamierzoną cechę architektury, co oznacza brak oficjalnej łatki ze strony producenta. Zgłoszenie do MSRC zostało zamknięte ze statusem „by design”, co potwierdza, że konstrukcja przeglądarki celowo pomija szyfrowanie warstwy pamięci operacyjnej. Użytkownicy muszą polegać wyłącznie na własnych mechanizmach obronnych i procedurach operacyjnych.
Zgłoszenie badawcze do MSRC otrzymało status „by design” (zamierzone), co oznacza, że Microsoft nie planuje łatać tej architektury. W rezultacie użytkownicy nie mogą oczekiwać łatki naprawiającej ten problem w najbliższych aktualizacjach przeglądarki. Jedyną skuteczną metodą ograniczenia ryzyka jest całkowite wyłączenie wbudowanego menedżera haseł w ustawieniach profilu Edge. Działa to natychmiastowo.
Ponadto, organizacje powinny rozważyć wdrożenie polityki grupowej wymuszającej stosowanie zewnętrznych menedżerów haseł. Narzędzia takie jak Bitwarden czy 1Password deszyfrują poświadczenia wyłącznie na żądanie, usuwając je z pamięci natychmiast po autouzupełnieniu. Temat zarządzania dostępem i bezpieczeństwa tożsamości omawiałem w kontekście artykułu o Jedno kliknięcie i tracisz dostęp, gdzie podkreślano konieczność stosowania kryptografii sprzętowej. Poniżej zestawienie działań zaradczych.
- Całkowite wyłączenie opcji zapisywania haseł w ustawieniach przeglądarki Microsoft Edge
- Wdrożenie zewnętrznego menedżera haseł z funkcją deszyfrowania na żądanie
- Regularne blokowanie stacji roboczych w środowiskach współdzielonych
- Ograniczenie uprawnień użytkowników do instalowania niezweryfikowanego oprogramowania
- Monitorowanie procesów systemowych pod kątem nietypowych zrzutów pamięci
- Wdrożenie kluczy sprzętowych Passkeys w miejsce tradycyjnych haseł tekstowych
| Mechanizm obronny | Skuteczność | Koszt wdrożenia |
|---|---|---|
| Wyłączenie menedżera Edge | Natychmiastowa | Zero |
| Zewnętrzny menedżer haseł | Wysoka | Niski |
| Klucze sprzętowe Passkeys | Bardzo wysoka | Średni |
Jak luka w Edge’u wpływa na bezpieczeństwo korporacyjne?
Środowiska firmowe opierające infrastrukturę na ekosystemie Microsoftu są szczególnie narażone na konsekwencje tej architektury. Synchronizacja konta Microsoft powoduje, że hasła ze wszystkich urządzeń pracownika ładowane są do pamięci RAM na pojedynczej stacji roboczej. Wystarczy jedna zainfekowana maszyna w sieci lokalnej, aby atakujący skompromitował poświadczenia do wielu systemów firmowych.
Ekosystem Microsoftu zakłada głęboką integrację przeglądarki z usługami chmurowymi i mechanizmami uwierzytelniania systemu Windows. Zgłoszenie badawcze wskazuje, że złośliwy kod działający w kontekście zwykłego użytkownika może odczytać poświadczenia bez wyzwalania mechanizmów detekcji. Temat kompromitacji infrastruktury z poziomu pojedynczego komponentu poruszałem przy okazji analizy Łagodzenie kompromitacji łańcucha dostaw npm Axios, gdzie luka w jednej bibliotece otwierała wektor ataku na całe systemy.
Z kolei, w kontekście Microsoft i OpenAI kończą swoją ekskluzywną umowę, organizacje intensywnie inwestują w narzędzia AI i automatyzację, często pomijając podstawy bezpieczeństwa na stacjach roboczych. Dostęp do pamięci procesu przeglądarki daje atakującemu klucze do aplikacji chmurowych, paneli administracyjnych i baz danych. Skrypt złośliwy może działać w tle.
Co więcej, tradycyjne oprogramowanie antywirusowe rzadko wykrywa zrzuty pamięci wykonywane za pomocą oficjalnych narzędzi systemowych, takich jak Procdump. Narzędzie to posiada podpis cyfrowy Microsoftu, co sprawia, że system traktuje je jako wiarygodne. W rezultacie atak pozostaje niezauważony przez całe tygodnie. To poważny problem operacyjny.
Jakie są alternatywy dla wbudowanego menedżera haseł?
Architektura dedykowanych menedżerów haseł znacząco różni się od modelu zastosowanego w przeglądarce Microsoft Edge. Rozwiązania takie jak Bitwarden, 1Password czy KeePass przechowują poświadczenia w zaszyfrowanym magazynie i deszyfrują je wyłącznie na bezpośrednie żądanie użytkownika. Po autouzupełnieniu formularza jawne dane są natychmiast usuwane z pamięci RAM. To fundamentalna różnica architektoniczna.
Zewnętrzne menedżery haseł implementują mechanizm tzw. bezpiecznej pamięci, która nadpisuje dane kryptograficznym śmieciem po zakończeniu operacji. W przeciwieństwie do Edge’a, gdzie hasła rezydują w pamięci przez cały czas działania procesu, menedżery minimalizują okno czasowe ekspozycji na atak. Temat optymalizacji zasobów i zarządzania pamięcią poruszałem w artykule o Google TurboQuant: 6x kompresja pamięci AI, gdzie efektywne zarządzanie zasobami bezpośrednio wpływa na stabilność.
Otóż, menedżery haseł wymagają podania głównego hasła lub uwierzytelnienia biometrycznego przed każdym odszyfrowaniem. To dodatkowy krok, który eliminuje scenariusz pasywnego wydobycia poświadczeń przez złośliwy proces działający w tle. Atakujący musiałby przechwycić moment autouzupełniania. Okno ataku jest minimalne.
Jednakże, użytkownicy często rezygnują z zewnętrznych menedżerów ze względu na wygodę i integrację z systemem. Przeglądarka oferuje natywne autouzupełnianie bez dodatkowych kliknięć. Zgłoszenie do MSRC pokazuje, że ten kompromis ma swoją cenę w postaci pełnej ekspozycji poświadczeń w pamięci RAM.
Często zadawane pytania
Czy Microsoft planuje naprawić tę lukę w Edge’u?
Nie, Microsoft Security Response Center sklasyfikował to zachowanie jako „by design” (zamierzone) i zamknął zgłoszenie bez planów naprawy. Użytkownicy muszą sami wyłączyć menedżer haseł.
Czy użycie PIN-u Windows Hello chroni przed tym atakiem?
Nie, PIN Windows Hello odblokowuje jedynie dostęp do bazy na dysku, która jest następnie deszyfrowana do czystego tekstu w pamięci RAM. Zgłoszenie badawcze potwierdza, że poświadczenia pozostają jawne dla całej sesji.
Czy profil gościa w Edge’u również przechowuje hasła w pamięci?
Profil gościa nie zapisuje haseł na dysku, ale jeśli użytkownik ręcznie wprowadzi poświadczenia na stronie, mogą one tymczasowo znaleźć się w pamięci operacyjnej procesu. Ryzyko jest mniejsze, ale nadal obecne.
Jak sprawdzić, czy hasła w Edge’u są narażone na atak?
Każda instalacja Edge’a z włączonym menedżerem haseł i co najmniej jednym zapisanym poświadczeniem jest narażona na ten wektor ataku. Należy otworzyć ustawienia „Profile > Hasła” i sprawdzić listę zapisanych wpisów.
Podsumowanie
Architektura Microsoft Edge celowo przechowuje wszystkie zapisane hasła w pamięci RAM jako jawny tekst, bez dodatkowego szyfrowania. Status „by design” oznacza, że producent nie planuje zmiany tego mechanizmu. Użytkownicy są pozostawieni sami sobie w kwestii zabezpieczenia poświadczeń. Główne wnioski z analizy tej luki architektonicznej obejmują:
- Hasła pozostają w pamięci przez cały czas działania przeglądarki, niezależnie od tego, czy są używane
- Zgłoszenie do MSRC zostało zamknięte jako „by design” – nie należy oczekiwać oficjalnej łatki
- Atak wymaga jedynie dostępu na poziomie zwykłego użytkownika w systemie Windows
- Wyłączenie wbudowanego menedżera haseł i wdrożenie zewnętrznego rozwiązania to jedyne skuteczne działania zaradcze
Jeśli używasz Edge’a jako głównej przeglądarki i masz w nim zapisane hasła, natychmiast otwórz ustawienia profilu i wyłącz opcję zapisywania poświadczeń. Przenieś swoje dane do dedykowanego menedżera haseł, który deszyfruje wpisy wyłącznie na żądanie. Udostępnij ten artykuł zespołowi IT w swojej organizacji, aby świadomość tej luki architektonicznej dotarła do osób odpowiedzialnych za bezpieczeństwo stacji roboczych.