23.05.2017 18:56
Ein paar Gedanken zu WannaCry
Wir haben heute unsere offizielle Warnung bezüglich der WannCry Ransomware veröffentlicht. Ich will in diesem Blogbeitrag ein bisschen Kontext liefern, und etwas strategischer denken.Erstens: wie viele hat es wirklich erwischt?Dazu gibt es mehre Blickwinkel und Datenquellen. Einerseits sind das diejenigen Organisationen, bei denen die Ransomware-Komponente von WannaCry voll zugeschlagen hat. Diese haben zum Teil bei der Polizei Anzeige erstattet, daher sind dort Daten dazu vorhanden. Die Dunkelziffer wird aber - wie immer bei diesen Sachen - hoch sein. Viele, insbesondere wenn der Schaden klein war, sparen sich die Zeit für die Bürokratie und stecken ihre Energie lieber in die Wiederherstellung des Betriebs. So sehr wir das verstehen, so sehr ist das aber aus gesamtstaatlicher Sicht nicht gut: wir bekommen kein volles Bild der Probleme, daher kann der Staat seine Ressourcen nicht an die richtigen Stellen leiten. Bei uns (CERT.at) melden sich typischerweise nur ganz wenige dieser Gruppe.Die CERTs stützen sich auf eine andere Datenquelle: der vielbeschriebene "Kill-switch" (in Wirklichkeit der Test der Malware, ob sie in einer Analyseumgebung läuft, in der alle Domains valide sind) besteht aus einem erfolgreichen http-Request. Diese werden vom Researcher, der das gefunden hat, mitprotokolliert und im globalen Datenverbund der CERTs weitergegeben. Wir wissen daher primär, wo in Österreich die Malware zwar vorhanden ist, aber nicht aktiv geworden ist oder gestoppt wurde. Die Zahl ist so gemessenen IP-Adressen ist überschaubar: weniger als 100.Zweitens: warum ist das global so groß geworden?Ransomware ist ja nichts Neues. Bis jetzt sahen wir aber entweder die Massenverbreitung über die üblichen Kanäle Phishing und Exploit-Packs, oder aber die manuelle Kompromittierung eines High-Profile Zieles, ein händisches "lateral movement" und dann die Platzierung der Malware. Letzteres war bei den SAMSAM-Angriffen auf Spitäler die beobachtete Vorgangsweise. Was wir jetzt gesehen haben, ist schlichtweg die Automatisierung der Weiterverbreitung innerhalb einer Organisation. Damit skaliert das Ganze plötzlich um Größenordnungen besser.Wir sehen den gleichen Effekt immer wieder im Webbereich. Wenn mal wieder Wordpress, Joomla & co eine gröbere Lücke haben, dann gibt es vereinzelnd Defacements und anderweitig manipulierte Webseiten. Dann und wann programmiert aber jemand den ganzen Prozess aus, und dann raschelt es bei uns im Ticketsystem weil dann innerhalb von kurzer Zeit hunderte Webseiten betroffen sind.Wann jemand das Ausnutzen einer Schwachstelle voll automatisiert, oder gar gleich einen Wurm dafür schreibt, lässt sich nicht vorhersagen. So etwa hatten wir das für den Schannel Bug erwartet gehabt (und sogar einen Honeypot dafür gebaut), da kam aber gar nichts. Dass jetzt EternalBlue / SMB / MS17-010 dafür benutzt wurde, mag mehr oder weniger Zufall sein. Für Ransomware eignet sicher das jedenfalls sehr gut, da damit die Malware direkt auf den Fileservern agieren kann. Dass die Shadow Brokers gleich den Exploit geliefert haben, und man den nicht aus dem Patch reversen musste (wie damals bei Conficker), erleichterte sicher die Arbeit.Drittens: warum geht das überhaupt?Da spielen meiner Meinung nach zwei Faktoren zusammen. Erstens, es ist immer noch viel zu einfach, jemand anderem böse Code unterzujubeln. Die Angriffsfläche moderner (oder noch schlimmer, nicht ganz moderner) PCs ist extrem groß. Dabei geht es nicht nur um Schwachstellen in Standardanwendungen, sondern oft genug um den einen falschen Mausklick, mit dem der Benutzer die Sicherheitsmaßnahmen des Systems aushebelt. Das können Macros in Office-Dokumenten sein oder Scripte in esoterischen Fileformaten, die per Mail oder Web dem Opfer mit einer netten Story untergejubelt werden. Social Engineering funktioniert immer noch bestens. Zweitens, kaum eine Organisation schafft es, seine interne IT wirklich am Stand der Technik zu betreiben. Mal sind es Legacy-Systeme, die auf nicht mehr unterstützen Betriebssystemen fahren, mal sind es Verzögerungen über Monate in der Einspielung von Patches, mal sind es Inkompatibilitäten, die eine Aktualisierung verhindern (Hallo Java!), mal ist es schlicht ein Ressourcenmangel in der IT-Abteilung.Oder anders gesagt: müssten wir mit unsere IT jedes Jahr das Pickerl (oder zum TÜV) machen lassen, dann würde so manches massiv bemängelt werden. Zertifizierungen nach diversen Sicherheitsnormen sollten das theoretisch besser machen, aber das ist in manchen Bereichen nur ein "wir haben einen gut dokumentierten Prozess, nach dem wir unser Schlamassel verwalten".Das alles ist in den meisten Fällen nicht böswillig, sondern bloß eine Folge der täglichen Triage der IT-Abteilungen. Nur so ist es zu erklären, dass Conficker immer noch in diversen Firmennetzen herumspukt. "Ja, wir sollten das aufräumen, aber welches andere Projekt kann ich deswegen zurückstellen?" Damit habe ich fast überall irgendwo bekannte Schwachstellen, die aber hoffentlich nicht von extern aus angreifbar sind. Es kommt leider viel zu oft vor, dass man sich zu sehr auf den Perimeterschutz verlässt. Ich werfe hier jedenfalls nicht den sprichwörtlichen ersten Stein.Nimmt man das zusammen, wird das Problem klar: Eine Erst-Infektion irgendwo ist leider fast Tagesgeschäft in größeren Organisationen, und wenn dieser Code zum systematischen Suchen und Ausnutzen von Schwachstellen benutzt wird, da kann das einen bösen Effekt haben.Viertens: wohin geht die Reise?Ein guter Teil der Probleme stammt aus einem verbockten IT Lifecycle Management. Wir planen sehr oft nur die Inbetriebnahme, und nicht immer auch die laufende Wartung und das Ende der Lebensdauer von Systemen. Das fängt an bei Commodity-Betriebsystemen als Komponenten in integrierten Systemen (Angeblich wird manchmal immer noch XP ausgeliefert) an, geht über Handys (wie lange bekommt das typische Android-Gerät Updates?), ganz normalen Servern (wie oft Windows Server 2003 noch eingesetzt wird, ist erschreckend) bis hin zu Internet-of-Things (IoT) Devices.Viel von dem, was wir jetzt (ver-)bauen, hat keine garantierte Software-Wartung bis zum Ende der Lebensdauer der Hardware. Mir gefällt die Metapher des IT oder technical debt sehr gut. Analog zum realen Leben: Ja, ich kann die Wartung meines Autos, oder die Reparaturarbeiten an meinem Haus, oder an Straßen- und Schieneninfrastruktur hinauszögern. Das wird nicht gleich dramatische Konsequenzen haben.Aber irgendwann holt mich das alles ein. Genau so einen Moment haben wir gerade eben mit WannaCry erreicht. Jetzt kam ein Exekutor, der die Schulden eintreibt.Fünftens: wieder einmal geht die Strategie der USA nach hinten losDie NSA saß lang auf dem 0-day und sah es als wichtiger an, ihre offensiven Fähigkeiten zu erhalten, als die eigene Industrie gegen diese Schwachstelle zu schützen. Dafür zahlen sie jetzt. Ich bin gespannt, ob die Vorgehensweise dort überdacht wird. Microsoft hat sich schon deutlich kritisch geäußert.Wir hatten genau das gleiche auch bei TLS, siehe meinen Blog-post zu DROWN.Ein weiterer Punkt passt hier noch dazu (und auch die Idee ist nicht von mir): will ich als kleiner Staat meine bescheidenen Mittel effizient gegen die Bedrohung durch einen Cyberwar einsetzen, dann sind all diese 0-days, die von meinen potentiellen Gegner gehortet werden, die Ressourcen, die ich angreifen will. Und im Gegensatz zu klassischem Krieg kann ich die auch schon zu Friedenszeiten angreifen. Wie? Indem ich selber die 0-day Suche mache oder fördere und die Ergebnisse nicht selber horte, sondern an die Hersteller melde und so den Wert dieser 0-days radikal verringere.Im Vergleich zu klassischer militärischer Hardware kostet das einen Pappenstiel. Investitionen in oder Nachbauten von der Zero Day Initiative oder Project Zero sind genau das, was kleiner Staaten machen sollten. Das darf natürlich nicht die einzige Maßnahme zur Erhöhung der Cyber Security sein.Vergesst das Arms-Race mit der NSA, das gewinnt ihr nicht. Aber ihr könnt global an der Cyber-Abrüstung arbeiten, indem ihr Forschung + Responsible Disclosure macht.[Addendum, 23.5.: Beim Browser-Tabs wegräumen kam mir wieder folgender Artikel unter. Der passt hier gut an das Ende.]
Autor: Otmar Lendl