[English]Das CERT Coordination Center weist in einem aktuellen Artikel darauf hin, dass eine Microsoft Windows RDP Network Level Authentication auch bei einem per LockScreen gesperrten Windows funktioniert.
Anzeige
Ich stelle das hier kurz ein, da die Meldung Microsoft Windows RDP Network Level Authentication can bypass the Windows lock screen gerade vom CERT veröffentlicht wurde – 1ST1 hatte in diesem Kommentar im Blog bereits auf einen Artikel von The Hacker News zum Thema verwiesen – und ich hatte es auch auf Twitter vor ein paar Tagen gesehen.
(Quelle: Pexels Markus Spiske CC0 Lizenz)
Worum geht es?
Microsoft Windows Remote Desktop unterstützt eine Funktion namens Network Level Authentication (NLA), die den Authentifizierungsaspekt einer Remote-Sitzung von der RDP-Schicht auf die Netzwerkschicht verschiebt. Der Einsatz von NLA wird empfohlen, um die Angriffsfläche von Systemen zu reduzieren, die mit dem RDP-Protokoll exponiert sind. Unter Windows kann eine Sitzung durch den Benutzer gesperrt werden, wodurch der am Bildschirm ein LockScreen erscheint. Dieser erfordert vom Benutzer eine Authentifizierung, um die Sitzung weiter nutzen zu können. Das Sperren von Sitzungen kann auch über RDP erfolgen, und zwar in der gleichen Weise, wie eine lokale Sitzung gesperrt werden kann.
Änderung ab Windows 10 Version 1803
Seit Windows 10 1803 (veröffentlicht im April 2018) und Windows Server 2019 hat sich die Handhabung von NLA-basierten RDP-Sitzungen so verändert, dass es zu unerwartetem Verhalten in Bezug auf das Sperren von Sitzungen kommen kann. Löst eine Netzwerkanomalie eine temporäre RDP-Trennung aus, wird die RDP-Sitzung beim automatischen Wiederherstellen der Verbindung in einen entsperrten Zustand versetzt. Das ist leider unabhängig davon, wie das entfernte System verlassen wurde. Das CERT beschreibt das Szenario in seinem oben verlinkten Artikel mit folgenden Schritten:
- Der Benutzer verbindet sich mit dem Remote Windows 10 1803 oder Server 2019 oder einem neueren System über RDP.
- Der Benutzer sperrt die Remote-Desktop-Sitzung.
-
Der Benutzer verlässt die physische Umgebung des Systems, das als RDP-Client verwendet wird.
An dieser Stelle kann ein Angreifer die Netzwerkverbindung des RDP-Client-Systems unterbrechen. Die RDP-Client-Software verbindet sich automatisch wieder mit dem Remote-System, sobald die Internetverbindung wiederhergestellt ist.
Aufgrund dieser Schwachstelle wird die wiederhergestellte RDP-Sitzung jedoch nicht auf dem Anmeldebildschirm, sondern auf einem angemeldeten Desktop wiederhergestellt. Dies bedeutet, dass das entfernte System entsperrt wird, ohne dass manuell Anmeldeinformationen eingegeben werden müssen.
2FA und Login-Richtlinien werden umgangen
Zwei-Faktor-Authentifizierungssysteme, die sich in den Windows-Anmeldebildschirm integrieren lassen, wie beispielsweise Duo Security MFA, können mit diesem Mechanismus ebenfalls umgangen werden. Die Leute bei CERT vermuten, dass andere MFA-Lösungen, die den Windows-Anmeldebildschirm nutzen, ähnlich betroffen sind. Alle Login-Richtlinien, die von einem Unternehmen durchgesetzt werden, werden ebenfalls umgangen.
Anzeige
Die Auswirkungen
Durch die Unterbrechung der Netzwerkverbindung eines Systems kann ein Angreifer mit Zugriff auf ein System, das als Windows RDP-Client verwendet wird, Zugriff auf ein verbundenes entferntes System erhalten, unabhängig davon, ob das entfernte System gesperrt wurde oder nicht.
Dem CERT/CC ist derzeit keine praktische Lösung für dieses Problem bekannt. Es werden die folgenden Workarounds empfohlen.
- Schutz des Zugriffs auf RDP-Client-Systeme: Wenn Sie ein System haben, das als RDP-Client verwendet wird, stellen Sie sicher, dass Sie das lokale System und nicht das entfernte System sperren. Das Sperren des entfernten Systems über RDP bietet keinen Schutz.
- RDP-Sitzungen trennen, anstatt sie zu sperren: Da das Sperren einer entfernten RDP-Sitzung keinen wirksamen Schutz bietet, sollten RDP-Sitzungen eher getrennt als gesperrt werden. Dadurch wird die aktuelle Sitzung ungültig, was eine automatische Wiederverbindung der RDP-Sitzung ohne Anmeldeinformationen verhindert.
Es sieht so aus, als ob Firmen mit Windows aus sicherheitstechnischen Gründen mittlerweile so einiges um die Ohren fliegt.
Ähnliche Artikel:
Angreifer scannen Windows-Systeme auf BlueKeep-Lücke
Fast 1 Million Windows-Maschinen über BlueKeep-Schwachstelle angreifbar
BlueKeep-Schwachstelle: Auch Microsoft warnt, es droht eine Malware-Pandemie
How To: BlueKeep-Check für Windows
Metasploit für BlueKeep vorhanden, z.Z. noch privat
2015
Das Schlimme daran ist vor allem, dass laut Hackernwes Microsoft dieses Problem nicht fixen will. Ich habe auch noch keine GPO-Einstellung gefunden, mit mit der man die beiden Empfehlungen automatisieren/erzwingen kann. Wer eine Idee hat, kann sie ja mal hier zur Diskussion stellen.
"…Das Schlimme daran ist vor allem, dass laut Hackernwes Microsoft dieses Problem nicht fixen will…"
Satan Nutellas Windows 10 ist das beste und sicherste Windows, das es je gegebn hat. Da muss man nichts flicken oder ändern.
Ja genau!
Und wer die Wahl hat, Win10 ja oder nein….lieber letzteres :-)
Wenn ich das jetzt richtig verstehe gibt es diese Lücke erst seint Windows 10 Version 1803, auch mal ganz interessant.
Roland Moser hat Recht. Bei Windows 10 braucht man nichts zu flicken und zu
ändern. Es gibt nur eine endgültige Lösung : Mülltonne auf – Windows 10 hinein –
Mülltonne zu. Danach die Mülltonne nicht mehr öffnen.
Die Windows 10 Hörigen sollen sich weiter damit herumschlagen, denn wer dieses
Windows 10 als Fortschritt bezeichnet, der hat es nicht anders verdient.
Wo ist das Problem? Nicht rumheulen, sondern einfach zu Linux wechseln
Dass ihr hier in einem Blog seit, in dem es vornehmlich um Windows geht, habt ihr sicherlich bemerkt? Muss das hier zugehen wie bei Heise? Ist euch langweilig?
:-) !
Was ist bei Heise? :-)
Für den privaten Gebrauch mag Linux eine mögliche Medizin sein, aber auch nur wenn man jemanden kennt, der auch mal bei Treiberproblemen helfen kann. Für den geschäftlichen Einsatz ist das leider unbrauchbar.
Ich lasse die Finger davon.
Wäre es massentauglich, wäre es auch verbreitet. Und die agressiven Antworten in den primitiven Linux-Foren brauche ich auch nicht.
Linux ist nicht verbreitet? Schonmal was von Android gehört? :)
"primitive Linux-Foren" habe ich auch noch nie gesehen. Wenn der tausendste Komiker mit der selben dummen Frage irgendwo ankommt, braucht er natürlich nicht mit Begeisterungsstürmen rechnen. Das ist in Windows-Foren nicht anders. Foren haben in der Regel eine Suchfunktion und Google gibt es auch noch.
"Für den privaten Gebrauch mag Linux eine mögliche Medizin sein, aber auch nur wenn man jemanden kennt, der auch mal bei Treiberproblemen helfen kann."
Dann bekommt er Hilfe von der entsprechenden Community :-)
"Für den geschäftlichen Einsatz ist das leider unbrauchbar."
Das ist wohl wahr, weil sich alle Welt von MS abhängig gemacht hat. Aber wenn alle das gleiche nutzen, gibt es auch die wenigsten Probleme.
Wieso sperrt man den verbundenen Rechner und den lokalen nicht? Ist doch absolut sinnfrei… Ein Sicherheitsproblem, dass in professionellem Umfeld kaum auftreten dürfte.