Remote Desktop via RDP: Was genau ist das und wieso ist das b?se? (2/4)

Remote Desktop bietet verschiedene Modi, die man kennen sollte. Denn einige davon sind gef?hrlich und trotzdem standardm??ig aktiv.

Lesezeit: 4 Min.
In Pocket speichern
vorlesen Druckansicht Kommentare lesen 116 Beitr?ge

(Bild: Shutterstock.com)

Von

Diese Serie zum Remote Desktop Protocol (RDP) soll vor allem Admins für die damit verbundenen Gefahren sensibilisieren und ihnen helfen, sich davor zu schützen. Der erste Teil RDP: Liebstes Kind der Cybercrime-Szene erl?uterte, wie Cyber-Kriminelle RDP in gro?em Stil missbrauchen. Die aktuelle Folge erkl?rt, wie RDP arbeitet und an welchen Stellen dabei sicherheitsrelevante Probleme auftauchen.

Weitere Folgen der Serie zum Remote Desktop Protocol

Der Autor Jürgen Schmidt bereitet den Inhalt der kompletten Serie auch gezielt für Administratoren in einem heise-Security-Webinar auf: Homeoffice und Administration via Remote Desktop - das sollten Admins wissen

Das Remote Desktop Protocol (RDP) übertr?gt den kompletten Windows Desktop auf einen anderen PC. Passende Client-Programme gibt es für alle Plattformen. Mit einem solchen l?sst sich der Windows-Rechner mit RDP-Freigabe dann komplett aus der Ferne bedienen. Der Anwender bekommt ein Fenster, in dem all seine Tastatur- und Mauseingaben direkt auf den RDP-Zielrechner landen. Auch spezielle Ressoucen wie Drucker, USB-Ports, Mikrofon und Tonausgabe lassen sich umleiten.

RDP kommt h?ufig zur Administration von (virtuellen) Windows-Servern zum Einsatz, hat aber auch für Desktop-Systeme seine Berechtigung (erfordert aber Windows Pro oder h?her). Au?erdem bietet sich RDP natürlich für die Fernwartung an, weil man als Admin schnell mal aus der Ferne nach dem Rechten sehen oder etwas geradebiegen kann. Wie man RDP konkret nutzt und einrichtet, erl?utern die c't-Artikel Remotedesktopverbindung: Der praktische Fernzugriff auf Windows 10 und Windows Server als Terminalserver einrichten, in denen jedoch die Sicherheitsaspekte nur am Rande vorkommen. Wenn man die hinzu nimmt, wird es n?mlich recht schnell kompliziert.

Technisch l?uft RDP auf dem TCP-Port 3389. Um die Sicherheit der Verbindungen ist es jedoch nicht gut bestellt. So beherrscht RDP zwar bereits seit Windows Vista Transport Layer Security (TLS/SSL), was bedeutet, dass alle Daten und insbesondere der Anmeldevorgang durch dessen gute Verschlüsselung vor Lauschern im Netz geschützt sind. Doch viele Windows-Systeme bestehen nicht darauf, sondern akzeptieren immer noch die unzureichende Verschlüsselung via "RDP Security"

Diese Standard RDP Security sieht unter anderem l?ngst kaputte Verfahren wie RC4 mit 40-Bit-Schlüsseln vor. Darüber hinaus sind dabei alle Private Keys der RDP-Server mit dem gleichen, ?ffentlich bekannten Microsoft-Schlüssel signiert. Ein Angreifer kann diese also perfekt imitieren und sich als das Ziel eines Verbindungsversuchs ausgeben, um Zugangsdaten mitzulesen. Auf den Punkt gebracht: Standard RDP Security ist unsicher und sollte nicht mehr zum Einsatz kommen. Trotzdem ist sie in vielen F?llen aus Gründen der Rückw?rts-Kompatibilt?t noch aktiv.

Solche Zertifikatswarnungen geh?ren zum RDP-Alltag. Wer sie ignoriert, riskiert, dass Angreifer sein Passwort mitlesen.

(Bild:?Screenshot)

Aktuell arbeitet RDP bevorzugt mit der Enhanced Security, bei der TLS zum Einsatz kommt. Doch auch damit ist ein Angreifer noch lange nicht ausgesperrt. Denn die identit?tsstiftenden Zertifikate sind standardm??ig lediglich selbstsigniert. Das hei?t, der Client kann ein echtes nicht von einem gef?lschten Zertifikat unterscheiden und erzeugt eine Zertifikatswarnung für den Anwender.

Hinzu kommt, dass es anders als im Web keine einheitliche Namenskonvention für RDP gibt. Das RDP-Zertifikat ist normalerweise auf den Namen des Windows-Rechners ausgestellt, der Zugriff erfolgt dann aber etwa über einen anderslautenden DNS-Namen oder seine IP-Adresse. Die Folge sind noch mehr Zertifikatswarnungen und Anwender, die darauf trainiert sind, diese Warnungen bei der RDP-Nutzung zu ignorieren. Und wer Zertifikatswarnungen ignoriert, ?ffnet damit Tür und Tor für einen Angreifer in der Position des Man-in-the-Middle, der alles mitlesen kann – einschlie?lich der Zugangsdaten.

Apropos Zugangsdaten: Die Authentifizierung des RDP-Nutzers erfolgte früher über den normalen Windows-Anmeldemechanismus. Der Anwender erhielt dabei nach dem Verbindungsaufbau den Anmeldebildschirm des Ziel-PCs – genauso wie er sich etwa nach einem Neustart des Rechners pr?sentiert. Dabei hat ein Angreifer bereits vor einer Anmeldung – also ganz ohne gültige Zugangsdaten – Zugriff auf einen betr?chtlichen Teil der RDP-Funktionalit?t. Sein Client handelt Parameter mit dem Server aus, dieser übertr?gt ihm den Anmeldebildschirm und nimmt schlie?lich Benutzernamen und Passwort entgegen.

Viele RDP-Systeme erlauben als Fallback immer noch die Anmeldung über den Windows-Login und pr?sentieren unter anderem die Benutzernamen auf dem Silbertablett.

(Bild:?Screenshot)

All das erzeugt Last auf dem System und l?sst sich für Denial-of-Service-Angriffe missbrauchen. Aber es ist auch angreifbarer Code, der Sicherheitslücken enthalten kann. Dass dies kein theoretisches Problem ist, zeigte letztes Jahr die sogenannte BlueKeep-Lücke (CVE-2019-0708). Das war eine kritische Lücke im RDP-Dienst, die sich ausnutzen lie?, um fremden Code einzuschleusen und auszuführen (Remote Code Execution).

Als BlueKeep bekannt wurde, waren auf einen Schlag über 1 Million Windows-Systeme angreifbar und h?tten sogar von einem sich selbst weiterverbreitenden Wurm übernommen werden k?nnen. Trotzdem werden die von Microsoft bereit gestellten Patches l?ngst nicht überall eingespielt. Allein in Deutschland sind noch über 5000 aus dem Internet erreichbare RDP-Systeme für BlueKeep anf?llig.

Auch ganz ohne Fehler und Lücken offenbart diese RDP-Authentifizierung die Benutzernamen der auf dem System vorhandenen Benutzer und erleichtert somit Brute-Force-Angriffe auf deren Passw?rter. Das systematische Durchprobieren g?ngiger Passw?rter klappt so oft, dass es RDP in der Szene auch die Verballhorung "Really Dumb Passwords" einbrachte.

Microsoft empfiehlt deshalb schon seit Jahren, Network Level Authentication (NLA) einzusetzen. Dabei erfolgt die überprüfung der Identit?t sehr früh im Aufbau der Netzwerkverbindung – also bevor RDP-spezifische Funktionen zum Einsatz kommen. BlueKeep l?sst sich damit nicht mehr ohne gültige Zugangsdaten ausnutzen. ?hnliches gilt auch für die meisten anderen, in den letzten Jahren bekannt gewordenen RDP-Schwachstellen, die sich Remote ausnutzen lie?en. Und gültige Benutzernamen verr?t RDP mit NLA auch nicht mehr.

Darüber hinaus verwendet NLA im Idealfall das CredSSP-Protokoll (Credential Security Support Provider), um eine starke Serverauthentifizierung über SSL/TLS- oder Kerberos durchzuführen, die vor MITM-Angriffen schützen sollen. Insbesondere erm?glicht es CredSSP prinzipiell, dass man auch mit selbstsignierten Zertifikaten sichere Verbindungen herstellen kann.

Damit das tats?chlich vor Man-in-the-Middle-Angriffen schützt, müsste man jedoch einen künstlichen Downgrade auf schw?chere Authentifizierungsverfahren verhindern. Dieses Downgrade ist jedoch standardm??ig erlaubt. Der Sicherheitsexperte Adrian Vollmer demonstriert sogar in einem Video, wie er auch bei aktivem NLA auf dem Server das Passwort eines Dom?nen-Administrators mitschneiden kann.

Angriff auf RDP als MITM

Durch das Downgrade auf unsichere Verfahren kann der Angreifer im LAN die Zugangs-Credentials eines Domain-Admins ergattern.

Solche Angriffe kann auch das Verbergen der RDP-Funktionen in einem VPN nicht ausschlie?en. Sobald ein Angreifer einen Rechner innerhalb des Firmennetzes kontrolliert – etwa nach einer Trojaner-Infektion durch Emotet – besteht die Gefahr, dass er sich dort in die Position des Man-in-the-Middle bringt und RDP-Zugangsdaten abgreift. Im Extremfall gelingt es ihm dabei, Domain Admin Credentials zu erbeuten und damit das komplette Active Directory der Firma zu übernehmen – was einen GAU für die Firmen-IT bedeutet.

Das einzige, was einen solchen Angriff unter Umst?nden dann noch verhindert, ist eine Warnung zur Identit?t des Servers. Bricht der Anwender den RDP-Login an dieser Stelle ab, geht der Angreifer leer aus. Die Erfahrung zeigt aber, dass viele Anwender solche Warnungen gerade im Kontext RDP einfach übergehen, weil sie quasi zum Alltag geh?ren.

Standard RDP Security sollte man nicht mehr einsetzen; aber allein das Aktivieren von NLA beseitigt noch l?ngst nicht alle Probleme. Die immer noch m?glichen Downgrades der Security erm?glichen einem Man-in-the-Middle weiterhin Downgrade-Angriffe (PDF), mit dem Ziel Zugangsdaten mitzulesen zu k?nnen.

Administratoren sollten also sicherstellen, dass NLA, TLS und CredSSP richtig eingerichtet und Zertifikate von einer Firmen-CA sauber signiert sind. Damit ist der Betrieb von RDP bei weitem nicht mehr so einfach, wie es anfangs schien. Im Gegenteil hat man es mit einer komplexen Mischung aus verschiedenen Konzepten und Techniken zu tun, die alle richtig eingerichtet werden müssen. Im schlimmsten Fall genügt sonst schon ein falscher Klick auf eine Zertifikatswarnung und der Angreifer hat das Passwort des Benutzers.

Zu überprüfen, ob man selbst anf?llig für eines der geschilderten Probleme ist, gestaltet sich nicht ganz einfach. So bevorzugen alle aktuellen RDP-Clients NLA, man bekommt also im Normalfall die Windows-Anmeldung via RDP gar nicht mehr zu Gesicht. Sie ist jedoch in vielen F?llen im Hintergrund nach wie vor gestattet und erst gezielte Tests f?rdern das zu Tage. Wie Sie das und die anderen geschilderten RDP-Probleme effizient selber überprüfen k?nnen, erkl?rt der n?chste Teil: RDP testen und angreifen. Darüber hinaus bereitet der Autor der Serie Jürgen Schmidt den gesamten Inhalt der Serie auch gezielt für Administratoren in einem heise-Security-Webinar auf: Homeoffice und Administration via Remote Desktop - das sollten Admins wissen.

(ju)

汤姆叔叔影院