Prologue

Die Speicherung von Klartextdaten im Prozessspeicher ist ein Problem für die Cybersicherheit. Diese Schwachstelle hat sogar ihre eigene Klassifizierung: CWE-316: Cleartext Storage of Sensitive Information in Memory

Malware auf dem Gerät eines Nutzers ist meist in der Lage den Speicher anderer Prozesse zu lesen und diese Daten ausnutzen. Ein ernstes Problem sind Passwörter und andere sensible Daten, die ein Programm vorübergehend im Speicher abgelegt hat (beispielsweise durch die Eingabe von Anmeldeinformationen durch einen Benutzer) und die nicht verschlüsselt sind.

Es gibt keine einfache Lösung für dieses prinzipbedingte Problem, aber es gibt Möglichkeiten für Work-Arounds. Die Entwickler können strenge Richtlinien für die Datenverschlüsselung befolgen, aber sobald die Daten entschlüsselt und in den Hauptspeicher geladen sind, liegen sie im Klartext vor.

Anwendungsentwickler müssen dafür sorgen, dass die Daten aus dem Speicher gelöscht oder zumindest sicher überschrieben werden, wenn

• die Anwendung geschlossen wird,
• der Benutzer die Informationen bereits angesehen hat oder
• diese schlicht nicht mehr benötigt werden, beispielsweise nach dem Abmelden eines Benutzers oder der Registrierungsprozess beendet ist.

Andernfalls sind sie auch für andere Anwendungen zugänglich, die die Daten lesen können. So wird zumindest das Zeitfenster für einen potentiellen Angriff minimiert.

Die Studie

Im Rahmen des für secuvera-Mitarbeiter zur Verfügung stehenden, intern stattfindenden Labdays, führten wir eine Studie bezüglich sensibler Informationen im Prozessspeicher von Windows Desktop Anwendungen mit Sicherheitseigenschaften durch. Andere Betriebssysteme haben wir nicht untersucht. Wir wollten wissen, ob Anwendungen im Sicherheitskontext ein hohes Niveau aufweisen.

Hierbei wollten wir konkret darauf prüfen ob nach dem verwenden und anschließendem Abmelden von verschiedenen Anwendungen, insbesondere Passwörter im Prozessspeicher verblieben. Es wird also nach der Existenz von sensiblen Informationen gesucht, nachdem diese eigentlich nicht mehr benötigt werden.

Dies würde beispielsweise VPN-Anwendungen oder Passwortmanager betreffen die nach Verwendung und anschließender Abmeldung eines Nutzers, dessen Informationen immer noch im Prozesspeicher behalten, anstatt diesen sicher zu überschreiben.

Getestet wurden die folgenden Anwendungen.

• OpenVPN
• NordVPN
• CyberGhost VPN
• Mullvad
• ProtonVPN
• Parsec
• Kaspersky
• GData
• Keepass
• HeyLogin
• XXX[1]
• PureVPN / PureKeep / PureEncrypt
• 1password
• BitWarden

Wie wurden die Schwächen gefunden?

Unsere Teststrategie bestand darin, alle Anwendungen in einen Zustand zu versetzen, in dem sensible Informationen bereits eingegeben wurden, und uns dann wieder abzumelden, ohne den Prozess zu beenden. Da nun kein Nutzer mehr angemeldet ist, sollten die Informationen des vorherigen Nutzers nun nicht mehr verfügbar sein.

Wir haben untersucht, ob die getesteten Anwendungen Informationen von vorherigen Benutzern hinterlassen und ob sie zusätzlich anfällig für Speicherscans sind, die unter dem verwendeten Windows-Standardbenutzer (kein Administrator, keine Administratorrechte) gestartet werden.

Unserer Erwartung nach sollten sämtliche sensiblen Informationen im Speicher nun überschrieben und somit unzugänglich für Malware oder manuelle Angreifer sein.

Wir haben ProcessHacker2 zum Auslesen des Speichers anderer Prozesse verwendet.

ProcessHacker bietet die Funktion den Speicher eines Prozesses live zu durchsuchen. Entsprechend haben wir nach unseren Anmeldeinformationen im Speicher der Anwendungsprozesse gesucht. Diese sollten ja nun nicht mehr im Klartext im Prozessspeicher vorliegen oder? Naja….

Neben dem ProcessHacker Tool verwendeten wir auch den ganz normalen Windows Taskmanager um ein Abbild eines Prozesses zu erstellen. Dieses Abbild haben wir anschließend nach Strings durchsucht. Die Ergebnisse waren teilweise erschreckend.

Nachfolgend haben wir einmal detailliert dargestellt wie wir einen häufig verwendeten Passwortmanager analysiert haben und was wir darin finden konnten.

Zu allererst haben wir uns einen Account für den zu testenden Passwortmanager erstellt und uns mit diesem an der Applikation angemeldet. Geprüft wurde übrigens die zum Testzeitpunkt aktuellste Version.

Anschließend haben wir einen Passwort-Eintrag erstellt und uns dann direkt wieder abgemeldet. Das angelegte Passwort sollte nun ja eigentlich nicht mehr im Prozessspeicher einsehbar sein. Jedenfalls macht es keinen Sinn es im Prozessspeicher zu behalten. Nicht versierte Nutzer werden zwar nun abgehalten das gespeicherte Passwort einzusehen, aber können auch versierte Angreifer abgehalten werden die sensiblen Informationen auszulesen? Wir schauen mal weiter.

Nach Abmelden und einem kurzen Speicherscan konnten wir doch tatsächlich sowohl unser Masterpasswort, als auch unser im Passwortspeicher „gesichertes“ Passwort im Speicher des Prozesses wieder finden.

Aber da ist noch mehr. Dieser Passwortmanager funktioniert so, dass er sich im Hintergrund an einen Server verbindet, die eingegebenen Anmelde-Informationen überprüft und anschließend den Zugang gewährt oder verwehrt. Es wäre sicherlich nicht gut wenn auch diese Kommunikation im Prozessspeicher einsehbar wäre.

Diese Informationen sehen zwar auf den ersten Blick nicht so kritisch aus, jedoch erlauben Sie einen Zugang über das Webportal des Passwortmanagers. Angreifer müssen somit auch gar nicht spezifisch nach einem Benutzernamen oder Passwort suchen. Eine schlichte Suche nach dem Wort „hash“ reicht bereits aus. Nehmen wir jetzt diese Informationen können wir uns einfach im Webportal anmelden und erhalten Zugriff auf unsere gespeicherten Kennwörter. Ein Angreifer muss nicht einmal den Hash knacken. Es reicht schlicht diesen in den Loginrequest an das WebPortal einzutragen.

Was haben wir sonst noch gefunden?

Bei der Analyse wurde bei mehreren Applikationen festgestellt, dass Informationen im Prozessspeicher zurückblieben.

Besonders erschreckend fanden wir, wie transparent manche Passwortmanager tatsächlich sind. Der Sinn eines Passwortmanagers ist es unter anderem Passwörter lokal sicher zu speichern.

In der folgenden Liste haben wir unsere weiteren Testergebnisse einmal detailliert aufgeführt.

Reaktionen der Hersteller

Mit diesem Blog-Post möchten wir auf die Veröffentlichung CVE-2024-26330 des Produkts Cyberghost VPN hinweisen.

Ein Patch eines weiteren namhaften großen VPN-Produkts wird zu dem noch im dritten Quartal mit der CVE-2024-5476 erwartet. Bis zum Patch hat uns der Hersteller darum gebeten, den Namen in Kombination zur CVE noch nicht zu nennen.

Alle in der Studie geprüften Hersteller wurden informiert.

Neben den genannten zwei Herstellern waren jedoch keine weiteren Firmen bereit, die Feststellungen als Schwachstellen anzuerkennen und zu patchen. Einige haben dies wenigstens begründet. Manche antworteten, dass dies ist auf die eigene Threat-Modelierung zurückzuführen, welche einen lokalen Angriff auf ihre Desktop-Anwendungen nicht berücksichtigt. Wirklich schade.

Wie schlimm sind jetzt die Findings?

Grundsätzlich sollten von Software, noch dazu im Sicherheitskontext, zu erwarten sein, dass sensible Informationen nur so lange im Speicher residieren, wie sie nötig sind. Sicher ist „nur“ die  E-Mail-Adresse auslesen zu können etwas anderes als Informationen auszulesen, die eine volle Accountübernahme ermöglichen. Wir hätten gerne mit den Herstellern an einer gemeinsamen Schweregradeinschätzung nach CVSS gearbeitet. Das war aus benannten Gründen leider nicht bzw. nur selten möglich. Wir versuchen textuell zu erläutern, was man mit den Findings anstellen kann, so dass die Leser:innen sich selbst ein Bild machen können.

Hintergrundinfos zu diesem Beitrag:

• Responsible Disclosure Policy bei der secuvera
  secuvera setzt auf das sog. Responsible Disclosure Verfahren, bei dem alle gesammelten Details zur Schwachstelle an Hersteller übermittelt werden, sodass diese in der Lage sind, die Schwachstelle nachzuvollziehen und zu beseitigen. Erst nach erfolgreicher Behebung des Problems in einem dafür als angemessen empfundenen Zeitraum, sowie einer Karenzzeit zur Einspielung der Behebung durch Anwender werden Informationen über Schwachstellen in Form eines Advisories veröffentlicht. Wenn ein Hersteller das Problem jedoch nicht anerkennen mag oder keine Reaktion auf unseren Kontaktversuch zeigt, wird die Beschreibung der Schwachstelle früher veröffentlicht, auch wenn kein Fix bereit steht.
• Über Labdays
  Jeder Mitarbeiter der secuvera GmbH kann einmal im Monat einen Labday durchführen. Der Labday dient zur persönlichen Weiterbildung der Mitarbeiter, indem neue Angriffstechniken unter Laborbedingungen nachvollzogen werden oder nach Schwachstellen in Produkten geforscht werden können.

[1] der bekannte Hersteller eines Passwortspeichers hat ist auf uns nach der Veröffentlichung des Aritkels zugekommen. Wir sind in Kontakt. Wenn es Neuigkeiten gibt, aktualisieren wir die Seite erneut.

Hinweis zu Änderungen im Artikel