[English]Wegen einer kritischen Sicherheitslücke in Microsofts Credential Security Support Provider will das Unternehmen künftig RDP-Verbindungen zu ungepatchten Clients blockieren. Administratoren müssen also reagieren.
Anzeige
Um was geht es?
In allen Windows-Versionen gibt es eine kritische Sicherheitslücke im Credential Security Support Provider (CredSSP). Konkret steckt die kritische Sicherheitslücke im Credential Security Support Provider-Protokoll (CredSSP), das in allen bisherigen Versionen von Windows verwendet wird. Denn das CredSSP-Protokoll wurde für die Verwendung durch RDP (Remote Desktop Protocol) und Windows Remote Management (WinRM) entwickelt. Das Protokoll übernimmt die sichere Weiterleitung der vom Windows-Client verschlüsselten Anmeldeinformationen an die Zielserver zur Remote-Authentifizierung.
(Quelle)
Die Sicherheitslücke CVE-2018-0886 ermöglicht nun Remote-Angreifern, RDP- und WinRM-Verbindungen zum Stehlen von Daten oder zum Ausführen von Malware zu nutzen. Ich hatte auf dieses Thema kürzlich im Blog-Beitrag CredSSP-Sicherheitslücke in RDP unter Windows hingewiesen. Dort lassen sich auch Informationen über die Sicherheitslücke abrufen.
Die Sicherheitslücke wurde im August 2017 an das MSRC gemeldet. Microsoft hat mit dem März 2018-Update diese Sicherheitslücke (CVE-2018-0886) in der CredSSP-Implementierung geschlossen.
Anzeige
Microsoft-Empfehlungen
Im Microsoft KB-Artikel 4093492 findet sich nicht nur die Erklärung zur Sicherheitslücke im Credential Security Support Provider Protocol (CredSSP). Microsoft empfiehlt Administratoren dringend, das Update auf Servern und Clients durchgängig zu installieren. Weiterhin sind die Gruppenrichtlinien so anzupassen, dass die Einstellungen "Force Updates Clients" und "Mitigated" sowohl auf dem Server als auch auf den Clients sobald wie möglich aktiviert werden. Dies soll die Server gegen unsichere (ungepatchte) Clients absichern.
Verbindungen von ungepatchten Clients werden geblockt
The Register schreibt in diesem Artikel, dass Microsoft demnächst verhindern wird, dass Windows Server RDP-Clients, die nicht gegen die Sicherheitslücke gepatcht wurden, von den Servern authentifiziert werden. Dies soll verhindern, dass Angreife RDP-Verbindungen missbrauchen, um Systeme zu übernehmen und sich in einem Netzwerk zu bewegen. Microsoft gibt im KB-Artikel 4093492 auch detailliert an, wie Microsoft mit Updates und Blockaden die Ausnutzung der Sicherheitslücke verhindern wird.
13. März 2018
Das erste Update-Release von diesem Datum aktualisierte das CredSSP-Authentifizierungsprotokoll und die Remote Desktop Clients für alle betroffenen Plattformen. Die Mitigation besteht darin, das Update auf allen berechtigten Client- und Server-Betriebssystemen zu installieren und dann die enthaltenen Gruppenrichtlinien-Einstellungen oder registrierungsbasierte Äquivalente zu verwenden, um die Einstellungsoptionen auf den Client- und Server-Computern zu verwalten.
Microsoft empfiehlt Administratoren, die Richtlinie so schnell wie möglich anzuwenden und sie auf "Aktualisierte Clients erzwingen" oder "Mitigated" auf Client- und Server-Computern zu setzen. Diese Änderungen erfordern einen Neustart der betroffenen Systeme.
Tipp: Achten Sie besonders auf Gruppenrichtlinien- oder Registry-Einstellungspaare, die in der Kompatibilitätstabelle dieses KB-Artikels weiter unten in diesem Artikel zu "Blockierten" Interaktionen zwischen Clients und Servern führen.
17. April 2018 (vorläufig)
Zu diesem Datum wird ein weiteres RDP-Update (für den Remote Desktop Client) ausgerollt. Dieses verbessert die angezeigte Fehlermeldung, wenn ein aktualisierter Client keine Verbindung zu einem Server herstellen kann, weil dieser nicht aktualisiert wurde.
8. Mai 2018 (vorläufig)
Es wird ein Update ausgerollt, um die Standardeinstellung von Vulnerable (verwundbar) auf Mitigated (abgesichert) zu ändern. Im Umfeld der Black Hat Asia-Konferenz hat The Register erfahren, dass der Mai-Patche dazu führen wird, dass ungepatchte RDP-Clients von gepatchten Windows Servern abgelehnt werden. Damit wird verhindert, dass die Sicherheitslücke ausgenutzt werden kann.
Achtung bei Linux-RDP-Verbindungen
Kleine Ergänzung für Leute, die hier zufällig noch mitlesen. Wer von Linux eine RDP-Verbindung zu einem Windows Server herstellt, läuft u.U. in Probleme. Ich habe das Thema im Blog-Beitrag Achtung bei Linux-RDP-Verbindungen und CredSSP-Updates angesprochen.
Ähnliche Artikel:
CredSSP-Sicherheitslücke in RDP unter Windows
Microsoft blockt bald RDP-Anfragen von Clients
Windows-Remoteunterstützung als Risiko
Anzeige
Das heisst also, der Patch kb4088875/kb4088878, der mir die Netzwerksettings bei meinen VMs killt muss jetzt installiert werden, damit meine RDP Verbindungen demnächst weiter funktionieren?
https://www.borncity.com/blog/2018/03/14/netzwerkprobleme-mit-updates-kb4088875-kb4088878/
Ich warte immer noch auf die Korrektur der obigen Patche… hier steht noch nix neues…
https://support.microsoft.com/en-us/help/4088878/windows-7-update-kb4088878
Ich gehe davon aus, dass dem so ist. Aber bis Mai 2018 hat MS ja noch den April Patchday und kann mit Previews stoppeln. Aber so richtig knorke sieht das nicht wirklich aus. Warten wir es ab.
Moin Herr Born.
Die Info "[Microsoft] will … künftig RDP-Verbindungen zu ungepatchten Clients blockieren" ist nicht korrekt. Was im April erzwungen wird, ist "mitigated" und nicht "force updated clients". Nur Letzteres würde RDP-Verbindungen von nicht kompatiblen Clients blockieren. Siehe Tabelle bei Microsoft ( https://support.microsoft.com/en-us/help/4093492/credssp-updates-for-cve-2018-0886-march-13-2018 ->Spalte "Server behavior") und auch nachprüfbar durch eigene Tests mit Windows und Linux (krdc).
Nutzen alle RDP-Verbindungen credssp? Das würde bedeuten, dass ab Mai-Patchday niemand mehr mit einem gepatchten System auf ungepatchte Systeme per RDP zugreifen können wird (mit der Defaulteinstellung)? Das wäre ein Gau sondergleichen.
Wie verhält es sich auf Windows Server 2003 SBS, die erhalten ja kein Update, folglich ändert sich auch nichts an deren Gruppenrichtlinieneinstellung?
Die Richtlinie ist nach Aktualisierung standardmäßig nicht aktiviert, also passiert doch erstmal gar nichts… !?