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

7-Zip ist eine Anwendung zur Komprimierung von Daten und deswegen so interessant, weil es sehr viele Freiheitsgerade bei der Erstellung eines Archives erlaubt, u. a. die Anzahl der Kerne, die die Anwendung verwenden soll. Die Anwendung gibt es hier und 7z als Format auch plattformübergreifend.

Unter Vista fällt auf, dass zwar bei beliebigen Dateien bei einem Klick mit der rechten Maustaste darauf, ein Kontextmenü 7-Zip kommt, doch die Dateien ein Icon für einen unbekannten Dateityp besitzen. Zwar kann auf jede Datei, z. B. eine Textdatei (.TXT)  mit der rechten Maustaste geklickt und das Kontextmenü 7-Zip ausgewählt werden, aber es geht mit einen paar Schritten auch einfacher und Icons sind korrekt darstellbar. Ein Icon eines mit 7-Zip verknüpften Dateityps sieht dann so aus:

Folgende Schritte sind dazu notwendig:

• auf Start klicken
• "7 Zip" eingeben
• mit der rechten Maustaste auf 7-Zip File Manager klicken und Als Administrator ausführen wählen
• in der danach gestarteten Anwendung 7-Zip Extras, Optionen, System wählen
• dort entweder Alles auswählen anklicken oder die gewünschten Dateiendungen selektieren
• auf OK klicken

Diese Fehlermeldung unter Vista, die durch einen Installer u. a. bei der Installation von Software für eine Logitech QuickCam kommt, lässt sich mit der gleichen Lösung wie für iTunes und die Meldung VBScript ist nicht installiert beheben.

Vista wird mit einer Minianwendung zur Berechnung von Fremdwährungen durch Microsoft ausgeliefert: dem Währungsrechner. Nein, dieser Beitrag handelt sich nicht um eine sinnvolle Risikodiversifikation, es geht darum, ob das verantwortliche Produktteam hier geschusselt hat. Wer Frank Fischers Blogeintrag Sorry, no Schadenfreude allowed!! zu einem "interessanten" Programmierfehler in Excel gelesen hat, wird es vielleicht schon ahnen: Die Ergebnisse der Minianwendung sind etwas fraglich.

Um den Wert einer Währung, als Beispiel "18,50 USD ist wie viel Wert in EUR" zu ermitteln, muss nur die Minianwendung in der Sidebar bzw. dem Desktop hinzugefügt, EURO und US-DOLLAR ausgewählt und 18,50 bei US-DOLLAR eingeben werden. Schon erscheint das Ergebnis, auch noch auf ganze fünf Stellen nach dem Komma genau.

Doch was heißt Komma? Das, was unter Start, Systemsteuerung und dort bei Region beim Reiter Regions- und Sprachoptionen über Dieses Format anpassen bei Dezimaltrennzeichen eingestellt ist? Denn wird nicht 18,50 sondern 18.50 eingegeben, findet die Umrechnung mit 1850 als Basis statt. Auch ist egal, wie viele Dezimaltrennzeichen eingegeben werden. Egal ob "," oder ".". Das Ergebnis bleibt falsch bzw. richtig.

 
 

Es geht weiter: -1850 ist eine ungültige Zahl, aber -18.50 ist eine gültige (1850).

Gegentest: -18aaaa.50 ist eine gültige Zahl (1850), -18.aaaa50 keine.

Liebes verantwortliches Produktteam: Bitte nachbessern, denn die Einstellungen in der Systemsteuerung haben scheinbar zusätzlich auch keine Auswirkung!

Nach Position Sidebar & Minianwendungen verändert sich hatte ich den letzten Tagen einen der "schönen" Effekte unter Windows Vista x64: Mehrere Dateien bzw. Ordner lassen sich mittels des Windows Explorers nicht mehr markieren. Alex würde da gleich auf TotalCommander verweisen, aber TotalCommander ist auch nicht immer das optimale Werkzeug. Ich möchte auch, wie heißt es so schön überall derzeit, Experience. Eine Gruppierung z. B. kann TotalCommander nicht. Die Mischung mehrerer Alternativen zu einem Portfolio ist also die Lösung.

Doch leider ist auch mit Vista eines bei Microsoft gleich geblieben: Ich werde das Gefühl nicht los, dass das Betriebssystem trotz aller Maßnahmen von Microsoft in den letzten Jahren in diesem Bereich, nach und nach "verfettet", sich "auflöst", immer mehr nach und nach nicht funktioniert. So z. B. die Markierung mehrerer Dateien bzw. Ordner mittels der Maus oder Tastatur. Das heißt, Organisieren, Alles Auswählen funktioniert ebenso wenig, wie Bearbeiten, Alles auswählen (die Menüleiste muss eingeblendet sein) oder STRG + A. Die Menüpunkte dazu sind kurzum deaktiviert, die Maus kann nicht verwendet werden.

Bevor man die Wiederherstellung einer Sicherheitskopie startet, kann folgendes ausprobiert werden:

• Start, Systemsteuerung wählen
• (auf Startseite der Systemsteuerung klicken)
  
• "Ordner" rechts oben eingeben
• Ordneroptionen auswählen
• auf die Registerkarte Ansicht wechseln, Ordner zurücksetzen wählen, auf OK klicken
• alle Anwendungen beenden
• auf Start klicken
• in einen freien Bereich im Startmenü klicken, STRG + Shift drücken, Explorer beenden wählen
• STRG + ALT + ENTF drücken
• Task-Manager starten wählen
• Datei, Neuer Task (Ausführen...) wählen
• "explorer" bei Öffnen eingeben und auf OK klicken
• auf Start klicken
• "regedit" eingeben
• auf regedit und danach auf Fortsetzen klicken
• zu HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\
Microsoft\Windows\Shell navigieren
• optional können jeweils BagMRU und Bags angeklickt und über Datei, Exportieren eine Sicherung der Werte erstellt werden¹
• BagMRU und Bags löschen
• (eventuell einen Neustart durchführen)

Danach sollte wieder alles wie gewohnt funktionieren.

¹ für die Wiederherstellung sind die Sicherheitskopien doppelt anzuklicken, Fortsetzen und Ja zu wählen