it-swarm.com.de

Durch das Entfernen einer anfälligen Verschlüsselung unter Windows 10 wird das ausgehende RDP unterbrochen

Der Schwachstellenscanner von TrustWave schlägt einen Scan aufgrund eines Windows 10-Computers mit RDP fehl:

Blockverschlüsselungsalgorithmen mit einer Blockgröße von 64 Bit (wie DES und 3DES) Geburtstagsangriff, bekannt als Sweet32 (CVE-2016-2183)

HINWEIS: Auf Windows 7/10-Systemen mit RDP (Remote Desktop Protocol) ist die anfällige Verschlüsselung, die deaktiviert werden sollte, mit "TLS_RSA_WITH_3DES_EDE_CBC_SHA" gekennzeichnet.

Mit IIS Crypto (von Nartac)) habe ich versucht, die Vorlage "Best Practices" sowie die PCI 3.1-Vorlage anzuwenden. Beide enthalten jedoch die unsichere Verschlüsselung (TLS_RSA_WITH_3DES_EDE_CBC_SHA):

(CipherScreen

Wenn ich diese Verschlüsselung deaktiviere, funktioniert RDP from Dieser Computer auf vielen Windows-Stationen nicht mehr (auf einigen 2008 R2- und 2012 R2-Servern funktioniert er immer noch). Der RDP-Client gibt einfach "Ein interner Fehler ist aufgetreten" und das Ereignisprotokoll aus:

Beim Erstellen eines TLS-Client-Berechtigungsnachweises ist ein schwerwiegender Fehler aufgetreten. Der interne Fehlerzustand ist 10013.

Ich habe das Serverereignisprotokoll eines der Server überprüft und sehe diese beiden Meldungen

Eine TLS 1.2-Verbindungsanforderung wurde von einer Remoteclientanwendung empfangen, aber keine der von der Clientanwendung unterstützten Cipher Suites wird vom Server unterstützt. Die SSL-Verbindungsanforderung ist fehlgeschlagen.

Die folgende schwerwiegende Warnung wurde generiert: 40. Der interne Fehlerstatus ist 1205.

Wie kann ich die Sicherheitslücke beheben, ohne ausgehendes RDP zu beschädigen?

Oder, wenn das oben Genannte nicht möglich ist, kann ich auf jedem RDP-Host etwas tun, mit dem ich keine Verbindung mehr herstellen kann, um dies zu handhaben?

--- Update # 1 ---

Nach dem Deaktivieren von TLS_RSA_WITH_3DES_EDE_CBC_SHA auf dem Windows 10-Computer habe ich versucht, eine Verbindung zu mehreren RDP-Hosts herzustellen (die Hälfte davon ist mit "Ein interner Fehler ..." fehlgeschlagen). Also habe ich einen dieser Hosts, mit denen ich kann verbunden habe, mit einem verglichen, mit dem ich nicht verbinden kann. Beide sind 2008 R2. Beide haben dieselbe RDP-Version (6.3.9600, RDP-Protokoll 8.1 unterstützt).

Ich habe die TLS-Protokolle und Chiffren mit IIS Crypto verglichen, um "Vorlage speichern" für ihre aktuellen Einstellungen auszuführen, damit ich die Vorlagendateien vergleichen kann. Sie waren identisch! Was auch immer das Problem ist, nicht Es scheint sich um eine fehlende Chipher Suite auf dem Host zu handeln. Hier ist ein Screenshot von Beyond Compare zu den Dateien:

(Cipher compare

Was kann zwischen den beiden RDP-Hosts, die dieses Problem verursachen, unterschiedlich sein und wie kann es behoben werden?

16
Zek

IIS Crypto bietet die Möglichkeit, sowohl die serverseitigen (eingehenden) als auch die clientseitigen (ausgehenden) Optionen festzulegen. Es gibt eine Handvoll Chiffren, die Sie aus Kompatibilitätsgründen auf der Clientseite aktiviert lassen müssen.

Um zu tun, was Sie wollen, würde ich persönlich Folgendes tun:

  • 3.1 Vorlage anwenden
  • Lassen Sie alle Cipher Suites aktiviert
  • Auf Client und Server anwenden (Kontrollkästchen aktiviert).
  • Klicken Sie auf "Übernehmen", um die Änderungen zu speichern

Starten Sie hier bei Bedarf neu (und Sie haben physischen Zugriff auf den Computer).

  • 3.1 Vorlage anwenden
  • Lassen Sie alle Cipher Suites aktiviert
  • Auf Server anwenden (Kontrollkästchen deaktiviert).
  • Deaktivieren Sie die Option 3DES

Ein Neustart sollte hier zum richtigen Endzustand führen.

Tatsächlich möchten Sie nur eingehende 3DES deaktivieren, aber dennoch die ausgehende Verwendung dieser Verschlüsselungssuite zulassen.

3
Tim Brigham

Bearbeiten (2018-09-26): Ich habe festgestellt, dass das Deaktivieren von 3DES auf 2012R2 RDP NICHT beschädigt, auf 2008 R2 jedoch. Die unterstützten Optionen scheinen sich zwischen den Kerneln zu unterscheiden.


Ich werde meine Antwort von einem TechNet teilen Thread aber zuerst BLUF:

Schlussfolgerung zum Serverfehler: Höchstwahrscheinlich haben Sie einen anderen Unterschied zwischen den Systemen. Sie stellen eine Verbindung zwischen verschiedenen Betriebssystemversionen her, ein System hat FIPS aktiviert und das andere nicht, oder Sie haben unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers Unterschiedliche Verschlüsselungsbeschränkungen. Ich würde auf jeden Fall die SCHANNEL-Protokollierung auf dem System aktivieren, das funktioniert funktioniert, um festzustellen, welche Verschlüsselung verwendet wird. Würde gerne zurück hören, wenn Sie RDP irgendwie dazu gebracht haben, mit einer alternativen Chiffre zu arbeiten.

Kopie des Beitrags :

Wir haben es geschafft!

Anscheinend haben 2008 und 2012 Syntaxprobleme und 2008/7 erfordert ein Trailing/168. 2012/8.1/10 nicht.

der Schlüssel für 2008 sieht folgendermaßen aus: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168/168

Und der Schlüssel für 2012 sieht so aus: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168

Ich kann bestätigen, dass die Verwendung von "Triple DES 168/168" 3DES auf dem System NICHT deaktiviert. Sie können sich dies mit einem Protokollscanner (wie Nessus) oder durch Aktivieren der SCHANNEL-Protokollierung selbst beweisen:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL] "EventLogging"=dword:00000007

Sie haben dann beispielsweise Ereignisse im SYSTEM-Protokoll.

Ein SSL-Client-Handshake wurde erfolgreich abgeschlossen. Die ausgehandelten kryptografischen Parameter sind wie folgt.

Protokoll: TLS 1.0 CipherSuite: 0x2f Austauschstärke: 1024

Für mich ist das Ergebnis 0xa, das Google als TLS_RSA_WITH_3DES_EDE_CBC_SHA anzeigt.

Wenn ich "Triple DES 168" (ohne/168) verwende, wird die Systemereignis-ID 36880 nicht angezeigt und die RDP-Sitzung wird blockiert.

Gemäß Artikel: Systemkryptografie: Verwenden Sie FIPS -kompatible Algorithmen zum Verschlüsseln, Hashing und Signieren

Remotedesktopdienste (RDS) Zum Verschlüsseln der Remotedesktopdienste-Netzwerkkommunikation unterstützt diese Richtlinieneinstellung nur den dreifachen DES - Verschlüsselungsalgorithmus.

Gemäß Artikel: "Systemkryptografie: Verwenden Sie FIPS -kompatible Algorithmen zum Verschlüsseln, Hashing und Signieren" Sicherheitseinstellungseffekte in Windows XP und in späteren Windows-Versionen

Diese Einstellung wirkt sich auch auf Terminaldienste in Windows Server 2003 und in späteren Windows-Versionen aus. Der Effekt hängt davon ab, ob TLS für die Serverauthentifizierung verwendet wird.

Wenn TLS für die Serverauthentifizierung verwendet wird, wird bei dieser Einstellung nur TLS 1.0 verwendet.

Wenn TLS nicht verwendet wird und diese Einstellung auf dem Client oder auf dem Server nicht aktiviert ist, wird der RDP-Kanal (Remote Desktop Protocol) zwischen dem Server und dem Client standardmäßig mithilfe des RC4-Algorithmus mit 128 Bit verschlüsselt Schlüssellänge. Nachdem Sie diese Einstellung auf einem Windows Server 2003-basierten Computer aktiviert haben, gilt Folgendes: Der RDP-Kanal wird mithilfe des 3DES-Algorithmus im CBC-Modus (Cipher Block Chaining) mit einer Schlüssellänge von 168 Bit verschlüsselt. Der SHA-1-Algorithmus wird zum Erstellen von Nachrichtenübersichten verwendet. Clients müssen das RDP 5.2-Clientprogramm oder eine spätere Version verwenden, um eine Verbindung herzustellen.

Beide unterstützen also die Idee, dass RDP nur 3DES verwenden kann. In diesem Artikel wird jedoch vorgeschlagen, dass eine größere Auswahl an Chiffren verfügbar ist: FIPS 140-Validierung

Der Satz kryptografischer Algorithmen, den ein RDP-Server (Remote Desktop Protocol) verwendet, umfasst Folgendes: - CALG_RSA_KEYX - RSA-Algorithmus für den Austausch öffentlicher Schlüssel - CALG_3DES - Dreifacher DES Verschlüsselungsalgorithmus - CALG_AES_128 - 128-Bit-AES - CALG_AES_256 - 256 Bit AES - CALG_SHA1 - SHA Hashing-Algorithmus - CALG_SHA_256 - 256-Bit SHA Hashing-Algorithmus - CALG_SHA_384 - 384-Bit SHA Hashing-Algorithmus - CALG_SHA_512 - 512-Bit SHA Hashing-Algorithmus

Letztendlich ist nicht klar, ob RDP Nicht-3DES-Protokolle unterstützen kann, wenn der FIPS - Modus aktiviert ist, aber es gibt Hinweise darauf, dass dies nicht der Fall ist.

Ich sehe keine Hinweise darauf, dass Server 2012 R2 anders als Server 2008 R2 funktionieren würde. Es scheint jedoch, dass Server 2008 R2 auf der FIPS 140-1-Konformität basiert und Server 2012 R2 FIPS 140-2 folgt Es ist durchaus möglich, dass Server 2012 R2 zusätzliche Protokolle unterstützt. Die zusätzlichen Protokolle finden Sie im Link FIPS 140 Validation .

Fazit: Ich glaube nicht, dass Server 2008 R2 RDP im Modus FIPS mit deaktiviertem 3DES unterstützen kann. Ich empfehle zu prüfen, ob Ihr System die Bedingungen für einen SWEET32-Angriff erfüllt (mehr als 768 GB in einer einzigen Sitzung) und ob es sich lohnt, die RDP-Funktion zu deaktivieren, wenn Sie 3DES deaktivieren. Es gibt andere Dienstprogramme zum Verwalten von Servern außerhalb von RDP, insbesondere in einer Welt, in der Virtualisierung weit verbreitet ist.

2
duct_tape_coder

Ich hatte das gleiche Problem: Die Installation des KB3080079-Patches auf dem Server ermöglicht die Unterstützung von TL 1.1 und 1.2.

Beachten Sie, dass Sie für Windows 7-Clients das rdp-Client-Update (KB2830477) installieren müssen, da sonst nur Windows 8+ eine Verbindung herstellen kann.

1
Evgeniy

Anscheinend haben 2008 und 2012 Syntaxprobleme und 2008/7 erfordert ein Trailing/168. 2012/8.1/10 nicht.

der Schlüssel für 2008 sieht folgendermaßen aus: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168/168

** Großartiger Fund Ich hatte genau das gleiche Problem auf einigen Windows 2008 R2-Domänencontrollern. Seltsamerweise scheinen meine 2008R2-Mitgliedsserver in Ordnung zu sein ... und meine 2012R2-Server funktionieren auch einwandfrei. Ich muss die älteren DCs dekomprimieren :)

0
omicronx9