#Equifax #ApacheStruts
2017 wurde der Finanzdienstleister Equifax Opfer eines groß angelegten Hackerangriffs.Die Ursache soll eine Sicherheitslücke in einer Open-Source-Software gewesen sein, die Equifax einsetzte. Nach derart großen Pannen werden immer wieder Stimmen laut, Open Source wäre unsicher. Die Ursachen sind jedoch meist auf einen fahrlässigen Umgang mit Open-Source-Software und bereits bekannten Sicherheitslücken zurückzuführen. Wer selbst Open Source einsetzt, sollte prüfen, ob man nicht ebenfalls durch Nachlässigkeit gefährdet ist.
Am 8. März 2017 hat das US-amerikanische Ministerium für Heimatschutz, genauer das Computer-Emergency-Readiness-Team (US-CERT), eine Warnung herausgegeben, dass eine Sicherheitslücke in bestimmten Versionen von Apache Struts besteht und diese gepatched werden muss. Der Finanzdienstleister Equifax, eine der wichtigsten Kreditauskunfteien der USA, nutzte Struts in ihrem Online-Dispute-Portal, eine Website auf der Verbraucher Beanstandungen über ihre Kreditauskunft anfechten können. Tausende dieser Kreditauskunftsdatensätze gelangten so in die Hände von Hackern. Laut Aussagen von Ex-Equifax-CEO Richard Smith weiß man nun, dass die anfällige Version von Apache Struts bei Equifax weder gefunden noch gepatcht wurde. Über die Hintergründe ist nichts bekannt.
Welche Struts-Sicherheitslücke lag eigentlich vor?
Erste Spekulationen deuteten darauf hin, dass es die Schwachstelle CVE-2017-9805 war, die etwa zur gleichen Zeit bekannt wurde, wie die Nachricht, dass Equifax gehackt wurde. Schuld war jedoch CVE-2017-5638, die im März letzten Jahres berichtet wurde. Zu diesem Zeitpunkt waren bereits Exploits verfügbar. Mehrere Websites berichteten bereits von aktiven Versuchen, sie zu scannen und diese Exploits zu nutzen.
Die Datendiebstähle sind laut Equifax von Mitte Mai bis Juli geschehen. Die OSSRA-Research (Open Source Security & Risk Analysis) von Black Duck legt nahe, dass Equifax vermutlich keine vollständige Sicht auf den von ihnen verwendeten Open-Source-Code hatte. Im OSSRA-Bericht haben wir festgestellt, dass Unternehmen doppelt so viel Open Source nutzten, wie sie selbst annehmen. Insgesamt 67 Prozent der analysierten Anwendungen mit Open-Source-Code hatten Schwachstellen in den verwendeten Komponenten; im Durchschnitt waren die in diesen Anwendungen identifizierten Schwachstellen seit mehr als vier Jahren öffentlich bekannt.
Das Sicherheitsteam von Equifax mag sich zwar dieser Sicherheitslücke bewusst gewesen sein, doch die Anwendungen, die gehackt wurden, flogen offenbar völlig unter ihrem Radar. Dies würde erklären, wie eine im März offenbarte Open-Source-Schwachstelle im Zeitraum von Mai bis Juli bei Equifax weiterhin von Hackern genutzt werden konnte.
Der Patch für CVE-2017-5638 stammt also aus März – lange vor Mai und damit lange vor dem Equifax-Vorfall. Die meisten Fehlerbehebungen erfordern den Download und die Installation eines Patches sowie den Neustart des Servers. Im Gegensatz dazu erfordert die Behebung dieser speziellen Sicherheitslücke in der Regel, dass jede Web-Anwendung, die mit der anfälligen Version von Apache Struts entwickelt wurde, mit einer gepatchten Version neu kompiliert wird.
Warum sollte Equifax die Sicherheitslücke für weitere zwei Monate auf sich beruhen lassen? Möglich, dass das Team bei Equifax die ganze Zeit daran gearbeitet hat, diesen Patch zu installieren und in der Ausführung einfach nicht schnell genug war. Aber angesichts der Schwere der Lücke scheint es unwahrscheinlich, dass sie diese wissentlich so lange offen gelassen hätten. Die wahrscheinlichere Antwort scheint zu sein, dass niemand diese bestimmte Software auf dem Schirm hatte.
Wie man mit Sicherheitslücken umgehen sollte
Das Apache-Struts-Projektmanagementkomitee veröffentlichte eine Stellungnahme zum Equifax-Vorfall, der Vorschläge zum Sichern aller offenen oder geschlossenen Quellbibliotheken in Softwareprodukten und -diensten enthält:
1. Stellen Sie sicher, dass Sie wissen, welche Frameworks und Bibliotheken, in welchen Versionen, in Ihrer Software verwendet werden. Verfolgen Sie Sicherheitsankündigungen, die diese Produkte und Versionen betreffen.
2. Richten Sie Prozesse ein, um schnell ein Sicherheits-Update durchführen zu können, sobald die Unterstützung von Frameworks oder Bibliotheken aus Sicherheitsgründen aktualisiert werden muss. Am besten ist es dabei in Stunden oder ein paar Tagen zu denken – nicht in Wochen oder Monaten. Die meisten Verstöße, die wir bemerken, werden dadurch verursacht, dass bekannte Schwachstellen, die monatelang oder sogar jahrelang angreifbar sind, nicht gefixt werden.
3. Denken Sie daran: Jede komplexe Software enthält Fehler. Man sollte seine Sicherheitsrichtlinien nicht auf der Annahme aufbauen, dass die eingesetzten Softwareprodukte fehlerfrei sind.
4. Richten Sie Sicherheitsebenen ein. Es ist ein gutes Verfahren des Software-Engineerings, individuell gesicherte Schichten hinter einer öffentlichen Präsentationsschicht wie dem Apache-Struts-Framework zu haben. Eine Lücke in der Präsentationsschicht sollte niemals den Zugriff auf signifikante oder sogar alle Back-End-Informationsressourcen ermöglichen.
5. Überwachen und erkennen Sie ungewöhnliche Zugriffsmuster auf öffentliche Web-Ressourcen. Heutzutage gibt es viele Open-Source- und kommerzielle Produkte, um solche Muster zu erkennen und Warnungen zu geben. Das Monitoring von geschäftskritischen, webbasierten Diensten ist gute Praxis und wird empfohlen.
Diese Ratschläge stellen eine gute Grundlage dar, um solche Vorfälle wie bei Equifax zu vermeiden.
Mangel an Sichtbarkeit könnte Tür zum Exploit geöffnet haben
Ähnlich wie bei Heartbleed beleuchtet dieser Vorfall das Problem der Open-Source-Sicherheit und den Wettlauf zwischen den Anwendern und (potenziellen) Open-Source-Hackern, sobald eine Sicherheitslücke gemeldet wird. Da Open Source so weit verbreitet und leicht zugänglich ist, sind Exploits direkt auf YouTube und Hacker-Seiten verfügbar, nachdem eine Sicherheitslücke zum ersten Mal gemeldet wurde. Diese Exploits wirken wie ein Türöffner. Hacker nutzen sie, um in tausende von Websites und Anwendungen einzudringen. Zu diesem Zeitpunkt besteht größtes Risiko für einen Angriff und daraus folgenden Schaden. Equifax verfügt – wie viele andere Unternehmen – über ein großes Anwendungsportfolio. Wie die OSSRA-Studie belegt, überwachen die meisten Unternehmen die von ihnen verwendeten
Open-Source-Komponenten nicht ausreichend. Falls Equifax also keine Lösung wie Black Duck Hub implementiert hat, ist davon auszugehen, dass sie höchstwahrscheinlich auch kein vollständiges und verlässliches Inventar der Open-Source-Komponenten in ihren Anwendungen haben. Als die Sicherheitslücke im März aufgedeckt wurde, wusste Equifax wahrscheinlich nicht einmal, dass sie gefährdet waren. Selbst dann nicht, wenn ihr Sicherheitsteam über die Sicherheitslücke informiert war. Anders ausgedrückt: Sie waren im Blindflug.
Während die Exploits für CVE-2017-5638 bereits bekannt waren und fast unmittelbar nach der Offenlegung der Sicherheitslücke auch genutzt wurden, lief Equifax ahnungslos in die Falle. Bei Equifax stand die Tür vier Monate lang offen – in diesem gesamten Zeitraum scannten und sondierten Hacker aktiv nach verwundbaren Websites und Anwendungen.
Der Datenzugriff wurde bei Equifax bemerkt. Bei durchschnittlich 206 Tagen für die Identifizierung und Behebung von Sicherheitslücken (vgl.siehe Data Breach Report des Ponemon-Instituts für das Jahr 2017) zeigt dies, dass die Reaktionszeit von Equifax überdurchschnittlich schnell war.
Was können Unternehmen aus dem Equifax-Vorfall lernen?
Aufgrund möglicher Auswirkungen auf die Privatsphäre der User, anschließende Rechtsstreitigkeiten und sogar Folgen für die Politik, sollten sich Führungskräfte und Sicherheitsteams fragen, ob sie nicht ebenfalls von derartigen Sicherheitslücken gefährdet sind. Am Ende gibt es viele Lektionen, die gelernt werden müssen und Teams helfen können, diese Art von Sicherheitslücke zu vermeiden:
1. Einsicht und Kontrolle ist unabdingbar. Man kann sich nicht schützen, wenn man nicht weiß, was im Code enthalten ist. Wenn man nicht über ein vollständiges Bild des von den Teams verwendeten Open-Source-Codes verfügt, setzt man seine Anwendungen großer Gefahr aus.
2. Das Schwachstellenmanagement von Open Source muss automatisiert und eng in Entwicklungs- und DevOps-Tools sowie Prozesse integriert werden. Der Code ist nur so sicher wie sein schwächster Teil. Nur wenn sichergestellt ist, dass der gesamte Code einschließlich der schwächsten Glieder gescannt wurde, bevor man mit dem Roll-Out der Anwendung beginnt, ist der Open-Source-Code in Ordnung.
3. Man sollte alles Mögliche tun, um das Zeitfenster zwischen der Meldung der Sicherheitslücke und dem Moment, in dem sie gepatcht oder behoben wird, zu minimieren. Jeden Tag werden mehr als zehn neue Open-Source-Sicherheitslücken öffentlich gemacht. Leider reicht die National Vulnerabilities Database (NVD) als frühzeitige Warnung nicht aus. Die Untersuchungen von Black Duck haben gezeigt, dass es
durchschnittlich drei Wochen dauert, bis Schwachstellen in der NVD dokumentiert sind.
Nach derartig großen Sicherheitspannen wie bei Equifax, werden immer wieder Stimmen laut, Open Source wäre grundsätzlich unsicher. Doch Open-Source-Software ist nicht mehr oder weniger unsicher als jede andere Software auch. Wenn man sie jedoch nicht konsequent überwacht und bei Sicherheits-Updates nicht auf dem Laufenden bleibt, setzt man sich selbst sowie die Systeme und Daten seiner Kunden einem Risiko aus.
Als Vice President of Product Strategy bei Black Duck Software konzentriert sich Patrick Carey auf die Zusammenarbeit mit Technik- und Produktmanagement-Teams. Er entwickelt und verbessert mit ihnen Lösungen, die Unternehmen dabei unterstützen, schnell und sicher Software zu erstellen, wenn sie Open-Source-Code-Komponenten integrieren. Die Software von Black Duck ermöglicht es Kunden sicherzustellen, dass der Open-Source-Code in ihren Anwendungen frei von bekannten Open-Source-Schwachstellen sowie mit Open-Source-Lizenzen konform ist – von der Code-Auswahl, über den Entwicklungsprozess, bis zur Auslieferung der Anwendung.
