[English]Vielleicht ist es allgemein bekannt – mir war es nicht bewusst: Lokal angemeldete Nutzer können unter Windows das Kennwort eines WLAN abrufen, wenn dieses unter dem gleichen Benutzerkonto eingetragen wurde. Dazu sind keine Administratorberechtigungen erforderlich, wenn man es richtig macht. Nachdem mich eine Leserin auf diesen Sachverhalt hingewiesen hat, habe ich das selbst an einem Windows 10 22H2-System nachvollziehen können. Hier ein kurzer Überblick, warum es geht.
Das WLAN-Kennwort ist geschütz
tDas Kennwort für einen auf einem Gerät eingerichteten WLAN-Zugang wird einem Benutzer aus Sicherheitsgründen normalerweise nicht angezeigt. Allerdings haben Administratoren in Windows die Möglichkeit, sich über den WLAN-Status das Passwort zum Drahtlos-Zugang anzeigen zu lassen.
Die Kollegen von windows-faq.de haben die Schritte, das auf der GUI-Ebene zu tun, in diesem Artikel dokumentiert. Obiges Dialogfeld aus Windows 10 22H2 zeigt die betreffende Registerkarte, wobei das Optionsfehl Zeichen anzeigen durch das Icon der Benutzerkontensteuerung gekennzeichnet ist. Das heißt, ohne Eingabe des Administratorkennworts in der Benutzerkontensteuerung wird dieses WLAN-Passwort (Sicherheitsschlüssel) nicht im Klartext angezeigt.
Leserhinweis auf WLAN-Passwortabfrage
Blog-Leserin Cornelia H. hat mich die Tage kontaktiert (danke für den Hinweis), weil sie von Nutzern mit der Frage konfrontiert worden war, warum sich das WLAN-Passwort von normalen Benutzer so einfach im Klartext auslesen lasse. Cornelia schrieb mir.
Sehr geehrter Herr Born
Als regelmäßige Leserin Ihres Blogs habe ich heute einen Hinweis zu Windows 10 und Windows 11, der Sie interessieren könnte.
Ein Kunde von uns hatte nachgefragt, warum mit einem (unpersönlichen) Benutzerkonto ohne Adminrechte ein WLAN-Passwort herausgefunden werden könne.
Auf Nachfrage hin stellte sich heraus, dass das mit dem Befehl ‘netsh wlan show profile <ssid> key=clear‘ möglich war.
Unsere anschließenden Tests waren zunächst erfolglos, weshalb wir vermuteten, dass der Benutzer auf dem Computer in die Administratorengruppe aufgenommen und nicht wieder entfernt worden war. Das konnte aber ausgeschlossen werden.
Ich habe es mal unter Windows 10 22H2 an einem Standardbenutzerkonto getestet. Rufe ich die Eingabeaufforderung mit Standard-Benutzerrechten auf, kann ich mit dem obigen netsh-Befehl wirklich das WLAN-Kennwort abfragen. Es ist keine Eingabe eines Administrator-Kennworts möglich.
Cornelia hat den Sachverhalt ebenfalls genauer untersucht und schrieb mir dazu, dass eine genauere Überprüfung des Computers nun Folgendes ergab:
Derjenige Benutzer, der gerade angemeldet ist, wenn jemand das Passwort für ein WLAN-Netzwerk eingibt, kann es anschließend über die Eingabeaufforderung auslesen, auch wenn er keine Admin-Rechte hat.
Eine spätere Änderung des WLAN-Passworts bringt nichts, der Benutzer kann das neue Passwort ebenso auslesen.
Nur andere Benutzer ohne Admin-Rechte können das gesetzte Passwort nicht auslesen.
Cornelia stuft das als eine Sicherheitsschwachstelle ein und weist darauf hin, das die grafische Schnittstelle in Windows (siehe obige Hinweise) die Eingabeaufforderung mit der Abfrage des Administrator-Kennworts anzeigt, sobald jemand das WLAN-Passwort im Klartext anzeigen lassen möchte.
Lösung für das Problem
Cornelia hat dann noch etwas probiert und eine Lösung für dieses Problem gefunden. Standard-Nutzer können das WLAN-Passwort nämlich nicht auslesen, wenn dieses unter einem anderen Benutzerkonto eingetragen wurde. Dazu schreibt sie:
Eine einfache Lösung ist, sich als Administrator am Computer anzumelden und das bekannte WLAN-Netzwerk über die Systemeinstellungen zu entfernen – mit „nicht speichern“.
Anschließend das Passwort neu eingeben. Da es folglich mit einer neuen ID registriert wird, kann der Benutzer [mit Standard-Rechten] das zugehörige Passwort nicht mehr wie zuvor auslesen.
Den Punkt habe ich jetzt nicht mehr separat überprüft.
Vorsicht bei Gastkonten
In einer Folgemail hat mir Cornelia noch einige ergänzende Informationen zu Gastkonten übermittelt. Dazu schrieb sie:
Guten Tag Herr Born ,
Ich habe noch eine Ergänzung, nachdem ich ein paar weitere Tests durchgeführt habe.
Im Gegensatz zu einem Standardbenutzer kann ein Mitglied der Gruppe Gäste ein bekanntes WLAN nicht entfernen, weil sämtliche Modern-GUI-Einstellungen blockiert werden. (Via Registry und/oder Powershell habe ich das nicht verifiziert.)
Das Passwort via cmd Befehl auszulesen – sofern es unter dem angemeldeten Gast eingetragen worden war – ist aber genauso möglich wie für einen Standardbenutzer.
Dieses Verhalten gilt sowohl für Windows 10 als auch für Windows 11. Dazu schrieb mir Cornelia noch: Das bestätigt, was schon seit Jahren bekannt ist: Ein Gast-Konto ist ohne zusätzliche, umfassende Konfiguration/Intervention kaum eingeschränkter als ein Benutzer-Konto. An dieser Stelle mein Dank an Cornelia für diesen Hinweis.
Was ist denn so schlimm daran, das der User der gerade ebend den Schlüssel selbst eingeben hat diesen lesen kann.
Könnte er den des Kollegen lesen wäre das natürlich fatal. (der lokal Admin wird auch nicht des Schlüssel lesen key, den der User eingegeben hat. Er kann ihn nur löschen und neu setzen.)
Sich als Hilfsuser(als Admin ist sicher nicht nötig) anzumelden nur um den WLAN Schlüssel vor dem User zu verbergen ist ja auch nicht sinnvoll.
Was soll der Aufwand?
(Warum) kann ein andere User überhaupt eine fremdesWLAN benutzen?
Wenn ich eine RJ45 LAN Dose habe, kann auch jeder, der meinen Rechner booten kann, diese benutzen.
Ein WLAN ist ja eigentlich nur ein Switch, ohne Kabel.
Will ich nicht, das jeder überall ins LAN kommt, benutze ich xPZ. B. eine Radius Authentifizierung die den Zugriff auf Ethernet-Ebene user spezifisch regelt. Das glt natürlich auch auf WLAN. Aber selbst dabei liegt der Schlüssel im Klartext auf dem Client, aber jeder User (!) hat sein Passwort.
Anyway :
Was genau soll verhindert werden, wenn der User den WLAN Schlüssel nicht sieht?
Wieso ist das ein Sicherheits Problem?
Denke mal an Umgebungen wie eine Firma, welche das WLAN nicht per RADIUS Server betreibt. Da teilen sich dann vielleicht 10-15 Geräte den gleichen PreSharedKey. Es ist sehr umständlich diesen auf allen Geräten zu ändern. Kommen Anwender an den WLAN Key, dann ist das schon ein Risiko, weil sich diese so auch mit anderen Geräten am WLAN anmelden könnten.
Ich sage nur verärgerter EX-Mitarbeiter am Wochenende mit Kali-Linux und einem Hang zu destruktiven Aktionen. Keine sehr gute Kombination.
Frage wäre noch: Wo merkt sich Windows den User zum PSK? Registry? Ließe sich das per GPO einfach überschreiben?
Destruktive Mitarbeiter mit Kali (was per se schon mal voraussetzt, dass es ein IT-Mitarbeiter ist) sind immer eine schlechte Kombination.
Das WLAN-Kennwort dient an keiner Stelle einer Sicherheit – ausgenommen von der Authentifizierung. Es sollte dahingehend auch nicht so behandelt werden.
Wenn eine Firma kein Radius nutzt hat sie ein massives Problem. Sag ich mal ganz nett.
Was soll das für eine Firma sein? Ändern die dann bei jeder Kündigung, jedem Azubi und jedem Externen der geht das WLAN-Passwort?
Für sowas gibt es nunmal RADIUS, dass man keine PSK -Probleme hat.
Ich denke ihr unterschätzt wie viele kleine Firmen mit Consumer Hardware wie Fritz!Box arbeiten. Klar sollte das nicht sein, aber Exchange sollte auch gepatched sein und VMware ebenso. Die Realität entspricht häufig nicht dem Sollzustand.
Der Nutzer kann zum Beispiel weitere Geräte ins Netzwerk bringen, ein privates Laptop oder ein Smartphone, das ist wiederum eine Sicherheitslücke da sich auf dem Geräten Schadsoftware befinden kann.
Man könnte noch hingehen und die Netzwerke so absichern, daß nur bekannte Mac-Adressen eine IP bekommen.
Bitte nicht das Ammen-Märchen von der unveränderlichen uniquen Mac-Adresse.
Möglichst noch den Tipp, das man zur Sicherheit die SSID verstecken sollte :-)
Da gehört ein Zertifikat auf das Gerät, auch um Zugriff zum LAN zu bekommen.leider wird das vernachlässigt.
Wozu braucht ein WLAN denn überhaupt einen Schlüssel?
Doch nicht aus „Sicherheitsgründen“ , sondern weil man keine Nutzung durch Dritte möchte / erlauben darf(Störerhaftung) .
Wenn ich bei Ikea reingehen, sehe ich da ein „offenes WLAN“ . Ich muß nur Abnicken dass ich kein Terrorist bin. Manchmal nicht mal das.
Dafür, das meine Daten in dem fremden Netz nicht unbefugt kopiert bin ja wohl allein ich verantwortlich. Wer mit klarem Verstand würde sich auf den Anbieter eines WLANs verlassen? Vielleicht wurde er schon gehackt?
Wenn man in einer Firma nicht will, das 400 mit ihren Handies die komplette Gast-Bandbreite ziehen, muss ich wohl das irgendwie eingrenzen. Das Eenfachste ist ein WLAN Schlüssel, wenn der Chef das nicht anders durchsetzen möchte. Das hat aber nix mit Sicherheit zutun. Da bin andere Meinung.
Zitat: „Wenn man in einer Firma nicht will, das 400 mit ihren Handies die komplette Gast-Bandbreite ziehen, muss ich wohl das irgendwie eingrenzen.“
Es geht hier ja nicht um Gastnetze und Bandbreite. In Produktivnetzen ist es sehr wohl ein Sicherheitsproblem, wenn sich unbefugte (Privat-)Geräte verbinden können. Daher ist grundsätzlich davon abzuraten, ein Produktivnetz mit einem Pre-shared Key abzusichern. Radius ist da die bessere Wahl.
Da gibt es doch Programme zum Auslesen.
E-Mail: „Mail PassView Download“
https://winfuture.de/downloadvorschalt,3026.html
Wlan: „WirelessKeyView“
https://www.chip.de/downloads/WirelessKeyView_28751595.html
„WiFi Password Finder“
Lieber mal den Artikel lesen. Es geht darum, dass es ohne Admin-Rechte geht. Wozu ein komisches Tool laden, wenn es mit 1 Zeile CMD geht.
https://de.wikipedia.org/wiki/Rubber_Ducky
Bei manchen dieser Programme wird der Virenscanner Alarm schlagen, da diese evtl. mal Teil von Ransomware-Paketen waren. (Eine bestimmte Version).
Unter Ubuntu kann man man den Key anzeigen mit:
nmcli device wifi show-password
Unter Android kann man den Key in den Wlan-Einstellungen anzeigen lassen.
Geht bei mir nur mit sudo… Ohne bekomme ich immerhin die SSID, die Sicherheit („WPA“) und einen schönen QR-Code – eben ohne Passwort.
Das Problem ist hier doch ein vollkommen anderes, nämlich, dass im genannten Beispiel mit „unpersönlichen“ Benutzerkonten gearbeitet wird. Ein absolutes No-Go – egal, wie die Begründung dafür lautet.
Und nur hierdurch ist die Situation zustande gekommen, dass eine Person das WLAN-Kennwort einsehen konnte, die es selber vorher gar nicht eingegeben hat.
Man scheint dort auch noch nichts vom Kiosk – Mode für die Gast/ unpersönlichen Rechner gehört zu haben.
Und sich dann über einen aus lesbaren WLAN Schlüssel aufregen?
Und
Was macht der Gast überhaupt?
Der darf ins Internet. Ende aus.
Wo genau ist da ein Sicherheits-Problem?
Wie gesagt. Wenn der Kunde da ein Problem hat, sollte er auch seine RJ45 Buchsen auch per Radius verteilen.
Das Schöne daran wäre, dass man so auch gleich jedem User seine VLAN zuordnen kann, ohne rumstecken zu müssen. Und der User kann seinen Rechner anschließen wo er will. Er sieht immer nur seine Ressourcen oder garnichts.
So kommt ein User aus dem Marketing nicht an Entwicklungs Rechner, auch wenn er sich da ins LAN einstöpselt.
Aber die Rechner der Entwicklung haben ja alle auch Passwörter. Em, ja. Noch nie etwas von remote exploits gehört? Da wäre es schon schön wenn man die Rechner nicht nur per Router trennen würde, zumal das erheblich Performance kostet.
Leider wird es dadurch nicht einfacher.
Aber das ist ja immer das Dilemma mit Sicherheit – Kosten – Komfort.
Dürfte ein Relikt der historischen WLAN-Otimierung mit Teilen des WLAN-Schlüssels sein: https://www.spiegel.de/netzwelt/web/microsoft-windows-10-ist-die-neue-wlan-teilen-funktion-sicher-a-1041996.html – um weiterzugeben braucht man wohl erstmal Zugriff. Vermutlich wurde es eingestellt, weil Microsoft sein Versprechen nicht halten konnte: „Das Unternehmen verspricht allerdings, dass die Empfänger der Daten die Passwörter nicht im Klartext lesen können. Andernfalls könnten diese die Zugangsdaten ja unkontrolliert verbreiten.“
Es gibt einem guten Grund warum die NIST das Zero Trust Prinzip empfiehlt.
Schon seit Jahren gibt es im Netz viele Geräte die alle Updates machen oder nach Hause telefonieren über die man nur selten Kontrolle hat.
Wo ist denn der Unterschied ob ein Nachbar im lokalen Netz ist oder ein Chinese?
Das ist ähnlich wie die Sitte zu glauben gespeicherten Kennwörter im Browser sind sicher.
Das Konzept Benutzer verwendet gemeinsam mehrere Programme ist halt sehr alt, und problematisch. Denn jedes Programm kann alle Benutzer Daten lesen unter Windows.
Besser macht es Android.
Das ist jetzt nicht wirklich was neues.
https://www.howtogeek.com/426257/how-to-see-all-your-pcs-saved-wi-fi-passwords/
PSK ist „broken by design“ und hat im Unternehmensumfeld keine Daseinsberechtigung.
Egal wie ein PSK angelegt wird; als User, als Admin oder auch per Policy; der PSK kann nicht vor dem Auslesen durch unpriviligierte Benutzer geschützt werden.
Das ist doch ein alter Hut und ein einschlägiger Blog hat schon 2016 darüber berichtet:
https://www.borncity.com/blog/2016/04/26/windows-10-gespeicherte-wlan-kennwrter-auslesen/
Microsoft hat über 5 Jahre Zeit gehabt, die Sicherheitslücke zu beheben.
Was ist passiert?
Nichts??!!
It´s not a bug, it´s a feature.
Ungeachtet dessen bleibt es ein alter Hut, über den hier im Forum schon vor sieben Jahren berichtet wurde.
Sämtliche Kritik in Ehren. Ja, ein PSK dient nicht der (Netzwerk-)Sicherheit, sondern der Abwehr gegen unerwünschter Fremdnutzung des WLAN. Soweit bin ich bei euch. Und ja, ein WLAN ohne RADIUS ist an sich ein Sicherheitsrisiko, welches bei Kleinbetrieben aber ggf. vernachlässigbar ist.
Dass man das Passwort mit irgendwelchen Drittanbieter-Tools auslesen kann, war mir natürlich auch bekannt. Die meisten davon erfordern aber für die Installation Adminrechte. Und falls nein, muss das Tool erstmals heruntergeladen werden, wobei teilweise der Defender oder eine andere Antivirussoftware anschlagen kann.
Beim genannten Fall ging es um Schülerlaptops an einer Sonderschule. Auf den betreffenden Geräten ist nebst einem lokalen Admin bewusst nur ein lokales Konto für den ‚user‘ aka Schüler eingerichtet.
Wenn eine Lehrperson das WLAN-Passwort mit angemeldetem ‚user‘ eingibt, und ein beliebiger Schüler später das Passwort auslesen kann, kann er eben auch sein iPhone /Android Smartphone oder andere Geräte mit dem gleichen WLAN verbinden. Das ist einerseits nicht erwünscht und andererseits belegen diese Zusatzgeräte dann IP-Adressen aus dem DHCP-Bereich, was – theoretisch – dazu führen kann, dass keine Adresse mehr für ein anderes/offizielles Gerät verfügbar ist.
Ob bzw. inwiefern manche Trojaner/Malware zusätzlichen Schaden anrichten könnten, ist ein Aspekt, den ich hier nicht diskutieren will.
Danke an Paul für den Hinweis wegen dem Kiosk-Mode. Das wäre ggf. eine Möglichkeit. Vom Ansatz her ist mir dieser bekannt, ich habe mich aber nie genauer damit befasst.
Schliesslich soll aber doch noch gesagt sein, dass (fast) alle vorherigen Kommentare am eigentlichen Problem vorbeigehen.
Dass ein Standard-Benutzer das WLAN-Passwort ohne Zusatztools auslesen kann, mag noch knapp akzeptabel sein. Dass das einem Gast ebenso erlaubt ist, dürfte aber wirklich nicht sein.
Das Hauptproblem dürfte aus meiner Sicht ein „Man in the Middle Angriff“ darstellen.
-Auslesen der bekannten SSIDs und der Zugangsdaten
-Fake-Router mit diesen Daten konfigurieren.
-PC verbindet automatisch mit dem Fake WLAN
-DNS des Fake WLAN lenkt bank.de nach bank.ru um und greift Zugangsdaten ab
Also wenn das so gemacht werden soll, dann würde ich mal versuchen einen 3. Account ohne Admin Rechte ein richten, der nur eines darf: Den WLAN Schlüssel setzen.
Der Gedanke, das sich ein Admin lokal anmelden muss fände ich nicht gut…
Ich hätte höchstens Sorge das da unendlich viel Bandbreite verbraten wird und z. B. videos gestreamt werden…
Besser wäre auf Radius umzusteigen. Aber wahrscheinlich ist haben die da nur ne Paläste-Kiste, die das nicht bietet. Der Radius Server muss ja auch irgendwo hin…
Evtl. Könnte man die Clients per VPNs anschließen und das WLAN nicht natten so das es für das Handy uninteressant wird, weik man nicht raus kommt.
Plaste-Kiste
In der Standardkonfiguration erzeugt Windows WLAN Profile für alle Benutzer.
netsh wlan show createalluserprofile
netsh wlan show allowexplicitcreds
netsh wlan show settings
Vielleicht hängt es damit zusammen, ansonsten wüsste ich nicht, warum ein Benutzer sein eigenes Passwort nicht lesen können sollte.
Das ist ein Microsoft-Skandal. Ich verwende einen Passwort-Manager. Da sind alle Passwörter verschlüsselt. Wenn ich die Passowort-Datenbank öffne sind für das freie Auge die Passwörter immer noch nicht einsehbar. Wenn ich ein Passwort in die Zwischenablage kopiere, dann muss ich dass Passwort innerhalb von 10 Sekunden verwenden, weil sonst die Zwischenablage automatisch gelöscht wird.
Jetzt erkenne ich, dass die WLAN-Passwörter von Microsoft jederzeit einsehbar sind – ohne der Notwendigkeit der Eingabe eines Masterpassworts wie bei einem Passwortmanager.
Auf meinem Windows 10 Rechner benötigt man kein ADMIN-Passwort.
Ungeheuerlich ist das Ganze.
Das ist weder „ungeheuerlich“, noch ein „Skandal“. Wenn ich irgendwo ein Passwort eingebe, wird das für gewöhnlich auch irgendwo gespeichert. Es gibt Schutzmechanismen (Hashes), die eher mittelsicher sind, diese kann man mit „salted“ und „peppered“ weiter absichern. Aber das Passwort steht irgendwo. Und ein Passwort wird für gewöhnlich auch übertragen.
„Ungeheuerlich“ oder ein „Skandal“ ist es, wenn der Anwender blind darauf vertraut, dass das Betriebssystem bzw. die Software schon alles richtig macht und dass der Einsatz eines Passwortmanagers diese vorgelagerten Probleme heilen würde.
Normaler Weise wird kein Passwort als Klartext gespeichert, sondern das Login erzeugt einen Hash und diese Hashes werden verglichen.
Ich habe allerdings neulich den wohl „den neusten Sch*eis“ gesehen:
Ein Treiber, der sich vor die Gina.Dll setzt und bei jedem Einloggen das Passwort online mit den bekannten Blacklists abgleicht und den User warnt, wenn sein Passwort im Darknet zu kaufen war.
Dazu muß das Klartext Passwort bekannt sein und entweder als Klartext gegen die Datenbank gefahren werden oder jeder Kunde müsste eigne Hashwerte in der Datenbank haben. Sonst weiß der Anbieter oder ein Lauscher ja, welches Passwort ich habe, wenn es in der Liste ist.
Aber es gibt Leute die kaufen das und sagen, das sie DSGV konform sind…
Man muss hier ganz klar zwischen dem Betrieb eines WLAN im Unternehmensumfeld, in dem es kritische Daten gibt, und dem privaten Umfeld unterscheiden. Im Unternehmensumfeld ist WLAN immer schon ein potentielles und schweres Sicherheitsrisiko gewesen. Man kann das mit Radius absichern, dann wird es aber aufwändig und vor allem teuer. Besonders, wenn man nicht nur die üblichen 100qm Wohnungsgröße, sondern große Gebäude über mehrere Etagen und Gelände großen Ausmaßes versorgen muss. Die Diskussion führe ich nun seit Jahrzehnten mit Anwendern und „Entscheidern“, die nur über ein gefährliches Halbwissen verfügen und es stets besser zu wissen meinen. Schließlich hat der eigene Sohn die FritzBox doch auch selbst installieren können.
Dass sich die Passwörter dermaßen leicht ermitteln lassen, halte ich im Unternehmensumfeld für ein Problem. Schon weil ich als Admin das Kennwort des WLANs eines Home Office Users auslesen kann. Im Enduser Umfeld hingegen ist das eher zu vernachlässigen, weil Sicherheit dort nur eine untergeordnete Rolle spielt. Trotzdem nicht schön…
Im Unternehmensumfeld halte ich es seit Jahren so: Es wird ein komplett separates WLAN eingerichtet, das komplett vom Unternehmens LAN getrennt ist. Die meisten Internetanschlüsse bieten die Möglichkeiten dafür (am Router vor der Unternehmens Firewall mit eigener IP Adresse). Daran wird ein Router mit Captive Portal betrieben. Gäste kommen so ins Internet. Mitarbeiter müssen den VPN Tunnel dafür starten. WLAN im Unternehmens LAN: Never Ever!
WLAN mit WPA-Enterprise ist so ein Ding, insbesondere wenn dafür als Radius-Server ein Windows-DC herhält. Da bekommt man keine Linux-Systeme dran.
Die Idee mit dem offenen Gäste-WLAN und dann VPN aufbauen ist da besser.
Hm, hast Du ggf. ein paar weitere Informationen?
Zum Thema gespeicherte Kennwörter gab es vor 2 Wochen einen Artikel von Raymond Chen: https://devblogs.microsoft.com/oldnewthing/20230206-00/?p=107797
Herr Raymond Chen hat mich nicht überzeugt. Ich möchte meine Passwörter auf meinem Rechner verschlüsselt gespeichert haben. Wenn ich meine 50-stelligen Passwörter mir real ansehen will, dann möchte ich ein Masterpasswort eingeben müssen. Bei der Verwendung eines Passwortmanager habe ich entsprechende Funktionen. Solche Funktionen will ich auch für das Betriebssystem Windows haben. Ich will nicht, dass Microsoft irgendwo meine Passwörter speichert, die sehr einfach auszulesen sind.
Dass ein User den von ihm selbst gespeicherten Key wieder auslesen kann, ist jetzt nicht sonderlich überraschend. Dass ein Admin-User an die Keys aller User kommen kann, genauso wenig.
Aber, ich habe ein wenig damit herumgespielt und zumindest auf meinem Testrechner etwas gefunden, das ich für ein echtes Problem halte: ein unprivilegierter User (ohne Admin-Rechte) kann den Key eines WLAN-Profils auslesen, das per Bereitstellungspaket während des OOBE angelegt wurde! Das sollte m. E. auf keinen Fall möglich sein, denn es wurde ja nicht von dem User selbst angelegt, sondern vermutlich von SYSTEM.
Die Berechtigungen scheinen mir unter HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WlanSvc\Interfaces\{GUID des Interfaces}\Profiles\{GUID des WLAN-Profils}\MetaData zu liegen. Da gibt es einen Eintrag „All User Profile Security Descriptor“ (der aber immer gleich zu sein scheint?) sowie einen Eintrag „CreatorSid“. Der Name legt nahe, dass hier der Besitzer des WLAN-Profils drin steht. Im Falle des Bereitstellungspaket-WLAN-Profils ist da hex:01,01,00,00,00,00,00,01,00,00,00,00 eingetragen. Ich habe mal versuchsweise diesen Wert durch den eines anderen WLAN-Profils ersetzt, das manuell von einem Admin-User angelegt wurde. Und schon konnte ich mit dem Standard-User den Key nicht mehr auslesen.
Habe das jetzt per PowerShell behoben und hier darüber gebloggt:
https://medium.com/@damiel_gc/dont-leak-my-wifi-key-305671b51c5c
es hängt auch mit „createalluserprofile“ zusammen:
netsh set createalluserprofile enable=no
=> neue WLAN Profile werden mit \SOFTWARE\Microsoft\WlanSvc\Interfaces\{GUID des Interfaces}\Profiles\{GUID des WLAN-Profils}\MetaData
„All User Profile Security Descriptor“
O:SYG:SYD:(A;;CCRC;;;BU)(A;;CCWPRC;;;BU)(A;;CCRC;;;NO)(A;;CCWPRC;;;NO)(A;;CCDCWPSDRCWD;;;NO)(A;;CCRC;;;BA)(A;;CCWPRC;;;BA)(A;;CCDCWPSDRCWD;;;BA)(D;;FA;;;WD)
es fehlt „BUILTIN\Benutzer: AccessAllowed (ChangePermissions, Delete, ListDirectory, ReadPermissions, Traverse, WriteData)“
=> ohne Adminrechte lässt sich der Key auch nicht mehr „netsh show profile xyz key=clear“ auslesen. Ein Zurücksetzen des Parameters „createalluserprofile“ ändert nichts für bestehende WLAN Profile, nur für neu hinzugefügte WLAN Profile.