goSecurity BLOG

In Firmen mit einer Windowsumgebung wird meistens eine Verbindung zu anderen Systemen mithilfe von der von Microsoft integrierten Remotedesktopverbindung (RDP) hergestellt. Dabei machen sich die Firmen teilweise keine Gedanken über die Konfiguration und Sicherheit des Dienstes und verwenden die Standardeinstellungen. Wird bei der Konfiguration nicht genug Sorgfalt getragen, sind Man-in-the-Middle-Angriffe (MITM) relativ einfach möglich.

Bei vielen unserer Audits bekommen wir, wenn wir auf einen Server über RDP zugreifen wollen, folgende Fehlermeldung:

Diese Fehlermeldung erscheint, da die Authentifizierung mit einem selbstsignierten Zertifikat durchgeführt wird und nicht von unserem Client verifiziert werden kann. Schauen wir das Zertifikat an, sehen wir auf den ersten Blick nur, dass es auf einen bestimmten Servernamen ausgestellt ist. Wir können jedoch nicht sofort sehen, ob es das richtige Zertifikat ist. Die einzige Möglichkeit zu prüfen, ob es sich um das richtige Zertifikat handelt, wäre den Fingerabdruck des Zertifikats zu überprüfen. Wer kennt aber den Fingerabdruck des Zertifikats?

RDP Sicherheitsprotokolle

Um RDP Sicherheitsprotokolle besser zu verstehen, schauen wir uns diese mal genauer an.

Standard RDP Security

Es funktioniert ähnlich wie SSL. Für den Schlüsselaustausch wird asymmetrische Verschlüsselung mit RSA verwendet. Dabei erstellt der Server einen 32-Byte grossen Zufallswert und sendet diesen Wert zusammen mit seinem Public Key (Public Terminal Signing Key) an den Client, welcher mit dem Private Key (Private Terminal Signing Key) des Servers signiert ist. Der Client überprüft diesen und erstellt ebenfalls einen 32-Byte grossen Zufallswert und sendet diesen verschlüsselt mit dem Public Key des Servers an den Server. Mit diesen zwei Zufallswerten wird der Sitzungsschlüssel erstellt, welcher zum Verschlüsseln und Validieren des RDP-Verkehrs verwendet wird. Ab diesem Zeitpunkt ist die Verbindung mit RC4 verschlüsselt (symmetrische Verschlüsselung). Das alles klingt im ersten Moment ganz gut (wenn wir von der RC4-Verschlüsselung absehen, welche schon länger als unsicher gilt). Leider ist es nicht nur die RC4-Verschlüsselung, welche uns Sorgen machen sollte, sondern auch, dass der Private Key des Servers auf allen Windowsversionen gleich ist und somit einfach extrahiert werden kann. Deswegen hat sich auch Microsoft dazu entschlossen, den Private Key unter Microsoft Development Network im Internet zu veröffentlichen. Die Standard RDP Security sollte auf keinen Fall länger verwendet werden.

Enhanced RDP Security

Hierbei handelt es sich um richtiges SSL/TLS. Das Betriebssystem übernimmt die Verantwortung für die SSL/TLS-Verbindung, und somit auch die Prüfung des Zertifikats mit den hinterlegten Root-Zertifikaten im Zertifikatsspeicher von Windows. Ist die SSL/TLS-Verbindung aufgebaut, werden alle Daten über diese Verbindung gesendet.

Hat der Domaincontroller nicht die Rolle «Active Directory Certificate Services», werden standardmässig selbstsignierte Zertifikate verwendet. Dadurch wird die Verbindung für einen MITM-Angriff verwundbar. Ein Benutzer kann nur noch schwer erkennen, ob es sich um das richtige Zertifikat handelt. Zudem werden häufig Zertifikatsfehlermeldungen von den Benutzern einfach ignoriert und bestätigt.

Network-Level Authentication (NLA)

Als drittes gibt es noch die Möglichkeit NLA zu aktivieren. NLA verwendet 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. Zusätzlich schützt das NLA den Remoteclient, indem die Benutzerauthentifizierung abgeschlossen wird, bevor eine vollständige RDP-Verbindung hergestellt wird.

NLA mit Kerberos

Das ist einer der sichersten Authentifizierungsverfahren, um sich gegen MITM-Angriffe zu schützen. Um das Verfahren zu nutzen, müssen beide Systeme Teil der gleichen oder einer vertrauenswürdigen Domäne sein. Beim NLA mit Kerberos beantragt der Client ein Ticket beim Kerberos-Dienst. Dieses Ticket wird dem Server für die Authentifizierung vorgelegt. Der Server kann das Ticket dann überprüfen und der Verbindung zustimmen oder diese ablehnen.

NLA mit SSL/TLS

Es gibt Anwendungsbereiche, bei denen Kerberos nicht für die Authentifizierung verwendet werden kann, wie beispielsweise bei Terminalserverfarmen, Internetverbindungsszenarien über ein Terminalserver-Gateway, bei denen der Client keinen Zugriff auf das KDC hat oder Terminalserver, die nicht in der Domäne sind. Hier können, wie bei einer normalen SSL/TLS-Konfiguration, Zertifikate von einer vertrauenswürdigen Zerifizierungsstelle am Server hinterlegt werden.

NLA mit NetNTLMv2 (NTLM)

Sind keine SSL/TLS-Zertifikate konfiguriert und die Authentifizierung über Kerberos nicht möglich, verwendet CredSSP den NTLM-Authentifizierungsmechanismus mit selbstsigniertem Zertifikat. Dabei sendet der Server ein zufälliger Wert (Server-Random) an den Client. Der Client erstellt mit diesem Wert und weiteren Werten wie beispielsweise Servername, Zeitstempel und dem gehashten Benutzerkennwort einen neuen Hash, welcher wieder an den Server gesendet wird. Nun macht der Server das gleiche und vergleicht die Hash-Werte.

Der Angriff

Beim MITM-Angriff wird der Netzwerkverkehr zwischen dem Server und dem Client abgefangen, in dem sich der Angreifer jeweils als der andere ausgibt. Dadurch kann der Angreifer den Datenverkehr mitlesen und/oder ändern, ohne dass es einer der anderen bemerkt. Um zu verhindern, dass ein Client die Kerberos-Authentifizierung verwendet, wird der Kerberos-Dienst blockiert. Hierzu wird der Zugriff vom Client auf Port 88 abgewiesen. Wenn der Client die Kerberos-Authentifizierung nicht verwenden kann, versucht der Client es über NTLM.

Für den Angriff laden wir zuerst das Tool SETH von GitHub herunter.

Mit SETH kann der MITM-Angriff automatisiert werden. Dabei wird ein ARP-Poisoning mit arpspoof durchgeführt und der Port 88 mit den iptables für die angegebene Opfer-IP-Adresse geblockt. Versucht der Client sich zu verbinden, klont das Tool das Serverzertifikat und startet den MITM-Proxy, um den Netzwerkverkehr mitzulesen und versucht die Authentifizierungsstufe herunterzustufen (Downgrade).

In unserer Testumgebung verwenden wir einen Windows 10 Client, der eine RDP-Verbindung mit einem Windows Server 2012 herstellen soll. Um den Angriff auszuführen, starten wir SETH mit den folgenden Parametern: Interface, IP-Adresse des Angreifers, IP-Adresse des Opfers und die IP-Adresse des RDP-Clients:

Als nächstes starten wir die RDP-Verbindung vom Windows 10-Client auf den Windows Server 2012.

Nach Eingabe des Passworts erscheint wie gewohnt die Zertifikats-Fehlermeldung.

Wird dies bestätigt, bekommt der Angreifer eine Verbindung mit dem Server.

In der Ausgabe von SETH finden wir zwei interessante Teile. Zum einen den NTLM-Hash, welchen wir versuchen können offline zu knacken und zum anderen das Klartextkennwort des RDP-Benutzers. Beides wird in rot ausgegeben.

Fazit und Empfehlungen

Um sich vor diesem Angriff zu schützen, ist es wichtig, nur RDP-Verbindungen zuzulassen, wenn die Identität des Servers eindeutig verifiziert werden kann. Dazu müssen folgende drei Bedingungen erfüllt sein:

• Die RDP-Verbindung wird über den Zertifikatsnamen aufgerufen
• Der Aussteller des Zertifikats ist als vertrauenswürdig eingestuft
• Das Zertifikat ist innerhalb des gültigen Zeitraumes

Weiter müssen die Clients über Gruppenrichtlinien so konfiguriert werden, dass ein nicht verifiziertes Zertifikat abgelehnt wird.

Gruppenrichtlinie:

Zusätzlich empfehlen wir, falls möglich, nur das RDP in Verbindung mit NLA einzusetzen. Dadurch wird die Benutzerauthentifizierung abgeschlossen, bevor eine vollständige RDP-Verbindung hergestellt wird. Somit wird der Remotecomputer gegen böswillige Benutzer und Software geschützt. Das ist auch über Gruppenrichtlinien konfigurierbar.

Gruppenrichtlinie:

Beachten Sie aber, dass auch bei diesem Verfahren die Zugangsdaten der Benutzer im Arbeitsspeicher des Remotecomputers abgelegt werden und mit der Berechtigung LocalSystem und bestimmten Tools, wie beispielsweise Mimikatz, ausgelesen werden können. Lesen Sie dazu den goSecurityBLOG: Lateral Movement.

Selbstverständlich müssen Sie nun auch Ihre Administratoren regelmässig darauf hinweisen, dass es in Ihrer Unternehmung verboten ist, Zertifikatsfehlermeldungen zu akzeptieren.

Und zuletzt sollten Sie immer darauf achten, sowenig wie möglich Benutzer mit Domänen-Administrator-Rechten zu verwenden. Am sichersten ist es, wenn Sie diese nur auf den Domaincontrollern verwenden.