Eternal Blue – und die vermeintliche Sicherheit nach MS Windows Updates

Wannacry und EternalBlue sind gerade in aller Munde. Zu Recht; der bereits eingetretene (wirtschaftliche) Schaden ist immens. Auf der Linux-Seite braucht man sich hier übrigens nicht auf ein hohes Ross zu setzen: Heart Bleed, Shell-Shock, massive Probleme mit SSH und TLS und KEX-Algorithmen seien nur als Beispiele dafür genannt, welche Schwachstellen auch Linux-Systeme lange Zeit unerkannt aufwiesen. Niemand weiß, wie lange die vor ihrer Behebung von wem ausgenutzt wurden ... Ich finde, in einem solchen Fall ist klammheimliche Schadenfreude völlig unangebracht. Zumal auch viele Admins in einer heterogenen Welt leben müssen - und mit Samba Brücken zu Windows-Servern oder PCs hergestellt haben. [Es stellt sich nebenbei die Frage, ob eigentlich Samba schwachstellenfrei ist ....]

Was ist eigentlich mit Angriffen ohne Ransomware?

Diskussionswürdig erscheint mir ferner ein Punkt, der mir im Moment in der hektischen Berichterstattung etwas unterzugehen scheint; viele der in deutschen Tageszeitungen erschienen Artikel zu Wannacry hoben vor allem auf Angriffsvektoren ab, die bösartige E-Mail-Anhänge voraussetzen. Die SMB-Schwachpunkte betroffener Windows-Systeme wurden von vielen "fachkundigen" Journalisten lediglich als Hebel für die schnelle Verbreitung der Malware begriffen. Die Aufregung in den Zeitungsartikeln konzentrierte sich deshalb vor allem auf das Thema "Erpressung" und natürlich den Funktionsausfall der betroffenen Systeme.

Dabei hatten Experten und u.a. auch die Fa. Cisco frühzeitig und völlig zu Recht auf folgenden Punkt aufmerksam gemacht:

Eternal Blue ist ein Exploit, den Angreifer gezielt und direkt gegen Systeme, die die SMB-Schwächen aufweisen und verwundbar sind, in einem LAN oder auch aus dem Internet heraus einsetzen können. Voraussetzung ist nur, dass auf den Zielsystemen bestimmte SMB-Ports zugänglich sind. Und natürlich kann im Rahmen des Angriffs auch eine ganz andere und weniger offensichtliche Payload (Schadware) als eine Ransomware zum Einsatz kommen.

Eigene Experimente mit Kali

Ich bewahre nicht ganz zufällig ältere Sicherungsimages von Win7/8/10-Images für VMware auf. Eine solche Kopie konnte ich gestern benutzen, um ein paar Experimente mit EternalBlue und dem Angriffs-Framework "Fuzzbunch" von einem Kali-System aus durchzuführen. Natürlich abgeschirmt von der Umwelt. Ergebnis war die praktische Bestätigung dreier plausibler Vermutungen:

  • Der Einsatz der im April publizierten Angriffswerkzeuge Fuzzbunch (Python-basiert; läuft auf Linux-Systemen unter Wine) und Eternal Blue ist bei ein wenig Erfahrung relativ einfach. Ein aktueller Umlauf von Modifikationen und neuen Angriffsvarianten ist deshalb als wahrscheinlich anzusehen.
  • Ein Angriff gegenüber Windows-Systemen, die die für Eternal Blue notwendigen Schachstellen im SMB-Protokoll aufweisen und von außen über SMB-Ports zugänglich sind, kann direkt und ohne Umwege (über Fake-Webseiten oder bösartige E-Mail-Anhänge) über das Internet geführt werden. Scan-Verfahren zur Identifizierung angreifbarer Systeme lassen sich von bösen Zeitgenossen jederzeit anfertigen. (Nachtrag 27.05.: Für Netzwerk-Admins steht nun z.B. ein NSE-Script für NMAP bereit).
  • Welche Payload (Schadware, Backdoor etc.) ein Angreifer nach Kompromittierung in das Windows-System einschleust, ist relativ beliebig. In Frage kommen u.a. Meterpreter Reverse Shells.

Nachtrag 27.05.2017:
Da ich inzwischen per Mail zwei Anfragen bekommen habe, ob ich die durchgeführten Experimente nicht im Detail beschreiben möchte, Folgendes: Nein, ich möchte nicht ins Detail gehen. Grund: Die deutsche Gesetzgebung (Hacker-Paragraph). Außerdem sind im Internet bereits genügend präzise Beiträge und Filme zum konkreten Einsatz von EternalBlue erschienen.

Reicht ein Update?

Das Problem hat aufgrund der beträchtlichen Zeitspanne, die seit der Veröffentlichung der Eternal-Tools vergangenen ist, eine weitaus größere Dimension, als so mancher Windows-Nutzer und Konsument von einschlägigen Zeitungsartikeln zur aktuellen Ransomeware-Welle meinen möchte. Bereits im April wurde der Einsatz des Exploits im Detail diskutiert; Hacker hatten also frühzeitig die Möglichkeit, sich tiefer einzuarbeiten.

Dass es viele direkt aus dem Internet angreifbare Windows-Systeme gab und gibt, muss nach den Ereignissen der letzten Tage nicht mehr großartig bewiesen werden. Ich selbst kenne einige kleinere Firmen, die Windows einsetzen und die über das Internet Filesharing per SMB nutzen. Worüber nun alle Verantwortlichen, die bislang anfällige Windows-Systeme betreuen, intensiv nachdenken sollten, ist also das Folgende:

EternalBlue ermöglicht einem Angreifer vor allem den Zugang zu einem kompromittierbaren Windows-System. Der Angriff muss aber keineswegs mit der Implementierung von Ransomware verbunden sein - auch wenn sich die Presse hierauf kapriziert.

Gerade geschickte (und wirklich böse) Angreifer, die perfidere Ziele als eine begrenzte Gelderpressung im Sinne haben, werden nach einem erfolgreichen EternalBlue-Angriff auf den gehackten Systemen problematischer Tools als eine offen nach außen sichtbare Ransomware implantieren. Gerade die wirklich ernst zu nehmenden Angreifer werden sich auf dem kompromittierten System still verhalten, Spuren verwischen, im Hintergrund ihre Privilegien erhöhen, Daten abziehen und sich - wiederum mit Hilfe von Eternal Blue auf andere Systeme im (Firmen-) LAN ausbreiten. Alles ohne, dass man das nach außen hin im Alltagsbetrieb merken müsste. Das war ja gerade das, was die NSA vermutlich mit Eternal Blue und dem Exploit Kit "Fuzzbunch" bezweckte.

Es genügt deshalb keinesfalls, jetzt auf den Systemen, die die SMB-Schwachstellen aufweisen, mal schnell die bislang versäumten Updates einzuspielen und wegen nicht zu Tage getretener Ransomware zu meinen, dass die Welt dann wieder in bester Ordnung sei. Ist sie mitnichten .... denn die wirklich gefährlichen Angreifer haben sich ggf. bereits unerkannt eingenistet.

Diejenigen Windows-Nutzer und Admins, bei denen die Ransomware den Angriff offensichtlich machte, sind in gewisser Weise besser dran als diejenigen, die auch Systeme mit den SMB-Schwachstellen hatten, exponiert waren und mittels Eternal Blue von intelligenten Hackern oder Organisationen angegriffen wurden - die aber davon bislang gar nichts merkten, merken oder merken werden. Man könnte ja auf Virenscanner hoffen - aber das Thema einer Maskierung von Schad-SW gegenüber Scannern ist ja nun wirklich kein Neues; das ist und bleibt ein ewiges Katz und Maus-Spiel ....

Im Bereich der Wirtschaft steht deshalb mal wieder die Bewertung der Auswirkungen unerkannter Wirtschaftsspionage im Vergleich zu den Kosten einer umfassenden Bereinigung potentiell betroffener Systeme an. Als verantwortlicher Admin würde ich jedenfalls kritische Windows-Systeme, die die SMB-Schwachstellen aufwiesen, nach den Vorgängen der letzten Tage neu aufsetzen oder aber zumindest ihren ausgehenden Datenverkehrs feinmaschig überwachen - auch und gerade dann, wenn keine Ransomware erscheint.

Denjenigen Administratoren, die die Gefahr besser ausloten wollen, lege ich zudem einige kürzlich erschienene Veröffentlichungen im Internet zum konkreten Einsatz von EternalBlue, Fuzzbunch etc. ans Herz. Damit sind bereits ein paar Schlagworte für die Suche genannt; weitere Stichworte wären Kali, Wine, msfconsole und Empire.

Nachtrag 26.05.2017:
Meine lieben Linux-Kollegen, die sich bislang ggf. sicher wähnten und Samba im Einsatz haben, seien auf folgende Artikel zu SambaCry hingewiesen:
http://thehackernews.com/2017/05/samba-rce-exploit.html
https://www.heise.de/security/meldung/Jetzt-patchen-Gefaehrliche-Luecke-in-Samba-3725672.html
https://www.heise.de/security/meldung/SambaCry-Gefaehrliche-Sicherheitsluecke-in-Samba-finden-und-patchen-3726053.html

Interessant zu lesen sind auch die zugehörigen Diskussionen im zugehörigen Heise-Forum - u.a. wegen eines in diesem Falle überflüssigen Lagerkampfes zwischen Linux- und Windows-Anhängern.

Schön, dass Microsoft für Forschungszwecke Linux nutzt – weiter so …

Heute früh hatte ich das Vergnügen, einen Artikel zu aktuellen Durchbrüchen von Microsoft in der Spracherkennung auf Basis trainierter neuronaler LSTM-Netzwerke zu lesen:
W. Xiong, J. Droppo, X. Huang, F. Seide, M. Seltzer, A. Stolcke, D. Yu and G. Zweig: "Achieving Human Parity In Conversational Speech Recognition", Microsoft Research.
Technical Report MSR-TR-2016-71, 2016
Siehe: https://arxiv.org/pdf/1610.05256v1.pdf

Dabei fiel mir neben den interessanten wissenschaftlichen und technischen Erläuterungen eine kleine Passage auf, die meine übliche Morgenmuffel-Stimmung beträchtlich aufhellte. Zitat:

"All neural networks in the final system were trained with the Microsoft Cognitive Toolkit, or CNTK [63, 64], on a Linux-based multi-GPU server farm. CNTK allows for flexible model definition, while at the same time scaling very efficiently across multiple GPUs and multiple servers. The resulting fast experimental turnaround using the full 2000h corpus was critical for our work."

Sowas liest man doch gerne ....

Windows 7 Updates – ein erzwungener Blick ins alltägliche Leiden vieler Zeitgenossen …

Es gibt Tage, in die der Ärger schon einprogrammiert ist. Zu solchen Tagen gehören oftmals solche, an denen man sich gezwungenermaßen mit Windows auseinandersetzen muss. Ich war vorgewarnt: Eine gute Bekannte schafft es seit ca. 6 Monaten nicht mehr, ihr WIN 7-System auf den neuesten Stand zu bringen. Nach ihrer Aussage werkelt der PC Ewigkeiten vor sich hin - von 2 CPU-Kernen ihres Laptops sei einer immer ausgelastet. Aus dem Bereich des Windows-Update-Tools kämen zudem laufend Fehlermeldungen ... Sie wisse nicht mehr, was sie tun solle ... (Den Rat, auf Linux zu setzen, mag sie leider aber immer noch nicht annehmen ...). Tja, mir fällt da nur der Satz ein: Drum prüfe, wer sich und seinen PC ewig bindet.

Aber kein Grund zur Schadenfreude: Gestern traf es mich selber. Ich war gezwungen im Zuge von Arbeiten für einen Kunden mal wieder meine 2 Windows 7-Systeme anzuwerfen. Beide laufen unter VMware - eines auf einem Linux-PC, das andere auf einem Linux-Laptop. Das letzte Mal hatte ich das erste Windows-System Anfang März 2016 gestartet - zum Updaten - aber auch da waren schon 2 Monate ohne Benutzung ins Land gegangen. Also habe ich seit Januar dieses Jahres ohne jeglichen Einsatz von Windows gelebt; eigentlich ein Grund zur Freude! Aber Windows wäre nicht Windows, wenn es keine Probleme gäbe - das dicke Ende kam dann prompt.

Im März hatte ich das Windows-System während einer Fernsehsendung sich selbst überlassen und den Update-Prozess nicht so genau verfolgt. Möglicherweise existierte das Problem, das ich jetzt feststellen musste, damals schon. Win 7 benötigte nach dem gestrigen Neustart einige Zeit, um festzustellen, dass es ca. 35 Updates einspielen muss. OK, nicht so verwunderlich. Also: Download und Installation gestartet. Dann vergingen Stunden (!) - ohne dass irgendetwas erkennbar Sinnvolles passierte.

Ein Blick in den Task Manager ergab: Ein "svhost.exe"-Prozess rödelte und rödelte auf dem System vor sich hin. Und wie bei meiner Bekannten ziemlich CPU-intensiv: Von 2 CPU-Kernen, die ich VMware zur Verfügung gestellt hatte, war einer immer zu 100% ausgelastet, manchmal aber auch beide. Die Nutzung des RAMs (4GByte) variierte oberhalb von 80 % bis hin zu 95%. Ohne jede Fortschrittsanzeige. Ein paralleler Blick auf unsere Firewall und unseren Router zeigte währenddessen so gut wie keine Netzaktivität.

Ich habe dann testweise mein anderes (ebenfalls virtualisiertes) Windows-7-System auf dem Laptop gestartet. Das gleiche Chaos - über Stunden. Auf dem PC-System habe ich dann nach 3 Stunden den Update-Prozess abgebrochen; es wurden dann drei kleinere Updates von 5 erfolgreich installiert; für 2 weitere kamen Fehlermeldungen, der Rest der 35 Updates wurde als abgebrochen angezeigt. Ein erneuter Versuch, Updates zu such und zu laden, mündete dann erneut in einen nicht enden wollenden Suchvorgang, erst mit hoher CPU-Auslastung durch einen msinstaller-Prozess, dann wieder svchost.exe - ohne jeden erkennbaren Fortschritt. Ich habe dann entnervt abgeschaltet.

Der einzige Trost: Ich war und bin nicht allein. Offenbar gab und gibt es seit Juli 2015 (!) regelmäßig Probleme mit Windows 7 und automatischen Updates. Ich gebe als Beleg nur 2 Links zu relativ aktuellen Blogs an, die gleichzeitig Hinweise zur Problembehebung enthalten; die Trefferliste von Betroffenen, die sich im Internet zu Schlagwörtern wie "windows 7 updates slow high cpu" äußern, ist aber gigantisch :

https://alexanderschimpf.de/windows-7-update-es-wird-nach-updates-gesucht
http://www.borncity.com/blog/2016/07/17/windows-7-und-die-langsame-update-suche-july-2016/comment-page-1/

Dass es auf manchen Systemen noch zu ganz anderen gravierenden Problemen mit Windows 7 Updates kommen kann, illustrieren folgende Artikel
http://www.computerworld.com/article/3070446/windows-pcs/windows-update-on-windows-7-is-still-a-problem.html
https://blog.botfrei.de/2016/05/microsoft-update-fuer-windows-7-sorgt-fuer-probleme/

Im übrigen scheint auch Win 10 von Update Problemen betroffen zu sein:
https://www.quora.com/Microsoft-Windows-10-Why-is-Windows-10-update-extremely-slow
https://support.microsoft.com/de-de/kb/3102810
http://www.itpro.co.uk/operating-systems/25802/15-windows-10-problems-and-how-to-fix-them-5

Was bin ich froh, dass ich mich mit dieser Art von Problemen normalerweise nicht auseinandersetzen muss! Mir tun die (z.T. regelmäßig) Betroffenen ehrlich leid.

Lösung für Win 7

Ich bin dann heute dem Ratschlag der Artikel hinter den beiden ersten Links gefolgt:

  • Schritt 1: Das Windows Update Tool über die Systemsteuerung (temporär) so einstellen, dass es nicht nach neuen Updates sucht.
  • Schritt 2: manueller Download folgenden Paketes, das viele Updates bündelt und einer Art Service Pack für Win 7 [64Bit] entspricht:
    windows6.1-kb3172605-x64_26f4cc7831a0d76393445b7b0a1a3ed5cd5b4047.msu
    Link:
    http://download.windowsupdate.com/d/msdownload/update/software/updt/2016/07/windows6.1-kb3172605-x64_26f4cc7831a0d76393445b7b0a1a3ed5cd5b4047.msu
    (siehe auch: https://alexanderschimpf.de/windows-7-update-pack)
     
    Nachtrag 29.09.2019: Nutzer eines 32Bit-Windows-7-Systems müssen sich folgendes Paket herunterladen und installieren:
    http://download.windowsupdate.com/d/msdownload/update/software/updt/2016/07/windows6.1-kb3172605-x86_4a9464688e111c4c1f63f94b543495f15ce6558d.msu
  • Schritt 3: Doppelklick auf die heruntergeladene Datei. Es öffnet sich ein rel. kleines, abgeundetes Fenster des Win 7 Update-Prozesses. Und der beginnt leider erneut mit der stundenlangen Suche nach Updates ... grrr .. Die automatischen Update-Prozesse, die das Chaos verursachen laufen also noch.
  • Schritt 4: Taskmanager starten (Ctrl-Alt-Delete) => alle Prozesse anzeigen lassen und nach CPU-Verbrauch sortieren => den führenden "svchost.exe"-Prozess, der praktisch einen CPU-Kern (oder die ganze CPU) auslastet, manuell beenden.
  • Schritt 5: Erneuter Doppelklick auf die heruntergeladenenn msu-Datei. Leider kommt dann typischerweise noch eine Warnung des Typs: "Only one instance of wusa.exe is allowed to run" => Task-Manager => Prozessanzeige => alphabetisch sortieren => wusa.exe-Prozess beenden.
  • Schritt 6: Erneuter Klick auf die heruntergeladene msu-Datei => es öffnet sich nun ein (rechteckiges) Fenster, das nach wenigen Augenblicken eine Bestätigung zur Installation anfordert => Installation durchführen lassen.

Dann passiert tatsächlich was. Nach relativ kurzer Zeit (bei mir ca. 2 Minuten) ist die Installation fertig. Nach dem bei Windows üblichen kompletten Systemneustart den Abschluss der Installation abwarten. Danach einloggen und die Einstellungen zum Windows-Update wieder ändern; bei mir "Nach Updates suchen, aber Zeitpunkt zum Herunterladen und Installieren manuell festlegen". Dann erneut nach Updates suchen lassen.

Das Positive war, dass die Suche nun nur ca. 1 bis 2 Minuten dauerte. Merkwürdig allerdings, dass nun auf einmal 45 Updates gefunden wurden, die noch zu installieren waren (ohne die optionalen). Also deutlich mehr als ursprünglich erkannt. Über die Gründe kann man nur spekulieren: Vielleicht setzten die neuen Updates die vorherige Installation anderer Updates voraus - und Windows ist nicht in der Lage, das vernünftig zu organisieren. Oder schlicht Fehler? Wer weiß.
Das Ganze bestätigt nur, wie seltsam und ineffizient das Windows-Update-System organisiert ist - und wie der User eigentlich hilflos daneben steht. Jedenfalls liefen sowohl der Download und auch die Installation danach wieder zügig durch. Auch für optionale Updates und auch - mit gleicher Vorgehensweise - auf dem zweiten Win 7 System.

Habe aufgrund dieses Erfolges nun meine Bekannte unterrichtet: Auch da führte das Procedere zum Erfolg. Sie kann nun - nach einem halben Jahr Leiden und Arbeitsbehinderung durch hohe CPU-Auslastung eines nie enden wollenden Update-Prozesses - endlich wieder mit ihrem Windows arbeiten. Die Arme ...

Fazit

Windows ist immer mal wieder ein Leiden. Gott sei Dank gibt es so nette Leute wie die Herren Dr. Schimpf und Hrn. Born, die die oben genannten Artikel geschrieben haben - Ihnen gebührt Dank für ihre Versuche und Tests. Wie einer von Ihnen sagte: Zumindest bis zum nächsten patch day ...

Und zum Abschluss noch folgende Feststellung: Würde sich jemand mal die Mühe machen, die durch die Windows-Update-Probleme entstandene Arbeitsbehinderung für betroffene Normal-User in Deutschland zu ermitteln und hochzurechnen, so würde man wahrscheinlich feststellen, dass die Nutzung von Win 7 im letzten Jahr massive volkswirtschaftliche Schäden verursacht hat. Neben verlorener Arbeitszeit ist auch der verursachte überflüssige Stromverbrauch zu nennen.

Ein Grund mehr, sich über sein Linux zu freuen - und den relativen Komfort der dortigen Paket-Manager zu genießen.