Torsten Weber’s Blog

Bei der Verwendung der Terminal Services 6 (ist bei Vista automatisch dabei, hier für XP, hier für XP x64, hier für Server 2003, hier für Server 2003 x64) von Microsoft, kann die Meldung kommen:

Remotedesktop kann die Identität des Computers, mit dem Sie eine Verbindung herstellen möchten, nicht überprüfen.

Auf dem Remotecomputer wird eine ältere Windows-Version als Windows Vista ausgeführt.
Der Remotecomputer ist nur zur Unterstützung der RDP-Sicherheitsebene konfiguriert.

In nicht wenigen Foren wird bei der Frage nach einer möglichen Lösung zu dieser Meldung geraten, bei der Remotedesktopverbindung unter dem Reiter Leistung die Option Authentifizierungsoptionen auf den Wert Immer verbinden, auch wenn Authentifizierung fehlschlägt zu stellen. Das stimmt, es hilft und ist eine Lösung; aber ist auch eine gute? Denn sehr naheliegend wird durch obige Option eine Authentifizierung abgeschaltet. Nicht irgendeine, sondern die, dass der Remotecomputer auch tatsächlich der ist, welcher er sein soll. Das ist viel wichtiger, als vielleicht einem bewusst ist. Warum? Weil Situationen konstruierbar sind, in denen Datenströme zwischen Client und einem Zielsystem abgefangen werden können. Eine der bekanntesten Konstellationen heißt "man-in-the-middle" oder auf Deutsch "Mann in der Mitte".

So sind Remotedesktopverbindungen unsicher

Aus Sicht des Endanwenders (dem Clientsystem), der den Zielrechner mittels Remote Desktop erreichen will, stellt sich dabei die Verbindung zum Zielsystem sehr normal dar: Ein Clientsystem ist direkt mit dem Zielsystem verbunden, implizit über das Intranet bzw. Internet. Doch es ist anders!

Bei der Konstellation namens "Mann in der Mitte" fängt ein Rechner, ein kompromittiertes System, die Datenströme von dem Clientsystem ab und leitet ihn ans Zielsystem weiter und auch die Antworten vom Zielsystem wieder an das Clientsystem. Es ist wie das "Briefchen schreiben" zu Schulzeiten und prinzipiell auch mit gleichen Angriffsvektor. Der Zettel mit einem so wichtigem Inhalt wie "Willst du mit mir gehen?" wurde weitergereicht und noch bevor er beim Adressanten angekommen war, hatte es vielleicht schon die halbe Schulklasse gewusst (und ein Klassenkamerad auch noch laut vorgelesen). So könnte das auch beim Remote Desktop funktionieren, nur leicht anders. Die Datenströme zwischen Clientsystem und dem Zielsystem werden mitgeschnitten und auf die geheimen Daten untersucht, z. B. Benutzername und auch das Kennwort. Bei so einer Vorgehensweise nützt es auch nichts, dass die RDP-Verbindung verschlüsselt ist. Ein Kennwort kann also gerne 356 Zeichen lang sein, der Angriffsvektor bleibt bestehen.

Das oben erwähnte kompromittiere System meint dabei, dass der Angriff gar nicht unmittelbar über den "Mann in der Mitte" erfolgen muss, sondern es sich hier um einen Zombie-PC handeln kann, also einem Rechner, dessen Zugangsdaten schon ermittelt wurden und der für den "Mann im Hintergrund" arbeitet. So lassen sich ganze Zombie-, Bot-Netzwerke aufbauen und das ist mit ein Grund, warum derzeit täglich jeweils ca. 1 Milliarde Spam-E-Mails von großen Providern abgewehrt werden müssen.

Die Schwachstelle, sie heißt Angriffsvektor, bei Remotedesktopverbindungen findet sich im Abfangen der Authentifizierung wider. Genauer gesagt, wird vom Zielsystem an das Clientsystem ein Schlüssel (Public Key) und ein zufälliger Wert (Random Seek) verschickt. Das Clientsystem erzeugt seinerseits dann auch einen zufälligen Wert und sichert diesen mit dem Schlüssel. Aus beispielweise "123" wird so "K!F". Klingt doch aber sicher? Ja, ist es auch. Ebenfalls sicher ist, dass der erzeugte Schlüssel für die Sicherung der übertragenen Inhalte per Remotedesktopverbindung mit den beiden zufälligen Werten erzeugt und als sogenannter Sessionkey verwendet wird. Doch wie eben aus den obigen Bildern leicht erkenntlich ist, bleibt ungeprüft, wer den Public Key und den zufälligen Wert an das Clientsystem am Anfang verschickt. Das kann das Zielsystem sein aber eben auch ein kompromittiertes System. Da ist er, der Angriffsvektor und er kann z. B. über ARP-Spoofing technisch auch noch sehr einfach genutzt werden.

Mit ARP-Spoofing wird der Netzwerkverkehr zwischen Clientsystem und Zielsystem überwacht und dann der zufällige Wert mitgelesen und der Schlüssel vom Zielsystem mit einem anderem ausgetauscht. Jetzt verschlüsselt das Clientsystem seinen zufälligen Wert mit dem ausgetauschten Schlüssel und jetzt ist alles da, was der "Mann im Hintergrund" braucht, um die Verbindung im Klartext überwachen zu können. Die Verschlüsselung von RDP-Verbindungen und starke Kennwörter schützen also nicht. Die Kommunikation kann nur über einen zusätzlichen Schritt sicher gemacht werden: In dem das Zielsystem sein Zertifikat an das Clientsystem schickt (Zertifikate stellen über ein technisches Verfahren sicher, dass A wirklich A und nicht B ist). Leider ist Microsoft hier ein gravierender Fehler unterlaufen¹.

Microsoft hat ein Zertifikat im Betriebssystem hinterlegt (genauer: mit privaten, hardcordierten Schlüssel) und zwar in einer Datei. Jeder Rechner wiederum, der die selbe Version dieser Datei besitzt und an der Kommunikation beteiligt ist, ist damit aus Sicht des Clientsystems immer A, egal, ob er eigentlich nun in Wirklichkeit B ist. Microsoft hat diese Problematik erkannt: Seit Windows 2003 Service Pack 1 kann die Verbindung zusätzlich mittels Transport Layer Security (TLS ist die Weiterentwicklung von SSL) geschützt werden, nur sollte man es eben auch einsetzen. Zumal es nichts kostet², nicht Alex? ;P

Ein virtuelles privates Netzwerk ist unabhängig davon als weitere Sicherungsmaßnahme möglich. Eine Authentifizierung ersetzt es aber nicht, denn schließlich kann z. B. auch ein Intranet infiltriert werden.

So werden Remotedesktopverbindungen sicher

Mit folgenden Schritten ist der Angriffsvektor ausschließbar, wenn das Zielsystem Vista/Server 2003 ist³:

• (Terminal Services 6 installieren, ist bei Vista dabei, für andere Betriebssysteme siehe oben)
• bei Remotedesktopverbindungen ist die Option Authentifizierungsoptionen auf den Wert Warnung anzeigen, falls Authentifizierung fehlschlägt zu stellen
• auf dem Server ist Start, Verwaltung, Terminaldienstekonfiguration, Verbindungen zu wählen
• dort ist die genutzte Schnittstelle, standardmäßig RDP-Tcp, doppelt anzuklicken
• dann ist beim Reiter Allgemein und bei der Sicherheitsstufe der Wert TLS bzw. SSL einzustellen
• dann ist auf Bearbeiten zu klicken, ein Zertifikat auszuwählen und auf OK und OK zu klicken

Dann ist der Angriffsvektor behoben wie es auch bei einer bestehenden Remotedesktopverbindung im Vollbild angezeigt wird. Stimmt irgendetwas bei der Einwahl nicht, kommen entsprechende Warnungen⁴.

Vista, Server 2003 vs. XP, Server 2000

Die Authentifizierung mittels der genannten Schritten funktioniert nur, wie weiter oben erwähnt, wenn das Zielsystem Vista, Server 2003 (oder höher) ist. Ob auf dem Zielsystem die beschriebene Authentifizierung unterstützt wird, lässt sich auch über eine Remotedesktopverbindung herausfinden. Auf dem Zielsystem ist nur der Remotedesktopverbindung-Client zu starten und auf das Symbol links oben zu klicken und der Menüpunkt Info zu wählen (von dem Clientsystem aus kann also nicht die Unterstützung des Zielsystems für Authentifizierung auf Netzwerkebene ermittelt werden):

Dort erscheint also logischerweise auf dem Zielsystem wie Vista, Server 2003 oder höher:

Authentifizierung auf Netzwerkebene wird unterstützt.

Und ansonsten:

Authentifizierung auf Netzwerkebene wird nicht unterstützt.

¹ siehe auch Kleiner Lauschangriff gegen Windows-Fernwartung
² entsprechende Zertifikate außen vor gelassen, die aber auch günstig erhältlich sind
³ bei Windows XP und Server 2000 muss mit IPSec gesichert werden
⁴ mehr zu "man-in-the-middle" und anderen Angriffsvektoren gibt es hier