Nach BlueKeep: Weitere RDS-Schwachstelle in Windows entdeckt

Eine Schwachstelle in den Remote Desktop Services von Win 10 und Server 2019 erlaubt unter eng definierten Bedingungen unbefugte Zugriffe. Es gibt Workarounds.

In Pocket speichern vorlesen Druckansicht 35 Kommentare lesen
Nach BlueKeep: Weitere RDP-Schwachstelle in Windows entdeckt

(Bild: itkannan4u)

Lesezeit: 5 Min.
Inhaltsverzeichnis

Das CERT Coordination Center der Carnegie Mellon University warnt vor einer Schwachstelle, die – wie BlueKeep (CVE-2019-0708) – die Remote Desktop Services (RDS) des Windows-Betriebssystems betrifft. Sie ermöglicht den Zugriff auf Remote-Desktops ohne Eingabe von Anmeldedaten. Und sie fußt ausgerechnet auf einem Feature, dessen Aktivierung Microsoft derzeit als zusätzliche Schutzmaßnahmen gegen BlueKeep empfiehlt: Network Level Authentication (NLA).

Das BSI stuft das von der neuen Verwundbarkeit mit Kennung CVE-2019-9510 ausgehende Gefahrenpotenzial als "hoch" ein. Allerdings sieht das CERT Coordination Center, das die initiale Warnung veröfentlicht hat, das anders: Es kommt lediglich auf einen CVSS-Base-Score von 4.6 von möglichen 10 (Einstufung "Medium"). Remote-Angriffe sind im Gegensatz zu BlueKeep hier nur aus dem lokalen Netzwerk möglich. Die Komplexität des Angriffs ist gering; allerdings funktioniert er nur in einem eng gesteckten Zeitfenster und unter ganz bestimmten Voraussetzungen.

Microsoft empfiehlt die Verwendung von NLA aus Sicherheitsgründen: Die Authentifizierung einzelner Nutzer gegenüber dem (RDSH)-Server, der die Remote Desktops bereitstellt, passiert hier bereits vor Aufbau der Session. In einem Sicherheitshinweis zu BlueKeep erläutert Microsoft, dass die Schwachstelle bei aktivierter NLA erst dann ausgelöst werden könne, wenn sich der Angreifer mit gültigen Zugangsdaten angemeldet habe.

Die Kehrseite der Medaille, so schreibt das CERT Coordination Center im aktuellen Sicherheitshinweis, sei jedoch, dass sich die Verarbeitung NLA-basierter Remote-Desktop-Protocol (RDP)-Sessions ab Windows-10-Versionen seit 1803 (erschienen im April 2018) und Windows Server 2019 in einer Weise geändert habe, die in Bezug auf das Sperren von Sessions zu "unerwartetem Verhalten" führen könne.

Ein möglicher Angriffszeitpunkt wäre, wenn ein Nutzer, der sich zuvor (unter Verwendung von Windows Server 2019, Windows 10 1803 oder einer neueren Version) via Remote Desktop Protocol mit dem RDSH-Server verbunden hat, diese Remote-Desktop-Session sperre, um sich von seinem Arbeitsplatz zu entfernen. Sofern es dem Angreifer aus dem lokalen Netz gelingt, kurzzeitig die Netzwerkverbindung des anzugreifenden Rechners zu trennen, greift die Schwachstelle.

Die RDP-Client-Software verbindet sich nämlich anschließend zwar automatisch wieder mit dem Server, startet die Session jedoch nicht etwa mit einem Login-Screen, sondern mit dem bereits "eingeloggten" Desktop. Der Angreifer benötigt für den Zugriff auf den Desktop des (vermutlich gerade abwesenden) Nutzers also keine Zugangsdaten. Die Ausführung von Exploit-Code oder ähnlichem ist nicht erforderlich.

Microsofts nächster reguläre Patchday ist für den kommenden Dienstag geplant; darüber. Ob Microsoft dabei auch einen Patch gegen CVE-2019-9510 verteilen wird, scheint allerdings fraglich. Denn in einem Statement gegenüber dem CERT Coordination Center äußerte Microsoft, keinen wirklichen Nachbesserungsbedarf zu sehen. Denn das der Client während des Zeitraums einer bestehenden Session die Login-Daten temporär speichere, um im sich im Falle eines Auto-Reconnects damit neu zu verbinden, sei das für NLA normale, gewünschte Verhalten.

Das CERT Coordination Center hat bei mehreren Hersteller von Zwei-Faktor-Authentifizierungslösungen, die sich in den Windows-Login-Bildschirm integrieren, angefragt, ob ihre Produkte (indirekt) von der Schwachstelle betroffen seien. Duo Security bestätigte dies, betonte zugleich aber, dass nicht etwa seine Software "verwundbar" sei. Vielmehr würde der von ihr im Login-Screen bereitgestellte Authentifizierungsmechanismus durch Microsofts mit Version 1803 eingeführte NLA-Änderungen einfach umgangen. Aus Sicht des Herstellers liegt der Handlungsbedarf also bei Microsoft.

Die Hersteller Authy und Silverfort geben an, nicht betroffen zu sein, da ihre Authentifizierungslösungen nicht Teil des Login-Bildschirms seien. Centrify ist laut CERT betroffen, hat sich aber (wie weitere Hersteller, zu denen noch keine Informationen vorliegen) noch nicht geäußert.

Da das Deaktivieren von NLA Angreifern in die Hände spielen könnte, die die (gravierendere) BlueKeep-Lücke auszunutzen versuchen, ist davon abzuraten. Der erste Alternativ-Vorschlag des CERT Coordination Center sollte (unabhängig von aktuellen Schwachstellen) ohnehin eine Selbstverständlichkeit darstellen. Es rät nämlich dazu, beim Verlassen des Arbeitsplatzes nicht nur den Remote-Desktop, sondern auch den lokalen Rechner zu sperren.

Alternativ schütze auch das bewusste Beenden der RDP-Verbindung vor dem Angriff, denn dadurch wird die Session ungültig und die automatische Wiederverbindung ohne Zugangsdaten ist nicht länger möglich.

Mehr zum Thema:

Update 07.06.19, 09:55: Artikel um Microsofts Statement und Hinweis auf betroffene Hersteller ergänzt. (ovw)