Blog
Note: Für alle hier genannten Tools gilt wie immer: Verwendung unter eigener Gefahr.
Einführung
In Projekten, Schulungen und Vorträgen werde ich immer wieder gefragt, ob eine Remote Desktop Protocol (RDP) Verbindung sicher sei und wie eine sichere Verwaltung von Systemen mit RDP implementiert werden kann. In den meisten skizzierten Szenarien geht es darum eine Verbindung von System A über B nach C aufzubauen, wobei System C in vielen Fällen ein Domain Controller oder anderes sensibles System ist. Hier will ich nun einmal aufzeigen, was es aus der Sicht eines Angreifers bedeutet Systeme mit RDP zu verwalten.
RDP ist dafür gebaut und daher kennen es wohl auch die meisten, einen entfernten Computer so nutzen zu können, als säße man direkt davor. In der Praxis wird es daher meist für die Verwaltung von Servern eingesetzt oder auch zum Fehlerbeheben auf Clients. RDP besteht aus zwei Komponenten. Dem RDP-Host, der in allen Windows Systemen standardmäßig vorhanden ist (termsrv.dll) und einem Client (mstsc.exe). Neben dem Standardclient in Windows gibt es noch zahlreiche andere Clients.
Das Remote Desktop Protocol wird von Microsoft in MS-RDSOD spezifiziert. Es besteht aus verschiedenen Protokollen und über die Jahre sind zahlreiche Erweiterungen dazu gekommen. Eine gute Einführung in RDP findet ihr u.a. bei CyberArk.
Bevor wir in das Thema einsteigen, sei aber angemerkt, dass RDP niemals für den täglichen Einsatz oder zur Administration gedacht war. Der ursprüngliche Grund für die Entwicklung waren Notfallszenarien, wenn die gängigen Remote Administrationstools nicht mehr funktionierten. Daher empfehle ich generell, dass anstatt einer RDP Verbindung zum Verwalten eines Servers die Remote Server Administration Tools (RSAT) von einem dedizierten System aus verwendet werden sollen.
RDP Protokoll
Verschlüsselung
Microsoft RDP bietet zwei Arten von Verschlüsselung an. Zum einen die native RDP-Verschlüsselung oder auch “Standard Security” - je nach Quelle - die auf RC4 basiert. Neben der nativen RDP-Verschlüsselung bietet RDP auch die “Enhanced Security”, die mit TLS arbeitet. Hierbei verwendet RDP den Standard SSL/TLS Treiber (SChannel.dll) von Windows. Daher kann die RDP-Verschlüsselung analog zum IIS konfiguriert werden und die Einstellungen haben auch Auswirkung auf andere Bereiche im Betriebssystem.
Welche Art von Verschlüsselung für RDP verwendet wird, kann serverseitig beispielsweise mithilfe folgender Gruppenrichtlinie konfiguriert werden:
Computer Configuration > Policies > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Hosts > Security
Die Richtlinie “Require use of specific security layer for remote (RDP) connections” gibt an, ob Client und Server die Verschlüsselung selber aushandeln dürfen oder ob die Native RDP- bzw. die TLS-Verschlüsselung verwendet werden soll.
| Security Layer | Verschlüsselung |
|---|---|
| RDP | RC4 |
| Negotiate | Beste Verschlüsselung, die Server und Client unterstützen |
| SSL | Erzwingt TLS Verschüsselung |
Neben dieser Gruppenrichtlinie gibt es noch eine zweite Einstellung, die für die Verschlüsselung relevant werden kann. Die Gruppenrichtlinie heißt: “Set client encryption level”. Mit dieser Einstellung kann die Schlüssellänge für die native RDP-Verschlüsselung konfiguriert werden. Die Möglichkeiten laut Doku sind:
- 128 Bit (High Level)
- 56 Bit (Low Level)
- Abhängig von den Möglichkeiten von Client und Server (Client Compatible)
Die Einstellung verliert aber ihre Relevanz wenn TLS in der erst genannten Gruppenrichtlinie erzwungen wird.
Authentifizierung
Für die Anmeldung an RDP kann die sogenannte Network Layer Authentication(NLA) verwendet werden. Sie erlaubt es einem Client eine Anmeldung durchzuführen, noch bevor das eigentliche RDP-Protokoll zum Einsatz kommt. Die ursprüngliche Idee dahinter war es, Denial-of-Service-Angriffe zu erschweren, da eine RDP-Verbindung einiges an Ressourcen auf dem Server benötigt. Mit der heutigen Rechenleistung ist dies aber eher nebensächlich geworden. Heute besteht der Vorteil von NLA hauptsächlich darin, mögliche Exploits auf RDP zu verhindern bzw. zu erschweren.
Die NLA Einstellung kann über die Gruppenrichtlinie “Require user authentication for remote connections by using network level authentication” konfiguriert werden. Es gibt die Möglichkeit, NLA zu erzwingen oder nicht.
Einen sehr guten Artikel über das RDP-Protokoll und die Transportverschlüsselung von RDP findet ihr hier.
Verwendung von Pure-Vanilla RDP
Mal abgesehen von Schwachstellen wie Bluekeep und Co. sind Angriffe auf das RDP-Protokoll (also die Übertragung von Daten) selbst weniger interessant. Später komm ich noch auf Man-In-The-Middle-Angriffe zu sprechen. Für einen Angreifer ist die relevantere Frage: “Wo finde ich wann, welche Zugangsdaten?”. Daher betrachten wir hier einmal verschiedene Szenarien von RDP-Verbindungen.
Alle nachfolgenden Aktionen setzen Admin-/Systemrechte seitens des Angreifers voraus, wenn nichts anderes dabei steht.
Client
Bei einer normalen RDP-Verbindung ohne besondere Einstellungen sieht die Verbindung auf der Clientseite für einen Angreifer wie folgt aus:
Das Klartextpassworts vom Benutzer, mit dem wir uns am Zielsystem anmelden, kann im Klartext ausgelesen werden (siehe im Bereich ssp). Die entsprechende Rechte vorausgesetzt. Aber auch ohne erhöhte Rechte kann ein Angreifer an die Klartext-Zugangsdaten gelangen. Alles was er dafür können muss, ist Code im Kontext vom Benutzer ausführen. Dann kann er den Speicherinhalt vom MSTSC-Prozess (RDP-Client), der im selben Kontext ausgeführt wird, auslesen:
Wenn der Benutzer die Anmeldung mit dem gleichen Benutzer, wie er auch am Client angemeldet ist, verwendet, um auf einen Server zu springen, dann ist auch hier das Passwort einzusehen (siehe im Bereich ssp):
Neben dem Auslesen von Zugangsdaten, kann ein Angreifer immer auch ein KeyLogger verwenden, um die Eingabe von weiteren Daten oder Passwörtern mitzulesen.
Wenn Credential Guard auf dem Client installiert ist, werden bei einer normalen RDP-Verbindung im Hauptspeicher keine Anmeldeinformationen vom Benutzer gespeichert.
Server
Eine Anmeldung mittels RDP zählt in Windows zu den “RemoteInteractive” Anmeldungen und bietet damit dem Benutzer Single-Sign-On (SSO) innerhalb der Domäne. Aus diesem Grund werden auch alle für SSO notwendigen Daten wie der NT-Hash und das Kerberos TGT auf dem Zielsystem gespeichert. Für einen Angreifer sieht eine RDP-Verbindung auf dem Server wie eine lokale Anmeldung aus:
Somit hat ein Angreifer alle Informationen, die er für Pass-The-Hash und andere Lateral-Movement-Techniken benötigt. Weiterhin kann ein Angreifer, der mit System-/Adminrechten auf einem Zielsystem ist, die Zugangsdaten im Klartext aus dem Terminalserver-Dienst-Prozess auslesen:
Die Anmeldung als “Standard-Benutzer” und dann der Wechsel auf den Admin-Benutzer mittels UAC, sieht auf dem RDP-Server für einen Angreifer wie folgt aus:
Auch bei der UAC werden alle notwendigen Daten für SSO und damit für Pass-The-Hash im RAM abgelegt und sind damit für einen Angreifer auslesbar. Einzig das Klartext-Passwort aus dem Terminalserver-Dienst-Prozess kann bei dieser Methode nicht ausgelesen werden.
Ein Angreifer hat aber noch weitere Möglichkeiten, an die Zugangsdaten von eingehenden RDP Benutzern zu kommen. Mit ausreichend Rechten kann er beispielsweise Code in die LSASS.exe injizieren, um damit die Anmeldedaten in eine Datei ausleiten:
Alternativ kann er die LASS auch dazu bringen, eine DLL zu laden, die dasselbe tun würde. Dafür müsste er allerdings den Server neu starten, was in den meisten Fällen zu leicht zu entdecken ist. Weitere Informationen über memssp findet ihr u.a. hier.
Restricted Admin Mode
Der RestrictedAdmin Mode wurde mit Server 2012R2 eingeführt und dann für alle Versionen bis einschließlich Windows 7 implementiert. In diesem Modus überträgt Windows keine Zugangsdaten vom Client auf den Server. Statt einer Interaktiven Anmeldung nutzt Windows hier die Netzwerkanmeldung, die alleine mit NTLM bzw. Kerberos funktioniert. Der Nachteil dabei ist, dass kein echtes Single-Sign-On mehr möglich ist. Auf dem Zielsystem ist der Administrator mit seinem Benutzer angemeldet, für jede Interaktion im Netzwerk wird allerdings die Identität des Servers verwendet.
Um den RestricedAdmin Mode zu verwenden müssen folgende Voraussetzungen gegeben sein:
- Der Benutzer muss in der Gruppe der lokalen Administratoren auf dem Zielsystem sein
- Server: Es muss in
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsader Wert DisableRestrictedAdmin (REG_DWORD) mit dem Wert 0 angelegt sein - Client: Für den Client muss die Richtlinie
Restrict delegation of credentials to remote serversEnabled konfiguriert sein und der entsprechende Eintrag ausgewählt werden.
Für die Policy stehen drei Werte zur Auswahl:
- Require Remote Credential Guard: Hier wird Remote Credential Guard erzwungen.
- Require Restricted Admin: Hier wird der RestrictedAdmin Mode verwendet.
- Restrict Credential Delegation: Hier kann beides verwendet werden, wobei Remote Credential Guard bevorzugt wird.
Weitere Infos wir der Restriced Admin Mode aktiviert werden kann, findet ihr hier.
Dann kann auf dem Client mit dem Befehl mstsc.exe /restrictedAdmin der Client gestartet werden. Der Benutzer kann hier nicht gewechselt werden. Es wird automatisch der Benutzer genommen, der gerade angemeldet ist.
Client
Auf einem RDP-Client hinterlässt die Anmeldung mittels RestrictedAdmin Mode für einen Angreifer keine zusätzlichen Informationen, die nicht eh schon da sind.
Server
Auf dem Server sieht die Sitzung im RestrictedAdmin Mode wie folgt aus:
Wie im Bild zusehen ist, beinhaltet die Sitzung lediglich den Computernamen (SRV$) und den NTLM-Hash vom Computer. Also werden keine zusätzlichen Benutzerinformationen gespeichert.
Remote Credential Guard
Bei Remote Credential Guard (RCG) ist auf dem Zielsystem - dem Server - Credential Guard aktiviert. Die Konfiguration auf Client- und Serverseite und der Verbindungsaufbau von Remote Credential Guard funktionieren analog zum RestrictedAdmin Mode. Einziger unterschied ist, dass wenn RCG verwendet werden soll die mstsc.exe mit /remoteGuard gestartet werden muss.
Auf dem Zielsystem sind folgende Informationen für einen Angreifer einsehbar:
Wobei ich glaube, dass hier aktuelle Mimikatz nicht in der Lage ist, den Speicher korrekt auszulesen… dass sah mal anders aus. Ich werde das Bild, wenn Mimikatz wieder aktualisiert wurde, nachholen und ein korrektes hochladen. Wichtig ist nur, dass ein Angreifer beim RCG keine NT-Hashes oder Kerberos TGT auf dem Server im Hauptspeicher findet.
Pass-The-Hash
Der Nachteil, wenn der Wert: DisableRestrictedAdmin auf 0 gesetzt ist, ist, dass auch ein Angreifer kein Passwort mehr für die Anmeldung per RDP benötigt. Daher sind wieder klassische PTH Szenarien möglich.
RDP Man-In-The-Middle
In vielen Unternehmen ist eine PKI mittlerweile etabliert. Leider werden Zertifikate trotzdem häufig nicht flächendeckend eingesetzt. Bei dem Thema RDP fällt das besonders oft auf. Wer kennt folgende Warnmeldung beim Aufbau einer RDP-Verbindung nicht?
Häufig höre ich dann das Argument: “Ja das ist ja nur intern” oder Ähnliches. Ein Grund warum, dass dennoch nicht auf die leichte Schulter genommen werden sollte, sind Man-In-The-Middle Angriffe. Für RPD gibt es dafür u.a. Seth. Seth erlaubt es einem Angreifer die RDP-Verbindung über seinen eigenes System laufen zu lassen.
Im Detail sieht dass dann so aus:
Wenn eine Verbindung aufgebaut ist, können neben dem Klartext-Password auch Tastenanschläge und vieles mehr mitprotokolliert werden. Der Angriff funktioniert aber nur solange, wie Mitarbeiter darin geschult werden Zertifikatswarnmeldungen bei RDP-Verbindungen gekonnt zu ignorieren.
Shadowing
Mit RDP Shadowing kann sich ein Administrator in die Sitzung von einem Benutzer einklinken. Je nach Konfiguration der Sitzung, kann der Administrator entweder den Computer selber steuern oder einfach nur dem Benutzer zusehen. Aus Perspektive eines Angreifers ist die Sitzung auf der Clientseite uninteressant. Da der Administrator hier keine Zugangsdaten auf den Client überträgt. Auf der Serverseite hinterlässt der Administrator, der RDP-Shadowing einsetzt, außer einem Service-Ticket auch keine zusätzlichen Informationen.
Fazit
Aufgrund der Funktionsweise sind RDP-Verbindungen aus der Sicht eines Angreifers sehr interessant. Das kann ich auch aus der Praxis bestätigen. Sehr oft gelangt man als Angreifer im Rahmen eines Projektes auf einen Server, auf dem ein Benutzer, mit mehr Rechte innerhalb der Domäne angemeldet, als man selbst. Da dabei meist Pure-Vanilla RDP verwendet wird, dürften die Konsequenzen jetzt klar sein. In der Praxis rate ich daher in der Regel davon ab, RDP zu verwenden und die dafür von Microsoft entwickelten Administrator-Werkzeuge zu verwenden. Weiterhin fangen viele Kunden an das Microsoft Tier-Modell zumindest in Teilen umzusetzen um zu verhindern, dass ein Fileserver-Administrator an die Zugangsdaten von einem Domänenadministrator kommen kann, nur weil er zufällig einmal per RDP am Fileserver anmeldet.
Wie immer gilt falls ihr Fragen, Anmerkungen oder Verbesserungsvorschläge zu dem Artikel habt, schreibt eine Mail an info@hackmich.net.