Mein LINEKDIN-Beitrag zum geteilten Link von Cyber Security News über die gefundene „Feature“ im RDP Dienst von Microsoft (eher das eine von Microsoft gesponsorte Backdoor) hat mich zur folgenden Frage gebracht:

Es stimmt anscheinend, dass es möglich ist, dass ein Benutzer sich ebenso mit einem vorherigen Kennwort über RDP auf einem System anmelden kann, auch wenn der Benutzer sich auf Systemen mit Multifaktor-Authentifizierung anmelden müsste. Hier würden die zusätzlichen Hürden ausgehebelt werden. Die Schwachstelle umgeht wohl effektiv die Cloud-Verifizierung, die MFA und die Richtlinien für den bedingten Zugriff (Conditional Access) und schafft so eine dauerhafte Hintertür für Angreifer, die sich alte Anmeldedaten verschafft haben, heisst es in dem veröffentlichten Bericht.

• Doch wie kommt man an solche oder ähnliche Anmeldedaten ran?

In diesem Moment ging mir ein kleiner Blitz auf, hergeleitet aus einer alten Erkenntnis, welches mit relativ überschaubaren Hürden ausgenutzt werden könnte, ebenfalls dank Microsoft.

Nun, es gibt nicht nur die Anmeldeinformationen für das System selbst, die der Einfachheit halber auf Systemen zwischengespeichert werden. Auch viele andere Anwendungen, die eine Netzwerkauthentifizierung benötigen, lassen ihre Benutzer-Credentials von Windows verwalten.

Ob eine einfache Anmeldung an einem SMB-Dienst, beispielsweise um ein Netzlaufwerk einzubinden, oder Netzwerk-Apps wie der Nextcloud Client oder OneDrive zu nutzen – für eine wiederholte, nahtlose Anmeldung werden die Zugangsdaten oft vom Windows-Betriebssystem gespeichert, inklusive Microsoft Live Accounts.

Ebenso werden Credentials auf dem Client-System hinterlegt, wenn etwa bei einer Terminal-Sitzung der Administrator bzw. der Benutzer das Häkchen bei der Funktion „Anmeldedaten speichern“ („Remember Me“) setzt. Dadurch müssen die Authentifizierungsdaten bei der nächsten Anmeldung nicht erneut eingegeben werden. Diese sind dann im Kontext eines Windows-Benutzers auf dem System verfügbar, und Microsoft vertraut an dieser Stelle auf die vorherige Authentifizierung.

Nehmen wir also einmal an, wir hätten die Möglichkeit, auf einen solchen Client zuzugreifen. Sei dies aus der Ferne über eine Schwachstelle, per eigener RDP-Verbindung mit gestohlenen Anmeldeinformationen des Benutzers oder aber auch physisch, weil die Person schlicht vergessen hat, die Station zu sperren, bevor sie sich vom Platz entfernt hat. Auch das Kompromittieren einer Workstation durch Zurücksetzen des Windows-Kennworts ist denkbar, z.B. mithilfe des utilman.exe Hacks, sofern die Festplatte nicht verschlüsselt ist, z.B. per Bitlocker. Der Rechner müsste nicht einmal entsperrt sein.

Nun, es gibt eine Möglichkeit, genau diese gespeicherten Credentials auszulesen und zu sichern. Dabei werden nicht etwa die Kennwörter im Klartext angezeigt. Vielmehr bietet Windows eine Funktion an, gespeicherte Zugangsdaten für Netzwerkanmeldungen jeglicher Art zu sichern und auf Wunsch wiederherzustellen.

Bei der Sicherung dieser Datei (oft im CRD-Format) erzwingt Microsoft zwar die Eingabe eines Kennworts zum Schutz. Dabei ist es für einen Angreifer, der bereits Zugang zum System hat, praktisch unerheblich, welches Passwort gewählt wird. Dieses wird nämlich lediglich bei der Wiederherstellung benötigt, um die Credentials auf ein anderes System laden zu können.

Sofern also der Zugang zu einem Client mit ausreichenden Rechten möglich ist – etwa bei einem der Administratoren im Netzwerk oder einem privilegierten Benutzer – ist das Kopieren dieser Credentials überraschend einfach. Hierzu muss mit der Tastenkombination WINDOWS + R das Ausführen-Fenster geöffnet und folgender Befehl eingegeben werden:

Der dabei eingegebene Befehl öffnet den Key Manager und zeigt in einem neuen Fenster alle hinterlegten Anmeldezeilen zu den jeweiligen Applikationen samt Benutzernamen an.

Rundll32 KeyMgr.dll,KRShowKeyMgr

Nach der Ausführung des Befehls erscheint ein Fenster, das die gespeicherten Einträge auflistet. Wurde von diesem System aus eine RDP-Sitzung in Richtung eines Servers aufgebaut und wurden dafür die Anmeldedaten gesichert, sieht man dort einen entsprechenden Eintrag, der oft als TERMSRV/<ZEIL> oder ähnlich benannt ist.

Jetzt muss man nur noch einen Speicherort auswählen (z.B. USB-Stick, sofern erlaubt), einmalig STRG+ALT+ENTF drücken und einen Sicherungskennwort eingeben, fertig.

Die so gesicherte Datei lässt sich dann bequem per USB-Stick mitnehmen, oder – falls noch Zeit und eine Internetverbindung bestehen – auf seinen eigenen Cloud-Speicher o.ä. hochladen.

Wofür konnte sich ein Angreifer noch interessieren, wenn er denn schonmal da ist:

Wenn man schon dabei ist, nimmt man natürlich auch diverse andere Zugangsdaten mit, die womöglich vom Benutzer im Browser hinterlegt wurden, z.B. für die bequeme Anmeldung auf Internetseiten. Auch die SAM Datei darf nicht vergessen werden. Der Export bzw. das Kopieren ist denkbar einfach 😉 Sie ist Teil der Windows-Registrierung und dient zur Speicherung von Benutzerkonten und Passwörter. Bei einem schlecht gewählten Passwort kann dieses, aufgrund des vorliegenden Hashwertes, durch einen Brute-Force-Angriff innerhalb weniger Minuten herausgefunden werden. Das Format der SAM Datei ist eine registry hive.

Zielort der SAM:

%windir%\system32\config\SAM

Befindet man sich beispielsweise im gleichen Firmennetz und hat der Benutzer sich zuvor auf einem SMB-Laufwerk angemeldet, kann man nun mit dessen entwendeten Credentials auf dem Laufwerk stöbern. Findet man dort weitere gespeicherte Credentials (z.B. für RDP), kann man versuchen, mit diesen auf die entsprechenden RDP-Server zuzugreifen – vorausgesetzt, diese sind erreichbar.

Empfehlungen an Systemadministratoren:

Da die Speicherung von Anmeldeinformationen durch Windows, so nützlich sie auch sein mag, erhebliche Risiken birgt und die Gefahr einer Kompromittierung nicht auszuschliessen ist, sollten Systemadministratoren hier aktiv werden (insbesondere von RDP-Zugängen auf Server eben durch die beschriebene Methode).

Es empfiehlt sich dringend, geeignete Powershell-Scripte oder ähnliche Mechanismen zu implementieren, die solche gespeicherten Anmeldeinformationen regelmässig pro Benutzer und Client entfernen. Bei Domainanmeldungen liesse sich dies einfach über einen Anmeldescript realisieren. Bei lokalen Anmeldungen ist dies z.B. über Remote Management Tools oder manuelle Richtlinien umsetzbar.

cmdkey /delete:Zielname

Auch Kerberos Tickets sollten regelmässig entfernt werden, z.B. mit dem Befehl:

klist purge

Strategische Empfehlung an System & Security Architekten sowie CIOs:

Am besten ist es natürlich immer, grundsätzlich auf starke Domain-Zugänge mit robusten Benutzer- und Gruppenpolicies zu setzen, immer individuelle/personenbezogene Benutzeraccounts zu erzwingen und eine leistungsfähige IAM-Lösung zu nutzen.

Beispielsweise ist die CoreOne Suite der Firma ITSENSE AG hierfür inzwischen eine Wunderwaffe, Swiss Made versteht sich. Dann lassen sich solche oder ähnliche, auch spezifische Schutzmassnahmen deutlich einfacher und effizienter implementieren und die Identitäten sowie schlussendlich die Systeme effektiver schützen.

Mit dem Wissen über diese neu entdeckte Schwäche in RDP sollten Server-Systeme ohnehin nicht mehr unmittelbar über RDP-Dienste erreicht werden können, selbst im eigenen Firmennetzwerk nicht. Für kritische Systeme ist bspw. eine Tier-Architektur unerlässlich. Denn es reicht nun unter bestimmten Umständen nicht mehr, dass im besten Fall bei Personalwechsel die Kennwörter generischer Accounts gewechselt werden. Individuelle Accounts sollten ja hoffentlich bei Austritt bereits gesperrt worden sein.

In solchen Fällen sind Zero Trust-Konzepte gar nicht mal so lästig 😉