Microsoft Edge speichert alle Passwörter im Klartext im Arbeitsspeicher, auch wenn sie nicht verwendet werden

• Microsoft Edge entschlüsselt alle gespeicherten Passwörter beim Start und hält diese Anmeldedaten im Prozessspeicher als Klartext vor
• Dieses Verhalten tritt auf, selbst wenn der Nutzer keine Website besucht, die diese Anmeldedaten verwendet
• Die Passwort-Manager-Oberfläche von Edge verlangt zwar eine erneute Authentifizierung, bevor dasselbe Passwort angezeigt wird, der Browserprozess hält jedoch bereits alle Passwörter im Klartext vor
• Unter den getesteten Chromium-basierten Browsern verhielt sich nur Edge auf diese Weise; Chrome ist so konzipiert, dass gespeicherte Passwörter nicht einfach aus dem Prozessspeicher ausgelesen und extrahiert werden können
• Chrome entschlüsselt Anmeldedaten nur bei Bedarf und bindet die Entschlüsselung mit App-Bound Encryption (ABE) an einen authentifizierten Chrome-Prozess, sodass andere Prozesse Chromes Verschlüsselungsschlüssel nicht wiederverwenden können
• Durch diese Kontrolle erscheinen Klartext-Passwörter nur kurzzeitig bei AutoFill oder wenn der Nutzer sie direkt anzeigen lässt, wodurch großflächiges Memory Scraping weniger wirksam wird

Risikoszenarien und Offenlegungsstatus

• In gemeinsam genutzten Umgebungen steigt das Risiko, wenn Klartext-Passwörter im Arbeitsspeicher verbleiben
• Erlangt ein Angreifer auf einem Terminalserver Administratorrechte, kann er auf den Speicher aller Prozesse angemeldeter Nutzer zugreifen
• In der Demonstration konnte ein Angreifer, der ein Benutzerkonto mit Administratorrechten übernommen hatte, die gespeicherten Anmeldedaten von zwei anderen angemeldeten Nutzern oder von getrennten Sitzungen sehen, während Edge lief
• Dieses Verhalten wurde Microsoft gemeldet; die offizielle Antwort lautete, dass es „by design“ sei
• Microsoft wurde mitgeteilt, dass dies im Sinne einer verantwortungsvollen Offenlegung veröffentlicht werde, damit Nutzer und Organisationen ihre Verfahren zur Verwaltung von Anmeldedaten bewerten können
• Am Mittwoch, dem 29. April, wurde dies bei BigBiteOfTech von Palo Alto Networks Norway vorgestellt, zusammen mit einem einfachen Tool, mit dem sich leicht prüfen lässt, ob Passwörter im Arbeitsspeicher im Klartext gespeichert werden
• Das Proof-of-Concept-Tool wurde auf GitHub veröffentlicht; da nur begrenzte Erfahrung mit C# und GitHub-Releases besteht, wird um Feedback gebeten: EdgeSavedPasswordsDumper

[GN⁺]

Hacker-News-Kommentare

• Das ist eher eine Situation, in der man sich bereits auf der anderen Seite des luftdichten Schotts befindet. Wenn man den Speicher beliebiger Prozesse lesen kann, ist man wahrscheinlich auch in einer Position, in der man einfach Passwörter dumpen kann, indem man sich als dieser Benutzer ausgibt.
  Wenn ein Angreifer Administratorrechte auf einem Terminalserver erlangt, kann er auf den Speicher aller angemeldeten Benutzerprozesse zugreifen; mit Administratorrechten könnte er auch einen Debugger an alle Chrome-Prozesse anhängen und die Entschlüsselung von Passwörtern erzwingen.
  Der tatsächliche Unterschied betrifft höchstens Cold-Boot-Angriffe; selbst dann ist unklar, ob das den Angriff nur etwas einfacher macht oder tatsächlich Angriffe ermöglicht, die sonst unmöglich wären.
  [1] https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...
  • Diese Logik passt exakt zum Chromium-Bedrohungsmodell. In dem Moment, in dem ein Angreifer Administratorrechte erlangt, ist definitionsgemäß alles verloren.
    Es wirkt unwahrscheinlich, dass das ein Edge-spezifisches Problem ist, und es gibt auch keinen ersichtlichen Grund, warum Microsoft den Browser unsicherer machen sollte als das Upstream-Projekt.
    Chrome betrachtet physisch lokale Angriffe als außerhalb seines Bedrohungsmodells; wenn sich jemand als ich auf meinem Gerät anmeldet oder Software mit meinen Betriebssystem-Benutzerrechten ausführen kann, gibt es nach dieser Sicht weder für Chrome noch für irgendeine App eine Möglichkeit zur Verteidigung.
    Ein solcher Angreifer kann ausführbare Dateien und DLLs verändern, Umgebungsvariablen wie PATH ändern, Konfigurationsdateien manipulieren sowie Benutzerdaten lesen und exfiltrieren; daher ist die Position, dass Chrome hier keine sinnvolle Sicherheitsgarantie geben kann.
    https://chromium.googlesource.com/chromium/src/+/148.0.7778....
  • In den letzten Jahren gab es Browser-Schwachstellen, mit denen schon mit normalen Benutzerrechten beliebige Speicherlesezugriffe möglich waren, auch wenn diese langsam waren oder keine vollständige Kontrolle über die Zieladressen boten. Zugangsdaten nach der Nutzung so schnell wie möglich zu löschen, ist daher eine durchaus vernünftige Vorsichtsmaßnahme, selbst wenn es nur einen weiteren Schutzgraben darstellt.
  • Sicherheit ist nicht schwarz-weiß. Einen Zettel mit Login-Daten an den Monitor zu kleben ist klar riskanter, als ihn in eine unverschlossene Schublade zu legen — es gibt Abstufungen.
  • Aus Nutzersicht muss man sich doch jedes Mal zuerst per biometrischer Authentifizierung anmelden, wenn man ein Passwort einfügen will — und dann soll irgendein Benutzerprozess das Passwort einfach aus dem Speicher abgreifen können?
    Vielleicht übersehe ich etwas.
  • Habt ihr Cloudbleed etwa schon vergessen?
    [0] https://en.wikipedia.org/wiki/Cloudbleed
• Der Vollständigkeit halber: Google erklärt, dass Chrome Passwörter im Speicher verschlüsselt speichert und einen Privilegienerhöhungsdienst verwendet, damit sich andere Prozesse nicht als Chrome ausgeben und auf Klartext-Passwörter zugreifen können: https://security.googleblog.com/2024/07/improving-security-o...
• Um es klar zu sagen: Ein möglicher Angriffsweg ist, dass man den Computer ungesperrt lässt, fünf Minuten auf die Toilette geht und ein böswilliger Hacker in dieser Zeit alle Passwörter dumpt, bevor man zurückkommt.
  Ich finde, das ist durchaus bedenkenswert. Dass Passwortmanager nach 10 Minuten erneut das Master-Passwort oder einen Passkey verlangen, hat seinen Grund.
  Ich war davon ausgegangen, dass Chrome auf einen verschlüsselten sicheren Bereich setzt und dass selbst mit Root-Rechten ein einfaches Extrahieren der Passwörter ziemlich schwierig wäre.
  Natürlich sollte man seinen Computer nicht unbeaufsichtigt lassen. Aber das bedeutet nicht, dass man Produkte so entwerfen sollte, dass unvermeidliche Fehler besonders leicht katastrophal ausgenutzt werden können.
• Greift dieses Tool auf eine Edge-Instanz zu, die auf derselben Maschine läuft? Wenn ja, könnte man die gespeicherten Passwörter dann nicht einfach exportieren?
  https://support.microsoft.com/en-us/topic/export-passwords-i...
  • Passwortmanager investieren oft erheblichen Aufwand, um Passwörter im Speicher sicher zu halten, aber das Angriffsmodell solcher Tools wird häufig nicht gut verstanden.
    Tools wie KeePass achten zum Beispiel sehr darauf, Browser-Plugins zu registrieren, aber mit normalen Benutzerrechten kann man den Schlüssel trotzdem aus dem Browser ziehen und damit beliebige Dinge tun.
    Auch Web-App-Ansätze wie „diesem Browser vertrauen“ wirken seltsam, wenn sich der Cookie-Speicher so leicht auslesen lässt.
• Unter Linux dürfte sich mit PAM etwas Ähnliches machen lassen. Man müsste nur gdb an einen openssh- oder getty-Login-Prozess anhängen.
• Gibt es einen Link zum Quellcode dieser .exe? Ich würde gern sehen, wie die Extraktion funktioniert.
• Der eigentliche Fehler ist, dass man immer noch einfache Passwort-Authentifizierung verwendet. Man sollte Challenge-Response oder Public-Key-Authentifizierung nutzen.
• Fairerweise ist in den Speicher geladen zu sein nicht dasselbe wie dort gespeichert zu werden.
  • In der Überschrift steht jedoch „im Speicher gespeichert“, und für mich klingt das fast gleich. Kannst du erklären, wie du den Unterschied zwischen „in den Speicher laden“ und „im Speicher speichern“ siehst?
• Korrigiert mich, wenn ich falsch liege, aber Chrome hat unter Windows Passwörter ebenfalls als Klartext gehalten, oder tat das zumindest früher. Ich habe einmal bei einem Freund ein vergessenes Passwort aus Chrome Version 2021 herausgeholt.
  • Das ist zwar ein paar Jahre her, aber ich erinnere mich an Diskussionen, in denen Google-Entwickler sagten, sobald jemand Zugriff auf das lokale Dateisystem habe, sei ohnehin schon alles verloren.
  • Chrome hat 2024 App-Bound Encryption zu Cookie-Dateien hinzugefügt.