Neue Werkzeuge, alte Methoden. Wir entwickeln zurück und finden den schwerwiegenden Fehler von 1Password.

Jeder liebt Passwort-Manager. Sie sind aus vielen Gründen großartig. Persönlich habe ich mehr als 200 Einträge im Manager. Bei so vielen vertraulichen Daten an einem Ort ist es wichtig, das Ausmaß des Schadens zu verstehen, wenn Ihre Daten kompromittiert werden, sei es Malware, Exploits oder nur ein Computer, der einige Minuten lang unbeaufsichtigt bleibt. Die Washington Post hat kürzlich einen Artikel veröffentlicht, der auf unserer Studie basiert. Dieser Artikel macht die Leute darauf aufmerksam, dass nicht alle Passwort-Manager gleich sind.

Ich war fest davon überzeugt, dass ein gesperrter Passwort-Manager gut geschützt ist. Wenn jemand Zugriff auf meinen Computer erhält, kann das Maximum auf eine Reihe zufälliger Bytes zählen, da die Informationen zuverlässig aus dem Speicher gelöscht werden.

Dies gilt für 1Password 4 (Beachten Sie, dass die neueste Version heute die siebte ist). Bevor ich vor einigen Jahren darauf umgestiegen bin, habe ich überprüft, ob wirklich keine Passwörter im Klartext vorhanden sind, wenn sich der Manager in einem gesperrten Zustand befindet. Im Falle eines Kompromisses muss sich der Angreifer also mit verschlüsseltem Speicher befassen.


Der Tresor ist verschlossen!

In diesem Zustand gibt es keine Kennworteinträge oder ein Hauptkennwort. Sehr vernünftig und korrekt, und 1Password 4 hat diesen Test bestanden. Oder nicht?

Um langweilige Details loszuwerden, sage ich sofort: Wir konnten das Hauptkennwort von einer gesperrten Instanz in 1Password 4 wiederherstellen, wie unten gezeigt.


Entsperren Sie 1Password 4 und stellen Sie Ihr Master-Passwort wieder her

Die Animation zeigt, dass 1Password 4 zuerst auf normale Weise entsperrt und dann gesperrt wird. Danach führen wir unser Multipass- Dienstprogramm aus, das das Kennwort erfolgreich wiederherstellt. Das Dienstprogramm nutzt die falsche Verarbeitung des Kennworteingabefelds in 1Password 4 aus, um den verschleierten Hauptkennwortpuffer wiederherzustellen, ihn zu entschlüsseln, 1Password 4 automatisch zu entsperren und schließlich das Hauptkennwort in der Konsole anzuzeigen.

Langweilige Details

Der erste Schritt bei der Bewertung eines Kennwortmanagers besteht darin, im Speicher nach einem eindeutigen Hauptkennwort zu suchen. Dies ist in jedem Hex-Editor möglich, der mit dem Prozessspeicherplatz interagieren kann. Zum Beispiel der kostenlose HxD- Editor. Verwenden Sie diese Option, um den Speicherplatz für 1Password 4 zu öffnen.



Wir fallen sofort in den ersten lesbaren Bereich des 1Password 4-Speicherplatzes.


Beispiel für die Darstellung eines HxD-Speichers

Noch nichts Besonderes. Aber Sie können eine Suche durchführen. Wie sieht die Situation beispielsweise aus, wenn Sie das Kennwort in das Entsperrfenster von 1Password 4 eingeben, aber nicht auf die Schaltfläche "Entsperren" klicken:


Gesperrter Tresor 1Passwort 4 mit dem im Feld eingegebenen Hauptkennwort

Sicherlich ist das Passwort irgendwo im Speicher?

Wir öffnen HxD, aber die Suche nach einer Zeile mit unserem Hauptkennwort ("Z3Superpass #") führt nicht zu Ergebnissen.



Es scheint, dass 1Password das eingegebene Formular irgendwie verschlüsselt oder verschleiert. Wenn das Verfahren korrekt funktioniert, ist alles in Ordnung.

Tiefer tauchen

Um herauszufinden, warum das Hauptkennwort nicht im Speicher gefunden werden kann, wenn es im Dialogfeld zum Entsperren eindeutig vorhanden ist, sollten Sie den Code finden, der mit ihm interagiert. Es gibt verschiedene Möglichkeiten. Sie können die Verarbeitung von Tastatur- und Mausereignissen verfolgen, indem Sie 'GetMessage', 'PeekMessage', 'GetWindowText' oder andere Windows-APIs lokalisieren, die normalerweise Benutzereingaben verarbeiten. Wir finden also den Puffer, in dem Tastenanschläge aufgezeichnet werden, und gehen über sie zur Verschlüsselungs- / Verschleierungsroutine. Dies ist jedoch ein langer und fehleranfälliger Prozess, insbesondere bei großen Frameworks, die den Speicher manchmal sehr seltsam verwalten. Daher müssen Sie viele Kopien und Konvertierungen vornehmen, um den Puffer zu verfolgen.

Stattdessen verwenden wir unser eigenes Thread Imager-Tool, mit dem „seltsame“ proprietäre Protokolle auf Anwendungsebene rückentwickelt werden können. Es hilft Ihnen festzustellen, wo im Speicher 1Password 4 mit unserem Master-Passwort interagiert. Das Tool identifiziert "automatisch" Codebereiche in 1Password 4, die mit einem verschleierten Passwort interagieren (es hebt einfach die Anweisungen hervor, die mit den interessierenden Daten für die weitere Analyse interagieren). Das Ergebnis sieht ungefähr so ​​aus:


Thread Imager findet 1Password 4-Code, der mit einem nicht fokussierten Hauptkennwort interagiert

Da das Hauptkennwort in verschleierter Form im Speicher gespeichert ist, sollte das Tool zunächst anzeigen, wo die Verschleierung auftritt.

Ein Fragment aus dem ersten Ergebnis zeigt, dass das erste Auftreten des Hauptkennworts von einem Codeübergang von der Adresse 0x7707A75D zu 0x701CFA10 begleitet wird.


Ein detaillierter Eintrag in Thread Imager hebt den Codeübergang von 0x7707A75D zu 0x701CFA10 hervor, während sich EAX- und ECX-Register auf den Puffer mit dem Hauptkennwort beziehen

Die Untersuchung dieser Stelle 0x7707A75D im Debugger (x64dbg) bestätigt unsere Theorie. Zum ersten Mal tritt die Zeichenfolge 'Z3superpass #' auf, wenn die Decodierungsfunktion 'RtlRunDecodeUnicodeString' aus der Bibliothek ntdll.dll endet.



Nach einer kleinen Analyse ist klar, dass diese beiden Funktionen verwendet werden, um das Passwort zu verschleiern: 'RtlRunEncodeUnicodeString' und 'RtlRunDecodeUnicodeString'. Das Hauptkennwort ist also vor dem primitiven Kopieren aus dem Speicher verborgen, weshalb wir es früher im Hex-Editor nicht finden konnten.

Wenn Sie den codierten Puffer am Ende der Funktion RtlRunEncodeUnicodeString untersuchen, sieht die verschlüsselte Zeile mit dem Hauptkennwort folgendermaßen aus:


Verschlüsseltes Master-Passwort

Nach RtlRunDecodeUnicodeString 'wird es dekodiert:


Entschlüsseltes Master-Passwort

Interessanterweise wird dieser Bereich unter derselben Adresse 0x00DFA790 gespeichert, und wir können seine Änderung buchstäblich beobachten, wenn Sie ein Passwort in das 1Password 4-Entsperrfenster eingeben:

Sicherheitslücke

'RtlRunEncodeUnicodeString' und 'RtlRunDecodeUnicodeString' sind einfache Funktionen, die eine Zeichenfolge mit einer einfachen XOR-Operation ändern. Das ist nicht so schlimm: Es scheint die Standardmethode zum Maskieren aller nativen Windows-Bearbeitungssteuerelemente mit gesetztem Flag 'ES_PASSWORD' zu sein.

Das Problem ist, dass nach dem Entsperren von 1Password 4 das verschlüsselte Master-Passwort nicht aus dem Speicher gelöscht wird.

Schlimmer noch, es bleibt im Speicher, auch nachdem 1Password 4 gesperrt ist. Das heißt, wir haben einen gesperrten Kennwortspeicher, aber mit einem verschlüsselten Hauptkennwort im Speicher.

Und noch schlimmer, da wir mit dem Dialogfeld zur Eingabe des Hauptkennworts interagieren, wird derselbe Speicherbereich mit demselben XOR-Wert wiederverwendet, wodurch wir einfach auf den codierten Puffer zugreifen können, um einen Exploit zu erstellen.

Herausforderung

Um einen zuverlässigen Exploit für 1Password 4 zu erstellen, müssen Sie sich ein klareres Bild davon machen, wie das Hauptkennwort von den Workflows des Programms verarbeitet wird. Mit den oben genannten Tools haben wir ein Ausgabedatendiagramm erstellt (siehe Abbildung unten).



Dieses Diagramm erleichtert das Verständnis, wo und welche Bibliotheken beteiligt sind, um Bereiche im Speicher zuverlässig zu identifizieren, in denen Sie das Hauptkennwort abrufen können.

Ausnutzen

Was haben wir im Moment? Wir haben einen gesperrten Speicher, und irgendwo im Speicher wird ein verschleiertes Kennwort gespeichert, da das Programm den Speicher nicht ordnungsgemäß bereinigt hat.



Um es abzurufen, müssen Sie die Prozedur in 1Password 4 aufrufen, die 'RtlRunEncodeUnicodeString' und 'RtlRunDecodeUnicodeString' initiiert. Somit wird der Speicherort des Speicherpuffers mit dem codierten Hauptkennwort angezeigt.


Speicherbereich mit einem verschleierten Hauptkennwort

Ohne diesen Puffer müsste man in den Abgrund interner Prozeduren und Windows-Steuerelemente und zugehöriger Speicherverwaltungsmechanismen eintauchen. Vielleicht macht es diese Analyse einfach, einen Puffer zu finden, aber wir sind diesen Weg nicht gegangen.

Es scheint, dass die einzige Möglichkeit, 'RtlRunEncodeUnicodeString' und 'RtlRunDecodeUnicodeString' aufzurufen, darin besteht, das Hauptkennwort in das Zeichen im Dialogfeld einzugeben. So erhalten wir den gewünschten Puffer. Die Passwortlänge ist uns jedoch nicht bekannt.

Wir haben dieses Problem gelöst, indem wir Code abgefangen haben, der auf das erste Zeichen unseres Puffers zugreift, und einen Änderungsversuch blockiert haben. Diese Routine befindet sich in der Steuermeldungsschleife in comctl32, die die Puffersteuerung der entsprechenden Elemente übernimmt. Wenn Sie 'memmove' mit dem Offset 0x70191731 aufrufen, wird der Puffer mit dem eingegebenen Zeichen überschrieben:


(Nebeneffekt: Markierte Zeile (gelb) aktualisiert die gesamte Passwortzeile.)

Jetzt haben wir endlich alles, was wir brauchen, um einen Exploit zu erstellen. Mit den folgenden Schritten können wir das Hauptkennwort extrahieren:

1. Haken Sie 'memmove' ein, um zu verhindern, dass das erste Byte des Master-Passworts überschrieben wird.
   
2. Haken Sie 'RtlRunEncodeUnicodeString' ein, um den Speicherort des verschleierten Master-Passwortpuffers abzurufen.
   
3. Haken Sie 'RtlRunDecodeUnicodeString' ein, um auf den im vorherigen Schritt erhaltenen verschleierten Puffer zuzugreifen.
   
4. Geben Sie ein Zeichen in das Kennworteingabefeld ein und lehnen Sie Schritt 1 ab (Speichern des gesamten Hauptkennworts). Leiten Sie Schritt 2 zu Schritt 3 um, um das verschleierte Hauptkennwort zu dekodieren.

Um alle diese Aktionen auszuführen, erstellen Sie eine DLL mit dem Handlercode für alle diese Hooks. Die Bibliothek ist in den 1Password 4-Prozess eingebettet und sendet ein Zeichen an das Hauptkennwortdialogfeld, indem sie die Schritte memmove, RtlRunEncodeUnicodeString und RtlRunDecodeUnicodeString startet, die wir abfangen können - und unsere Magie ausführt, um das verschleierte Hauptkennwort wiederherzustellen. Der größte Teil der Magie geschieht im DetourRtlRunEncodeUnicodeString. Dies ist der Hook für die unten gezeigte Funktion 'RtlRunEncodeUnicodeString':



Damit kommen wir zum Endergebnis: Entsperren des gesperrten Repositorys 1Password 4 einer beliebigen Version mithilfe des von der Windows-API verwendeten fehlerhaften Verfahrens:

Zusammenfassung

Als wir uns zum ersten Mal mit den Innenseiten von 1Password 4 befassten, erwarteten wir ein komplexes Sicherheitssystem und erwarteten, dass alle vertraulichen Informationen aus dem Speicher gelöscht werden, wie dies bei PBKDF2-Prozeduren und anderen Bereichen der Fall ist, in denen das Hauptkennwort verwendet wird. Entsprechende Einträge werden ebenfalls gelöscht. Aufgrund von Versehen wird das Kennworteingabefeld jedoch als Standard-Windows-API-Steuerelement mit einem versteckten Kennwort betrachtet, was die Sicherheit von 1Password 4 untergräbt.