XSS – ein kleiner Fehler bei der Produktivierung von Web-SW kann schwere Folgen haben …

Letzte Woche war ich damit beschäftigt, das Hacking einer PHP-basierten Website nachzuvollziehen. Die Analyse ergab gleich mehrere Fehler, die sich in Kombination zu einem massiven Problem auswuchsen:

  1. Eine zentrale Datei, die das Umschreiben von gewöhnlichen Web-Adressen auf PHP-Skripts vornahm und schon seit ca. über einem Jahr ohne Probleme im Einsatz war, war kürzlich an einigen Stellen modifiziert worden. In der Testphase war diese Datei "auf die Schnelle" leider mit Statements versehen worden, die Adress-Anteile ungefiltert über PHP-"echo"-Kommandos ausgab. Im Produktivierungsprozess wurde dann "in der Hektik" vergessen, diese Statements vollständig zu deaktivieren. Jeder, der sich ein wenig mit PHP und Sicherheit auskennt, weiß, dass solche Kommandos das primäre Einfallstor für XSS-Angriffe darstellen.
  2. In den Tests vor der Produktivsetzung wurde zwar verifiziert, dass die Website mit all ihren Links korrekt lief. Der geänderte Rewrite-Prozess für Adressen wurde somit positiv bestätigt. Leider wurden Negativtests für bestimmte Typen von fehlerhaften Adresseingaben bzw. Adresseingaben zu nicht vorhandenen Seiten nicht im notwendigen Umfang durchgeführt. Solche Tests hätten schnell und deutlich gezeigt, dass manipulierte Eingaben und z.T. auch erratische Eingaben zu fehlenden Seiten ungefilterte Programm-Ausgaben zeitigten. So fiel das aber leider gar nicht auf.
  3. Durch Einschleusen von Javascript-Code konnte von Angreifern die DOM-Ebene manipuliert werden. Das ließ sich relativ leicht nachstellen. Allein dieser Punkt eröffnete bereits ein großes Schadenspotential. Als schlimmer erwies sich aber die durch XSS eröffnete Möglichkeit zum Auslesen von Session-Cookies. Dadurch stand einer Session-Übernahme nur noch wenig entgegen. Als besonders schlimm stellte sich das für Sessions heraus, in denen ein Zugriff auf eine ältere PhpMyAdmin-Installation stattfand. Leider war das Programm wegen fehlender SSL-Zertifikate in der gleichen Web-Domäne untergebracht worden. Hier war am falschen Ende gespart worden: Das Gemeine ist, dass sich eine "Sicherheits"-Überlegung - nämlich die notwendige Verschlüsselung von Transaktionen zur Datenbank-Pflege - im hier beschriebenen Angriffsszenario als Bumerang erwies.
  4. Interessanterweise nutzten die Angreifer die Sessionübernahme nicht direkt zur Manipulation der Datenbankinhalte. Die ältere PHP-Version wies nämlich auch noch eine Verwundbarkeit nach CVE-2017-9841 auf: Ein standardmäßig mit ausgeliefertes PHP-Programm eines Vendors beinhaltete einen eval()-Aufruf. Dadurch wurde dann die Ausführung von relativ beliebigem PHP-Code ermöglicht.
  5. Für die Website wurde keine TLS/SSL-Verschlüsselung erzwungen.

Im Endeffekt war durch die Kombination der obigen Punkte das Tor zu einem Hacker-Paradies geöffnet wurde; missbraucht wurde die Site denn auch prompt von Angreifern mit IP-Adressen in Albanien, Bulgarien, Rumänien, USA.

Was lernt man aus diesem Szenario?

Der Ablauf ist geradezu klassisch: Hastiges Arbeiten und Unaufmerksamkeiten eines Entwicklers reißen in der Konsequenz ein großes Loch in den Betrieb einer Website.

Worin lag im Ablauf aber der eigentliche Fehler? Dass beim schnellen Coding ein sauberes Exception-Handling mal umgangen wird, ist eine Sache. Ein PHP-Code mit echo-Befehlen, die eine ungefilterte Ausgabe auch nur fragmentierter Teile irgend eines Inputs liefern, darf aber keine QS passieren.

Hier meine ich einerseits ein Code-Review samt Scannen des Codes auf print oder echo-Befehle. Ich meine andererseits aber auch den Testansatz: Wenn man einem Rewrite-Programm für Adressen arbeitet, sollte man natürlich unbedingt das Verhalten für ungewöhnlichen Adress-Input testen. Ferner hätte eine Überwachung der Log-Protokolle einen Missbrauch eher entdecken lassen, als es dann de facto geschehen ist (nämlich durch den Hosting-Provider).

Ein weiterer Fehler liegt natürlich in der alten Version von PhpMyAdmin - hierfür hätten die herausgegebenen Warnungen CVEs, etc. verfolgt werden müssen. Das Risiko, dass mit der Positionierung dieser SW in derselben Domäne im Fall eines XSS-Angriffs verbunden war, war unterschätzt worden.

Eine interessante Frage im Rahmen dieses Blogs ist nun:
Hätte hier ein ISMS nach der ISO /IEC 27000 geholfen?

Ich meine schon. Im Rahmen der Risko-Analyse und Risiko-Bewertung hätte das Thema Web-Anwendungen und zugrunde liegende Programme sicher eine Rolle gespielt. Die Problematik von XSS-Angriffen hätte dort (u.a.) untersucht werden müssen. Als Maßnahme zur Risikobehandlung wären dann mit hoher Wahrscheinlichkeit die hier unterlassenen Schritte als Teil eines einzuhaltenden "Produktivierungsplans" definiert worden. Betroffen sind im hier gegebenen Kontext gleich eine ganze Reihe von in der Praxis obligatorischen Maßnahmen-Vorgaben des Anhangs zur Norm ISO/IEC 270001: Zu nennen sind die Maßnahmen A10.1, A10.3, A10.9, A10.10. Relevant sind ferner A11.5, A12 (bes. A12.2.4, A12.4, A12.5, A12.6), A15.2, A15.3.

Ich will gar nicht auf Details der Punkte eingehen. Man ist aber immer wieder erstaunt, wie gut eigentlich der Maßnahmenkatalog der Norm bei geeigneter Umsetzung helfen würde, Szenarien wie das oben beschriebene zu vermeiden.

SSH, Linux und die stetige Veränderung von Sicherheit – I

Setzt man sich mit IT-Sicherheit auseinander, so ist eine der faszinierenden, aber auch erschreckenden Tatsachen die, dass als sicher eingeschätzte Fundamente mit der Zeit erodieren. Das gilt für Open-Source-SW ebenso wie für Produkte proprietärer Hersteller. Auch bei konsequenter Update-Politik bleibt immer ein Rest an Unsicherheit.

Im Open-Source-Bereich erlebte SSL/TLS in der OpenSSL-Implementierung mit dem "Heartbleed-Bug" ein abruptes und unsanftes Erwachen aus dem Dornröschen-Schlaf. Dann kam der "Shellshock"-Bug. Ursache waren in beiden Fällen echte SW-Fehler, die sich beheben ließen. Für den Linux-Server-Administrator erschöpfte sich die notwendige Reaktion im Einspielen zeitnah bereitgestellter Updates der Linux-Distribution seines Vertrauens. Aber reicht das immer? Und wenn schon Bugs vorhanden sind - wer sagt einem, dass nicht auch viel grundsätzlichere, z.B. algorithmische Schwächen unsere aktuellen Security-Tools kennzeichnen? So fragt man sich als besorgter Admin immer mal wieder:

Wie sieht es eigentlich mit SSH - genauer OpenSSH - aus?

Unzweifelhaft gehört SSH zu den zentralen Handwerkszeugen, die den Alltag von Systemadministratoren nicht nur im Linux-Umfeld prägen. Ohne SSH kein SFTP, ohne SSH keine sichere Remote-Serveradministration, ohne SSH kein VPN over SSH (z.B. in problematischen Staaten). Es ist wohl keine Übertreibung zu sagen: Ist SSH bedroht, fallen Grundfesten der IT-Sicherheit. Auch im Linux-Umfeld. Trägt man konkrete Verantwortung für die Geheimhaltung von Unternehmensdaten steht deshalb früher oder später die Frage im Raum:

Muss man sich im Falle der Installation und Konfiguration von SSH neben Updates ggf. auch mit Kryptokomponenten befassen, die jenseits der praxisnahen Erzeugung von Schlüsseln für "Public Key"-Authentifizierungsverfahren liegen? Und wer gibt einem im Zweifel dafür vertrauenswürdige Richtlinien an die Hand? Fragen genug für ein paar Blog-Beiträge.

Begründeter Anlass zur Sorge?

Seit ziemlich genau einem Jahr gab es mehrfach Anlass, sich um die SSH-Konfiguration auf eigenen Servern Gedanken bis Sorgen zu machen. Das begann mit einer Untersuchung, deren Ergebnisse erstmals im Mai 2015 diskutiert und dann auf einer Sicherheitstagung im Herbst 2015 präsentiert und als Paper veröffentlicht wurden. Gegenstand des Papers sind potentielle Schwächen eines asymmetrischen Krypto-Verfahrens (Diffie-Hellman-Merkle [DHM]), das u.a. im Rahmen von SSH, TLS und IKE/IPsec zum Einsatz kommt. Ich fand es wenig beruhigend, wie die Studie nachvollziehbar vermittelte, dass ca. 25% aller SSH-Verbindungen mit den Ressourcen eines Staates angreifbar sein sollten.

Ich selbst ordne eine solche Thematik weniger unter dem Blickwinkel einer Totalüberwachung durch mehr oder weniger freundlich gesinnte Sicherheitsorgane irgendwelcher Staaten ein, als vielmehr unter dem Aspekt einer potentiellen und durch Staaten gestützten Wirtschafts- und Industriespionage. Ein wichtiger Punkt für unseren deutschen Mittelstand und darunter gerade für kleinere innovative Firmen, die auf Open-Source setzen.

Auch die praktischen Konsequenzen für System-Administratoren trugen nicht gerade zu meiner Nachtruhe bei:

Aus meiner Sicht waren über Konfigurationseinstellungen mathematische Verfahren einzuschränken oder zumindest zu priorisieren, die unter DHM und damit auch SSH zum Einsatz kommen. Ein besseres Verständnis setzte eine intensivere Auseinandersetzung mit Krypto-Verfahren und deren Vertrauenswürdigkeit voraus. Das Ergebnis entsprechender Recherchen war wiederum nicht als Beruhigungsmittel geeignet. Und zu guter Letzt äußerten sich NSA-Vertretern vor kurzem ganz grundsätzlich zur Zukunft asymmetrischer kryptographischer Verfahren. Die getroffenen Aussagen betreffen u.a. auch SSH und wurden von Experten unterschiedlich gewertet, was wiederum eher zur Verwirrung bzgl. der praktischen Konsequenzen beitrug.

Zeit also für eine kleine Auseinandersetzung mit diesen Punkten. Eine Grundsatzdiskussion, ob man nicht-europäischen Herstellern proprietärer Betriebssystem-Software, die aufgrund der Gesetzeslage im eigenen Land ggf. mit Geheimdiensten zusammenarbeiten müssen, bzgl. der sicheren Implementierung von kryptographischen Systemkomponenten trauen kann, erspare ich mir dabei. Ich beschränke mich hier auf Konsequenzen für Linux-Systeme.

Gliederung der Beitragsserie

Nicht jeder Linux-Admin kennt Grundlagen der Kryptographie. Um die Risiken klarer einzuordnen, ist aber zumindest ein oberflächlicher Blick hinter die Kulissen notwendig. Leser, die mit den Grundlagen (symmetrische Kryptographie, asymmetrische Verfahren, Faktorisierung großer Zahlen, Primzahlen, Modulo-Operationen) vertraut sind, werden sich dagegen mit einigen Ausführungen langweilen. Ich teile deshalb die Auseinandersetzung in mehrere Beiträge auf, die je nach Lust und Laune auch übersprungen werden können.

  • Zunächst möchte ich oben genannte Schlüsselpublikation aus dem letzten Jahr in Erinnerung rufen - und hierzu ein paar Links zusammenstellen. Dabei möchte ich auch einen Blick darauf werfen, wie die Untersuchung vom BSI bzw. CERT-EU verarbeitet wurde. Für Systemadministratoren war die Konsequenz abzuleiten, sich nicht nur mit SSH-Updates sondern auch mit Konfigurationseinstellungen von SSH zu befassen.
  • In einem weiteren Beitrag wende ich mich dann ein paar Details der diagnostizierten Schwächen im initialen Schlüsselaustausch zu. Aus den dortigen Ausführungen sollte einerseits klar werden, wie wichtig die Absicherung des initialen "Key Exchange"-Verfahrens ist [KEX]. In Kombination mit den Untersuchungen aus 2015 ergibt sich, dass der vorsichtige Administrator bestimmte KEX-Verfahren in seiner SSH-Konfiguration eigener Server ausschließen wird; selbst wenn der SSH-Standard sie erfordert.
  • Anschließend möchte ich kurz auf Alternativen zum klassischen Diffie-Hellmann-Verfahren eingehen. Ohne auf Details einzugehen, ist auch dort darauf hinzuweisen, dass bestimmte sog. Elliptic Curve basierte KEX-Verfahren u.U. mit Vorsicht zu genießen sind, selbst wenn sie nicht die 2015 entdeckten Schwächen aufweisen. Dies deuten zumindest andere Untersuchungen an.
  • In einem weiteren Teil möchte ich dann auf etwas Banales hinweisen, das aber in der Praxis von sog. "günstigen" Linux-Implementierungen durchaus eine Rolle spielen kann - nämlich die Kollision von Upgrade- und Update-Politik in nur zeitweise mit Sicherheitsupdates versorgten Linux-Distributionen. Ich werfe dabei einen Blick auf 2016 offiziell verfügbare Updates zu OpenSSH für eine bestimmte Opensuse-Variante.
  • Ein weiterer Teil stellt dann konkrete Hinweise zur Konfiguration von SSH bzgl. DHM zusammen.
  • Ein letzter Artikel befasst sich mit dem Abrücken ausgerechnet der NSA von bestimmten Grundlagen asymmetrischer Krypto-Verfahren.

Die große Passwort-Sammlung … Wi-Fi Sense unter Win 10

Es ist schon interessant, wie unterschiedlich die im Moment im Entstehen befindliche und am Ende wohl recht umfassende Passwort-Sammlung zu Wi-Fi-Geräten dieser Welt wie auch die zugrunde liegenden "Features" eines seit kurzem auf dem Markt erhältlichen PC-Betriebssystems von Sicherheitsexperten beurteilt werden. Ja, Sie erraten es schon: Es geht um "Wi-Fi Sense" unter MS Windows 10/Windows Phone 8.1.

Siehe hierzu auch

https://grahamcluley.com/2015/08/windows-10-wifi/
http://krebsonsecurity.com/2015/07/windows-10-shares-your-wi-fi-with-contacts/
http://www.silicon.de/41615267/windows-10-sicherheitsexperte-kritisiert-wlan-sharing/
http://www.zdnet.de/88242223/windows-10-wlan-sharing-greift-auf-kontakte-zu/
http://www.spiegel.de/netzwelt/web/microsoft-windows-10-ist-die-neue-wlan-teilen-funktion-sicher-a-1041996.html
http://www.extremetech.com/extreme/209208-windows-10s-new-wifi-sense-shares-your-wifi-password-with-facebook-outlook-and-skype-contacts
http://www.pcgameshardware.de/Windows-10-Software-259581/News/FAQ-zur-WLAN-Passwortfreigabe-1166576/
http://reviews.gizmodo.com/why-the-hell-is-windows-10-sharing-my-wi-fi-passwords-1719900675
http://www.rockpapershotgun.com/2015/07/28/windows-10-wifi-sharing/
http://www.computing.co.uk/ctg/news/2415787/windows-10-wi-fi-sense-security-warning-over-automatically-shared-passwords
https://www.404techsupport.com/2015/06/windows10-network-security-wifisense/
http://www.cnet.com/how-to/how-to-kill-wi-fi-password-sharing-in-windows-10/
http://www.geek.com/microsoft/windows-10-wifi-sense-does-not-share-your-passwords-1630014/
http://money.cnn.com/2015/07/30/technology/windows10-wifi-sense/
http://www.networkworld.com/article/2956393/windows/microsoft-windows-10-wi-fi-sense-an-astoundingly-bad-idea.html
http://arstechnica.com/gadgets/2015/07/wi-fi-sense-in-windows-10-yes-it-shares-your-passkeys-no-you-shouldnt-be-scared/
http://www.pcworld.com/article/2943752/wifi-passwordsharing-feature-in-windows-10-raises-security-concerns.html
https://itauditsecurity.wordpress.com/2015/07/30/no-sense-using-win10-wifi-sense/
http://www.theregister.co.uk/2015/06/30/windows_10_wi_fi_sense/
http://www.langer.ws/2015/07/sicherheit-nein-danke-windows-10-teilt-wlan-passwoerter-mit-der-welt/
http://www.golem.de/news/it-sicherheit-windows-10-kann-wlan-passwoerter-an-kontakte-verteilen-1507-115107-2.html
http://www.net-security.org/secworld.php?id=18584

 
Die Beurteilungen reichen von "Desaster" bis hin zu "nützlich" und "doch nicht so gefährlich, weil man schließlich ja etwas dagegen tun könne". Auch wenn ich selbst nie Win 10 auf einem Desktop oder Laptop einsetzen würde, ist das Thema aus einer generellen IT-Sicherheitsperspektive hochinteressant und fordert zur Meinungsbildung geradezu auf. Dazu möchte ich einige Überlegungen beisteuern.

Zunächst mal sei gesagt: Als Internet-Nutzer vertraut man auch anderen Organisationen und deren technischer Präsenz Passwörter an. Aber da entscheide in der Regel ich selbst im Rahmen von Anmeldevorgängen, ob ich anonym bleiben will und welches Risiko ich damit verbinde. Ferner ist die Information, die ich z.B. in einem Forum hinterlasse, genau in dem Maße begrenzt wie ich bereit bin, sie preiszugeben.

Viel wichtiger ist aber aus meiner Sicht: Ich bin bei vielen Internet- und Cloud-Diensten von Haus aus nicht der Illusion ausgesetzt, dass ich Herr über die eingesetzte Technik und die Sicherheit meiner Daten wäre. Es handelt sich nicht um eigene, persönliche und physikalisch greifbare technische Systeme in meinem Besitz. Geht es um gehostete Computer-Systeme wie Server, machen sich interessierte fachkundige Anwender denn auch sehr wohl intensiv mit den Sicherheitsvorkehrungen des Hosters und meinen eigenen Einflussmöglichkeiten auf die Sicherheit vertraut.

Im Falle von PCs oder Laptops unterliegen viele normale Nutzer jedoch der Ansicht, dass dort gelagerte Daten von ihnen selbst kontrolliert würden. Auch wenn dies im Fall von Closed Source Betriebssystemen im Kern natürlich als kaum beweisbare Annahme anzusehen ist - zumindest für den heute fast obligatorischen Fall, dass das Gerät regelmäßig ans Internet angeschlossen wird. In Wirklichkeit wussten/wissen wir ohne explizite Prüfung des Datenverkehrs unserer Systeme nach außen nie, wie privat welche unserer Daten wirklich noch waren oder sind. Die Admins des Bundestages können ein Lied hiervon singen ..ö. aber da ging es um Hacking von Passwörtern und nicht um das Betriebssystem als Passwort-Schleuder.

MS öffnet mit WI-FI Sense aus meiner Sicht nun die Büchse der Pandora für private Netze, PC-Systeme und deren Sicherheit. WI-FI-Sense ist aus Sicherheitsperspektive nicht nur wegen der Verbreitung von MS Win als kritisch anzusehen - sondern vor allem deshalb, weil wir es im Falle von Win 10 mit einer bereits recht weitgehenden Verschmelzung von Internet und PC-Betriebssystem zu tun haben. Das eröffnet einen unschönen Blick auf noch kommende, künftige Cloud-Entwicklungen.

Ich führe nachfolgend einige Gründe für meine wachsende Besorgnis an.

Passwörter zu WLAN-Access Points oder WLAN-Routern sind sicherheitsrelevant

Offenbar ist diese Binsenweisheit beim Design von Win 10 unter den Tisch gefallen. Deshalb nochmal im Klartext:

Passwörter für WLAN/Wi-FI Access Points und/oder WLAN-Router sind u.U. hoch sicherheitsrelevant - nicht nur für den Zugang zum Internet über Wi-Fi-Geräte, sondern für alle angeschlossenen Systeme im betroffenen Netzwerk (WLAN, aber auch per Router angeschlossene LANs) und seinen Segmenten insgesamt. Ich will das gar nicht im Detail begründen; wäre die Aussage falsch, dann hätte man weder WPA2 noch andere Netzwerksegemente, noch spezielle Firewalls für WLAN-Router erfinden müssen. Auch die vielen Artikel, in denen Heimanwender zum Einsatz von WPA/WPA2 aus guten Gründen gedrängt wurden, wären überflüssig. Zeil der Schutzmaßnahmen im Wi-FI-Zeitalter - wie u.a. eine verschlüsselte Passwortübertragung über Funk - war immer die Verhinderung einer unfreiwilligen Preisgabe von Passwörtern an unbefugte Dritte

Ein ungeschützter WLAN-Zugang eröffnet Angreifern eine Vielzahl von Angriffsvektoren auf dahinter liegende Systeme. Ein kluger Anwender, der die Passphrase für den Netzwerkzugang kennt, kann im betroffenen Netz beliebig viel Schaden anrichten, wenn er die dortigen Computersysteme erstmal auf Netzwerkebene direkt ansprechen kann. Dies gilt im Besonderen und gerade für MS-Systeme. Wer es nicht glaubt, mache sich mal mit Metasploit und den dort verfügbaren Tools vertraut.

Aber auch jemand der gar keine PC-- oder Server-Systeme im Netz angreifen will, sondern "nur" den Internet-Zugang selbst über den WI-FI-Access Point einer Firma oder Privatperson für illegale Zwecke (wie illegale Downloads oder aber das Übermitteln von bösartigen Nachrichten)nutzen will, kann erheblichen Schaden mit enormen rechtlichen Folgen anrichten.

Das sind - wie gesagt - Binsenweisheiten. Sie gelten in jedem Fall für Heimnetzwerke, aber leider auch für viel kleine Firmen, die für echte Sicherheitsvorkehrungen in ihren Mini-Netzen mit MS PCs kaum Zeit und Geld aufwenden können. Deswegen ist die Verwahrung und Nicht-Zugänglichkeit von Passwörtern ein hochsensibles Thema - daheim wie im Beruf. Die Weitergabe von Passwörtern für WLAN-Zugangspunkte und Router ist schon im privaten Bereich eine sehr persönliche Entscheidung und Vertrauenssache - in kleinen Firmen ist sie in jedem Fall sicherheitskritisch.

MS stellt diese Binsenwahrheiten jedoch mit den Standardeinstellungen von Win 10 auf den Kopf:

Wenn einem Betriebssystem für einen PC ( "Private (!) Computer") in der Standardeinstellung nicht einmal mehr Passwörter heilig sind, die den Zugänge zu offenkundig sicherheitskritischen technischen Systemen, welche sich in meinem Besitz und Zugriff befinden, eröffnen, und wenn solche Passwörter in der Standardeinstellung (!) des Systems in die Cloud verlagert und ggf. sogar durch ganze Gruppen von Dritten "geshared" werden, dann fragt man sich, welches Verständnis von Privatsphäre und Sicherheit die Erfinder eines solchen Systems überhaupt haben.

Jedenfalls ist dieses Verständnis nicht vom elementaren Prinzip "privacy by design" für Software und Betriebssysteme geleitet. Der "Standard" ist in Zukunft bei MS offenbar: Share everything with me and also third parties - ich nutze deine privaten Daten (s.u.) und verwalte zudem auch Passwörter für deine technischen Geräte in der Cloud - genauer auf MS-Servern. Zudem sorge ich dafür, dass auch andere diese Passwörter nutzen können, wenn du oder ein Dritter (s.u.) diese Passwörter an andere verteilen wollen. Ich sage dir aber nicht, was genau ich für die Sicherheit deiner Daten tue.

Die Gefahr durch unbedarfte oder böswillige Dritte

Ein entscheidender Punkt der Kritik ist nicht allein der Transfer von sicherheitsrelevanten Passwörtern durch ein Win 10 System über das Internet auf die Server des Betriebssystemherstellers. Hinzu kommt, dass ich selbst dann potentiell betroffen sein kann, wenn ich Win 10 gar nicht benutze:

Es reicht, einem Mitarbeiter/Bekannten, der sich mit einem Win10-Gerät (und möglicherweise sogar Smartphone mit Win 8.1) in Reichweite meines WLANs befindet, die Nutzung meines eigenen WLAN Access Points oder WLAN-Routers zu gestatten und ihm hierzu das Passwort "im Vertrauen" mitzuteilen. Das Passwort findet auch dann seinen Weg in die Cloud und wird ggf. von meinem Bekannten mit anderen geteilt. Auch wenn das Passwort selbst für die Beteiligten nicht direkt sichtbar ist, bleibt doch Fakt: Das Passwort ist von Dritten und Vierten einsetzbar, wenn ich es einmal einem Bekannten, der Win 10 Benutzer ist, für den Zugang zum WLAN gegeben habe. Selbst, wenn der betreffende Bekannte das gar nicht will oder weiß - aber mit der Standardinstallation von Win 10 auf seinem Wi-Fi fähigen Gerät wurde die Sache auf den Weg gebracht. Siehe für die Details die oben angegebenen Artikel, u.a. :
https://grahamcluley.com/2015/08/windows-10-wifi/

Dies bedeutet, dass ich die Kette der Personen, die ggf. ungewollt in den Besitz meines Passwortes gelangen, nicht mehr kontrollieren kann.

So wird dann etwa der Angestellte, der das lokale Firmen-WLAN auch schon mal mit dem privaten Laptop nutzt, weil er ja das Passwort kennt - und weil ggf. der Admin seinen Job bzgl. der Firewall nicht ordentlich gemacht hat - schon mal gewollt oder ungewollt zum Sicherheitsrisiko. Und denjenigen, die meinen, das Problem über MAC-Filter auf ihren Access Points oder WLAN-Routern lösen zu können, sei gesagt: Es gibt kaum etwas, das leichter und schneller zu fälschen ist als eine MAC-Adresse.

Will man sich gegen Wifi-Sense schützen, so muss man lt. MS seine SSID abändern und den Zusatz "_optout" hinzufügen. Ich empfinde das einerseits als Zumutung - wegen eines Upgrades eines PCs muss die Bezeichnung von Netzen geändert werden - wo sind wir denn? Andererseits: Woher weiß ich als Privatanwender oder Admin eigentlich, dass ich mich auf diese Vorgabe von MS dauerhaft verlassen kann?

Glauben statt überprüfbare Sicherheit

Zudem ist ja überhaupt nicht klar, welche Sicherheitsmaßnahmen MS eigentlich genau für den Transfer durchs Internet oder für die Lagerung auf den MS Servern einsetzt und was diese Maßnahmen wert sind.

De facto wird also mit der Standardinstallation von Win 10 "Sicherheit" für den Anwender durch "Glauben" des Anwenders an hinreichende Maßnahmen des Betriebssystem-Herstellers wie auch die Ver- und Bewahrung meiner Daten gegenüber Dritten ersetzt. Bin ich ganz naiv, "glaube" ich dann auch daran, dass meine Daten nicht (kommerziell) verwertet werden.

Die krude Grund-Haltung zur Sicherheit ist bei Win 10 wenigstens konsistent umgesetzt - denn Win 10 überträgt bekanntermaßen ja auch massenweise private Daten zur Nutzung des Systems, IT-Konten jeder Art, Freunden, Adressen, etc. auf eigene Server. Siehe für entsprechende Internet-Links etwa:
http://linux-blog.anracom.com/2015/08/11/win-10-linux-im-namen-der-informationellen-selbstbestimmung/

Insgesamt verfestigt sich beim Lesen aktueller Publikationen der Eindruck, dass MS mit Win 10 zumindest die elementare Regel für sichere SW - nämlich "privacy by design" - nicht nur im Bereich Wifi-Sense ignoriert. Nun gut, MS ist weiß Gott nicht allein, wenn es um die Abschaffung von Privatsphäre über die Cloud geht. Aber durch die Verlagerung und die potentiell einkalkulierte Verbreitung von sicherheitsrelevanten Passwörtern ist hier schon von einer Orwell'schen Umdefinition der Begriffe "Sicherheit" und Privatsphäre" auszugehen, die ich persönlich keinesfalls teilen kann.

Verschmelzung von Betriebssystem und Cloud

MS Win 10 ist ein Betriebssystem, in dem PC und Cloud "erstmalig" eng miteinander verschmolzen werden sollten. Nun ist die "Cloud" ja keineswegs etwas Abstraktes - es handelt sich i.d.R. um Server-Konglomerate, die jemandem gehören und von jemandem verwaltet werden. In unserem Fall von MS.

Das vorliegende Ergebnis der Cloud/Betriebssystem-Verschmelzung verheißt in puncto IT-Sicherheit jedenfalls nichts Gutes für die Zukunft: Wenn MS schon bestimmte Passwörter für technische Geräte, deren Sicherheit für die Netz-Infrastruktur daheim oder in der Firma essentiell sind, auf eigene Server verschiebt, warum sollte ich dann eigentlich daran glauben, dass dies in Zukunft nicht auch mit anderen Passwörtern passiert?

Genauer betrachtet ist das ja sowieso das ultimative Cloud-Ziel: Der Anwender lädt sein "Betriebssystem" in Miniform aus dem Netz auf einen Thin-Client herunter - alle wesentlichen Programme laufen aber auf Servern des Betriebssystem-Providers. Dann liegt die Passwortverwaltung auf den Cloud-Servern zwingend nahe. MS WIN 10 ist ein Schritt in diese Richtung. Voraussetzung für derartig umfassende Cloud-Dienste sollten jedoch immer klare Verträge und ein hinreichender Kenntnisstand des Anwenders sein.

Der Unterschied zur jetzigen Situation ist der:
Bislang glaubten wir, dass Passwörter auf unseren lokalen PCs liegen - und zwar verschlüsselt und für andere nicht nutzbar. Unter Linux kann ich das prüfen - unter MS Win nur partiell. Wir gingen ferner davon aus, dass Dritten die Passwörter nicht zugänglich gemacht werden. Unter Win 10 gilt dies zumindest für wichtige technische Infrastrukturkomponenten schon nicht mehr. Hinzu kommt, dass diese Änderung in der verlockenden Form eines kostenfreien Betriebssystem-Upgrades an den unaufgeklärten Anwender herangetragen wird, der natürlich auf Standardeinstellungen während des Installationsvorgangs vertraut.

Wäre MS WIN vollständig in die Cloud verlagert, so könnte der Benutzer das Risiko des Passwortverlagerns und -sharens mit andern Internetkonten vermutlich besser einschätzen. Im Falle der Verführung zu einem kostenfreien Upgrade seines "Privaten Computers" kann man sich fragen, ob die Masse der Anwender die substanzielle Änderung einer bislang etablierten Sicherheitspolitik bzgl. der Handhabung von Passwörtern überhaupt wahrnehmen.

Der Privatanwender ist meist überfordert

Vielleicht stimmt es ja, das man zumindest im Prinzip etwas gegen den Transfer der sensiblen Wi-FI-Passwörter zu MS Servern tun kann. Viele der oben angegebenen Artikel zeigen ja auf, was man gem. der Angaben von MS (!) dafür tun muss. Es stellt sich einem dennoch die Frage: Wer ist denn im Alltag des privaten Anwenders "man"? Ist "man" denn wirklich zu effektiven Gegenmaßnahmen fähig?

"Man" ist wohl letztlich er - also der Anwender - selber ... Damit wird aber weltweit Privatsphäre und Sicherheit vom Ausbildungsstand und dem (technischen) Wissen der Anwender abhängig gemacht. Meine Erfahrung mit Standard-Windows-Benutzern in meinem Bekanntenkreis ist leider: Die meisten sind bereits mit viel einfacheren Dingen als den Schritten zur Anstellung von Wi-Fi Sense überfordert - und haken in der Regel Systemrückfragen im Rahmen einer Betriebssysteminstallation einfach ab, weil sie die Sicherheitsimplikationen nicht übersehen können oder wollen ...

Gewiss: Große Firmen werden Wifi-Access Points mit zentralen Auth-Verfahren über z.B. 802.1x, EAP und Radius-Servern verbinden und damit zunächst (hoffentlich) vor Wifi-Sense geschützt sein - aber ich kenne haufenweise kleinere Firmen, die mit konventionellen WPA/WPA2 auf WLAN-Routern (z.B. Fritzboxen von AVM) arbeiten. Die sind somit alle potentiell von den neuesten "Segnungen" des Marktführers für Desktop-Systeme betroffen ....

Deswegen ist insgesamt davon auszugehen, dass MS beim Aufbau seiner weltumfassenden Datenbank für Wi-Fi-Passwörter letztlich Erfolg haben wird, zumal alle unsere lieben Freunde, Verwandte und Bekannte ja zur (ungewollten und unbewußten) Verbreitung von Wifi/WLAN-Passwörtern beitragen können - selbst wenn man selbst gar nicht WIN 10 benutzt.

Was haben wir da also eigentlich vor uns?

Die Verbreitung von Win 10 ist aus meiner Perspektive und aus den genannten Gründen mit einer Maschinerie gleichzusetzen, die u.a. dem Aufbau einer der größten Passwort-Datenbanken der Welt auf amerikanischen Servern dient. Hinzu kommen technische Informationen über die WIFI-Ausstattung weltweit. Die Datenübertragung und Verschlüsselung findet zudem über die SW eines Unternehmens statt, von dem einige Experten schon in der Vergangenheit bezweifelt haben, dass Datensicherheit die Top-Leitlinie des technischen und kommerziellen Handelns ist.

Mal abgesehen davon, welche mächtige Position MS selbst durch eine solche Datenbank erhält .... Wir müssen - ganz unabhängig von MS's Sicherheitsvorkehrungen - in jedem Fall mit Fug und Recht annehmen, dass eine solche Datenbank für Passwörter und technische Information zu WI-FI-Netzen und die Übertragungswege zu dieser Datenbank für viele Organisationen - darunter auch verbrecherische - von größtem Interesse sein dürfte. Den finanziellen Wert einer solchen Datenbank kann man gar nicht überschätzen. Sie ist sicher sehr viel mehr wert als ein paar Steuersünder-CDs. Im schlimmsten Fall ist es deshalb wohl nur eine Frage der Zeit, bis irgendein Böser entweder die Wifi-Sense Transfer-SW in Win 10 oder Win Phone 8.1 knackt oder Zugang zu der Wifi-Sense Datenbank selbst erhält.

Was sollte man also als Firma oder kundiger Anwender eines komplexeren Heimnetzes tun?

Als sicherheitsorientierter Admin wird man dafür sorgen, dass man von der ganzen potentiellen Misere möglichst gar nicht betroffen ist. Die eigentlich richtige Konsequenz, nämlich Win 10 in der Home-Version gar nicht erst zum Einsatz zu bringen, stellt sich für viele Admins kleiner Firmen leider von Haus aus nicht.

Netzwerksegmentierung
Aber auch in einer MS dominierten Welt zeigen so elementare Sicherheitsregeln wie die strikte Separation von Netzen/Netzwerksegmenten mit öffentlich zugänglichem Access Point (z.B. für externe Mitarbeiter) einerseits von privaten oder firmeninternen Netzen/Netzwerksegmenten andererseits Wirkung. Diese fundamentale Regel gewinnt mit Win 10 an Bedeutung - und ist technisch angemessen umzusetzen.

Ob einem Admin das aber rechtlich wirklich hilft, wenn etwa ein böser Facebook-Freund eines externen Mitarbeiters oder Freundes in Zukunft den öffentlichen Wifi-Zugang zum Internet einer Firma für illegale Zwecke nutzt, sei mal dahingestellt ....

Passwortwechsel
Eine weitere elementare Regel ist deshalb schlicht das häufige, nicht vorhersehbare Wechseln von Passwörtern zu den zu administrierenden Wireless-Netzen.

MAC-Filter
Zugangsfilter auf MAC-Ebene sind nur begrenzt wirksam und schrecken echte Hacker nicht ab. Aber warum nicht?

Zentralisierte Authentifizierungsverfahren über 802.X1
Ferner sieht es zur Zeit wohl (noch) so aus, dass MS die Finger von Passwörtern zu WIFI/WLAN-Access Punkten oder -Routern lässt, bei denen die Authentifizierung über zentrale Systeme läuft. Für Firmen, die mit Gedanken spielen, Win 10 Clients einzusetzen oder Win 10 Clients Zugang zum WLAN zu geben, kann die technische Devise im Moment wohl nur so lauten:

Weg von direkter WPA2/WPA-Authentifizierung gegenüber dem WIFI/WLAN-Access Point/Router und statt dessen hin zum Einsatz zentraler Authentifizierungsverfahren über IEEE 802.1x, EAP, Radius Server. Etliche WLAN AccessPoints/Router unterstützen schon seit längerem "WPA2 Enterprise", das solche Lösungen ermöglicht. Leider aber z.B. nicht die Produkte des Marktführers in Deutschland für die breite Allgemeinheit - nämlich AVMs Fritzboxen - und dies trotz mehrfacher Aufforderung von besorgten Anwendern. Aber es gibt ja Alternativen für Access-Points auch im preiswerten Consumer-Segment und Sicherheit sollte auch in kleinen Firmen eine überschaubare Investition wert sein ....

Flankiert müssen Vorkehrungen zur zentralen Authentifizierung in WLANs allerdings auch

  • durch umfassende Aufklärung der Win 10 Nutzer,
  • das systematische Abstellen von Wi-Fi-Sense auf Geräten, die wir kontrollieren können
  • sowie durch rigide Policies zur Wi-Fi/WLAN-Nutzung im Unternehmen.

Kein BYOD für WIN 10 Geräte
Ich war noch nie ein Freund von BYOD - aber "Bring your own (!) Win 10 Device or Win 8.1 Mobile Device" ist in einer Firma mit Sicherheitsanspruch sicher keine gute Idee.

Überwachung ausgehenden Datenverkehrs
Und wenn man sich auf Dauer nicht auf die Versicherung von MS verlassen will,dass 802.1X-Netze unangetastet bleiben, wird man wohl nicht darum kommen, ausgehenden Netzwerkverkehr von Win 10-Systemen daraufhin zu kontrollieren. Ich denke, es wird nur einen Frage der Zeit sein, bis entsprechende automatisch verwertbare Muster für den Datentransfer bekannt werden.

Konsequenz für Sicherheitsaudits

Das Feature "Wifi-Sense" von Win 10/Win Phone 8.1 sollte im Risiko-Management von Firmen und in zugehörigen Sicherheits-Audits einen festen Platz bekommen. In Kombination mit der Upgrade-Politik ist das Thema sogar ein idealer Prüfstein dafür, ob das Risiko-Management im Rahmen des Change Managements für das technischen Umfeld hinreichend funktioniert.

Ein paar Links zu 802.1X, EAP, Radius: