Software und Lebensmittel
Software wird manchmal mit dem Begriff End-of-Life (EoL) gekennzeichnet. Übersetzt bedeutet das so viel wie „Die Software hat ihr Lebensende erreicht“. Was passiert denn nun ab diesem Zeitpunkt?
Am besten kennen wir das Überschreiten eines Ablaufdatums vermutlich von Lebensmitteln. Dort gibt es das Mindesthaltbarkeitsdatum und wie es der Name schon vermuten lässt, müssen Produkte mindestens bis diesem angegebenen Datum haltbar sein, können jedoch auch noch länger genießbar sein. Tatsächlich wird oft geraten, ein Lebensmittel mit überschrittenem Mindesthaltbarkeitsdatum genauer zu prüfen, aber nicht gleich wegzuwerfen.
Was hat Software nun mit Lebensmitteln zu tun? Tatsächlich nicht viel – und genau da liegt auch das Problem. Bei Software im EoL-Status denkt sich vielleicht manch einer: „Das Programm läuft doch noch hervorragend, das verwende ich einfach weiter. Ich habe doch auch schon oft abgelaufene Lebensmittel gegessen, die waren alle noch gut. Genauso wird meine abgelaufene Software bestimmt noch gut und sicher sein.“
Und doch gibt es einige Unterschiede, wenn es um veraltete Software geht.
Probleme von Software im End-of-Life Status
Anders als bei Lebensmitteln kann ein Endbenutzer nicht so einfach überprüfen, ob eine Software „noch gut ist“. Bei Nahrungsmitteln lässt sich die Verpackung relativ einfach auf Unversehrtheit überprüfen und wir besitzen Geruchs- und Geschmacksnerven, um verdorbenes Essen gut erkennen zu können. Software dagegen ist häufig sehr komplex, sodass Anwender die Sicherheit nicht ohne Weiteres beurteilen können.
Hersteller (auch Open-Source-Software ohne explizite Hersteller zählt dazu) bieten manchmal sogenannte Bug-Bounty-Programme an: unabhängige Personen können gefundene Schwachstellen melden und erhalten dafür eine finanzielle Belohnung. Es kann auch sein, dass Softwareanbieter eine Untersuchung der Software bei einem Sicherheitsdienstleister beauftragen oder selbst aktiv nach Schwachstellen suchen.
Ab dem EoL-Status allerdings betreiben Hersteller üblicherweise keine eigene Forschung nach Schwachstellen mehr. Werden Schwachstellen in neueren Versionen der Software bekannt, wird ebenfalls nicht immer untersucht, ob diese auch in der alten EoL-Version vorliegen. Für sogenannte Bug-Bounty-Hunter sind EoL-Versionen auch unattraktiv, da sie hierfür keine finanzielle Belohnung mehr erwarten können und es sicherlich auch mehr Bekanntheit und Anerkennung bringt, eine Schwachstelle in einer aktuellen Softwareversion zu finden. Jedoch suchen „böse Hacker“ weiterhin nach Schwachstellen und haben hier sogar ein lohnenswertes Ziel, weil keine schnellen Updates erwartet werden. Dadurch entsteht für EoL-Software ein Risiko, das nicht zu managen ist.
EoL oder nicht EoL?
Außer ein Apfel direkt vom Baum sind so gut wie alle Lebensmittel mit dem Mindesthaltbarkeitsdatum ausgezeichnet. Anders sieht es bei EoL-Software aus: Hier fehlt leider Einheitlichkeit in der Ankündigung und Benennung. Manchmal wird Software explizit mit dem End-of-Life-Status versehen wie beispielsweise die Version 7 von PHP oder die Version 4 der Bootstrap-Bibliothek, manchmal fehlt aber dieser konkrete Begriff.
Bei Protokollen wie bei SMB1 wird gewöhnlich der Begriff „deprecated“, also „veraltet“ verwendet.
Nochmal anders verhält es sich oftmals bei Javascript-Bibliotheken, so zum Beispiel bei Highcharts: hier werden regelmäßig neue Versionen veröffentlicht, das Lebensende alter Versionen wird aber nicht klar markiert. Sollte man jedoch die Bibliothek Highcharts in der Version 6 verwenden, bei der die letzte Version 6.2.0 in 2018 veröffentlicht wurde und für die eine Schwachstelle mit hohem Schweregrad bekannt ist, dann ist es dringend an der Zeit, sich über ein Update Gedanken zu machen.
Auch wenn also eine Software nicht offiziell als EoL markiert wird, ist eine seit mehreren Jahren überholte Version ähnlich wie EoL zu betrachten.
Angriffe auf EoL-Software
Lebensende hin oder her – gibt es denn überhaupt Beispiele, bei denen die Nachlässigkeit, Updates einzuspielen, überhaupt zum Problem wurden?
Ein folgenreicher Hackerangriff soll hier etwas beleuchtet werden: Im Jahr 2017 wurde die Ransomware WannaCry weltbekannt, die auf Windows-Rechnern Dateien verschlüsselte und ein Lösegeld in Bitcoin forderte. Da sich die Schadsoftware selbstständig verbreiten konnte, waren innerhalb eines Tages Systeme davon weltweit betroffen, unter anderem britische Krankenhäuser, russische und rumänische Ministerien, die Deutsche Bahn, Automobilhersteller und andere Firmen.
Der Kern des Angriffs war ein Exploit namens EternalBlue, der eine Schwachstelle im Protokoll SMB1 ausnutzen konnte. Das Protokoll SMB1 wurde schon vier Jahre zuvor, im Jahr 2013 als veraltet markiert. Immerhin zwei Jahre vor dem Hackerangriff, in 2015, konnten alle von Windows damals unterstützten Clients und Server mindestens über SMB2 oder schon SMB3 kommunizieren. Das letzte Betriebssystem, welches das Protokoll SMB1 zwingend benötigte, war Windows Server 2003, der Support für diese Server-Version dafür endete nämlich im Jahr 2015. Ein Blog von Microsoft aus dem Jahr 2015 empfiehlt Administratoren, sich darauf vorzubereiten, SMB1 komplett aus den Systemen zu entfernen. Fairerweise muss man sagen, dass ein Wechsel von SMB1 auf SMB2 nicht durch ein einfaches Update möglich war. Aus Kompatibilitätsgründen war SMB1 immer noch auf neueren Versionen des Windows-Betriebssystems standardmäßig aktiviert. Man hätte also SMB1 manuell deaktivieren müssen. Dennoch war schon lange vor dem Angriff klar, dass SMB1 veraltet ist.
Zwei Monate vor dem WannaCry-Angriff hatte Microsoft Sicherheits-Updates für alle unterstützten Windows-Versionen herausgegeben. Übrigens kannte der amerikanische Geheimdienst NSA die Schwachstelle schon Jahre zuvor, hat diese zunächst aber nicht an Microsoft weitergegeben, um die Lücke selbst ausnutzen zu können. Aus ungeklärten Gründen wurden die Kenntnisse der NSA über diese Schwachstelle jedoch geleaked und nach und nach öffentlich, woraufhin die NSA die Schwachstelle notgedrungen an Microsoft meldete. Das Update von Microsoft war trotzdem immer noch zwei Monate vor dem schwerwiegenden Tag des Angriffs. Allerdings erhielten Betriebssysteme im EoL-Status – wie beispielsweise Windows XP – vorerst kein Update von Microsoft, der Support war ja schon ausgelaufen. Erst einen Tag nach dem Erscheinen von WannaCry wurden auch dafür öffentliche Updates herausgegeben, weil das Problem offensichtlich so gravierend war.
Was können wir daraus lernen?
- Administratoren hatten zwei Monate lang Zeit für das Update. Daran sieht man, dass regelmäßiges Updaten und insbesondere das schnelle Einspielen von Sicherheitsupdates enorm wichtig ist.
- Ein proaktives Deaktivieren des schon lange vorher veralteten Protokolls SMB1 hätte schon vorzeitig gegen den Angriff geschützt.
- Die Windows-Betriebssysteme, die sich schon im EoL-Status befanden, hatten zunächst kein Update wegen dem Supportende erhalten. Daran sieht man das Risiko von EoL-Software, die trotz öffentlich bekannter Schwachstellen nicht mit Updates versorgt wird oder wie in diesem Fall zu spät ein Update bekommt, also erst nach dem Angriff. (Um ehrlich zu sein, hier die ausführliche Wahrheit der Geschichte: die Windows-XP-Systeme im EoL-Status waren schon so alt, dass die WannaCry Schadsoftware meistens den PC zum Absturz brachte und sich von diesen Systemen nicht weiterverbreiten konnte. Dieser glückliche Zufall für die EoL-Systeme machte es deutlich weniger schlimm, dass für sie zunächst kein Update verfügbar war. Das heißt aber nicht, dass EoL-Software bei einem Angriff zufällig immer abstürzt und deshalb alles gut ist.)
Bewertung von EoL-Software
Welchen Einfluss haben diese ganzen Erkenntnisse, wenn wir einen Penetrationstest durchführen? Identifizieren wir in einer Prüfung EoL-Software – und das passiert nicht nur in einer absichtlich verwundbaren Testumgebung, sondern sogar in neu entwickelten Anwendungen – dann ist die Software nicht nur leider ein kleines bisschen veraltet. Sondern es bedeutet auch, dass vielleicht schon öffentlich bekannte Schwachstellen existieren, die aber nicht mehr vom Hersteller behoben werden. Darüber hinaus können auch bisher unbekannte Schwachstellen in der Software existieren und man kann nicht davon ausgehen, dass die Software aktiv danach untersucht wird.
Insbesondere zeigt die Verwendung einer Software im EoL-Status, dass das betreffende Unternehmen die Update-Prozesse stark vernachlässigt. Beim Fall von WannaCry hat man gesehen, dass bereits das Versäumnis, ein Update innerhalb von zwei Monaten zu installieren, zur Katastrophe führen kann; End-of-Life heißt aber, dass Code meistens über Jahre hinweg nicht auf den aktuellen Stand gebracht wurde.
Was heißt das nun für die Bewertung eines solchen Fundes? Auch wenn wir üblicherweise nach dem CVSS-System bewerten, ist die Verwendung eines konkreten CVSS-Zahlenwerts bei EoL-Software fraglich. Es ist nicht das Ziel, eine einzelne Schwachstelle bewerten, die möglicherweise in der veralteten Software existiert, sondern es soll die generelle Problematik der EoL-Software aufgezeigt werden.
Deshalb bewerten wir – ohne einen konkreten Zahlenwert als CVSS-Score zu nennen – End-of-Life-Software stets mit kritischem Schweregrad. Auch wenn das zunächst einmal besonders hoch erscheint, bildet eine solche Bewertung die Summe der Probleme gut ab, schließt zudem die Möglichkeit unbekannter Schwachstellen mit ein und ist außerdem ein deutliches Signal, dass Update-Prozesse dringend und grundlegend verbessert werden sollten.
Eine Ausnahme gibt es für clientseitige JavaScript-Bibliotheken: hier wird der Schweregrad „nur“ als hoch statt kritisch eingestuft. Nachforschungen bezüglich öffentlicher Schwachstellen in verbreiteten Bibliotheken haben ergeben, dass in der Praxis die Schwachstellen für JavaScript-Bibliotheken einen Schweregrad von höchstens „Hoch“ aufweisen. Das gilt beispielsweise für die bekannten Bibliotheken JQuery, Angular, React, Vue, Ember, Meteor, Mithril, Polymer, Aurelia oder Backbone. Dies ist zwar keine vollständige Liste und auch keine Garantie, dass nie eine kritische Schwachstelle gefunden wird; Dennoch wird die Bewertung mit „Hoch“ der Erfahrung gerecht, dass JavaScript-Bibliotheken typischerweise maximal hohe Schweregrade bei Schwachstellen aufweisen.
Fazit
End-of-Life-Software bezeichnet Code, der nicht mehr vom Hersteller unterstützt und mit Updates versorgt wird. Sie weist ein nicht zu unterschätzendes Risiko auf und zeigt auch gravierende Mängel im Update-Management auf, was wir in der Bewertung beim Fund solcher Software zum Ausdruck bringen. Sollten Sie jetzt in Aktionismus verfallen und gleich alle Ihre Programme und Bibliotheken nach EoL-Status untersuchen wollen, dann ist https://endoflife.date/ eine erste Anlaufstelle. Hier sind die EoL-Versionen von verschiedener Software gelistet.
Am Besten ist es natürlich, die Software durch regelmäßige Updates aktuell zu halten. Dann haben es Angreifer gleich viel schwerer.
Und wenn man zusätzlich die Lebensmittel ein bisschen im Blick hat (also updated), dann ist vielleicht auch der Käse in der hinteren Ecke des Kühlschranks vor Ablauf des Mindesthaltbarkeitsdatums bereits verzehrt.