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.
(Bild: Shutterstock.com)
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.
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
- Remote Desktop via RDP: Liebstes Kind der Cybercrime-Szene
- Remote Desktop via RDP: Was genau ist das und wieso ist das böse?
- RDP: Testen und angreifen (27.4.)
- RDP: Best Practices für den sicheren Einsatz
Sofort am Start
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.
Verbindungsfragen
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.
(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.
Gefährliches RDP-Anmeldeverfahren
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.
(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.
Network Level Authentication
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.
Empfohlener redaktioneller Inhalt
Mit Ihrer Zustimmmung wird hier ein externes YouTube-Video (Google Ireland Limited) geladen.
Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit können personenbezogene Daten an Drittplattformen (Google Ireland Limited) übermittelt werden. Mehr dazu in unserer Datenschutzerklärung.
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.
Zwischenfazit
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)
