Open-Source-Schwachstellen brachten Equifax ins Stolpern – wie können Sie sich schützen?

Der Kreditüberwachungsriese Equifax gab letzte Woche bekannt, dass das Unternehmen gehackt wurde und dabei höchst persönliche Daten von 143 Millionen Menschen offengelegt wurden. Als Ursache nannte Equifax eine Schwachstelle in Apache Struts, einer äußerst beliebten Java-Bibliothek. Das Unternehmen ging mit seiner Reaktion auf den Angriff alles andere als souverän um – und die Sicherheit unserer Daten zu gewährleisten, liegt in seiner Verantwortung. Equifax ist jedoch keineswegs das einzige Unternehmen, das Struts oder anderen Schwachstellen in Open-Source-Bibliotheken ausgesetzt ist.

Equifax wurde wahrscheinlich entweder über die leicht auszunutzende Schwachstelle zur Remote Command Execution (RCE), die im vergangenen März bekannt wurde, oder über die neuere RCE-Schwachstelle von letzter Woche kompromittiert, die fast genauso gravierend ist. Obwohl diese Probleme für relativ viel Aufsehen gesorgt haben, gehen die Nutzer der Pakete äußerst langsam gegen sie vor.

Wir haben rund 1.000 Open-Source-Projekte auf GitHub untersucht, die Struts direkt verwenden. 64 % davon sind weiterhin anfällig für die schwerwiegende Schwachstelle vom März. Praktisch alle sind anfällig für die letzte Woche bekannt gewordene Sicherheitslücke. Bei einer separaten Untersuchung von Tausenden Java-Projekten, die Snyk getestet hat, waren 78 % beim ersten Scan für die RCE-Schwachstelle vom März anfällig, und 100 % waren von dem Problem der vergangenen Woche betroffen. (Anschließend haben wir die Nutzer auf diese Probleme hingewiesen und ihnen geholfen, sie zu beheben.)

Das Risiko durch diese Schwachstellen ist nicht theoretisch – sie stellen eine reale und unmittelbare Bedrohung dar. Nach der Bekanntgabe der RCE-Schwachstelle in Struts im März beobachteten wir eine große und zunehmende Zahl von Angriffen in freier Wildbahn, bei denen diese bekannte und leicht auszunutzende Sicherheitslücke missbraucht wurde. Auch die letzte Woche bekannt gewordene Schwachstelle führt zu zahlreichen Angriffen.

Wer trägt die Verantwortung?

Auf Sicherheitsvorfälle folgt oft ein gegenseitiges Fingerzeigen: Alle Beteiligten versuchen, jemand anderem die Schuld an der Katastrophe zu geben. Leider ist die Verantwortung für die Sicherheit von Open Source ein komplexes Thema …

In diesem Fall ist es leicht, mit dem Finger auf Apache Struts zu zeigen.

Im vergangenen Jahrzehnt wurden mehr als 40 Schwachstellen in Apache Struts bekannt, darunter schwerwiegende wie die bereits erwähnten RCE-Probleme. Das könnte zu der Annahme verleiten, Struts sei eine unsichere Bibliothek. Doch das ist weit von der Wahrheit entfernt. Das Team reagierte tatsächlich schnell und verantwortungsvoll auf die gefundenen Probleme und nahm sich – anders als viele Open-Source-Projekte – sogar die Mühe, wichtige Fehlerbehebungen auf ältere und weniger gut gepflegte Softwareversionen zu übertragen. Apache veröffentlichte eine gut formulierte Stellungnahme zum Equifax-Vorfall.

Als Nächstes könnten die Equifax-Entwickler verantwortlich gemacht werden, die das gehackte Portal entwickelt haben.

Sie entschieden sich für eine Open-Source-Bibliothek eines Drittanbieters, ohne zu prüfen, ob bekannte Schwachstellen vorlagen, oder diese kontinuierlich zu überwachen – mit verheerenden Folgen. Diese Entwickler tragen durchaus Verantwortung, denn sichere Software zu entwickeln gehört zu ihrem Auftrag. Dabei darf jedoch nicht vergessen werden, dass Entwickler keine Sicherheitsexperten sind und vielen die Risiken bei der Verwendung einer Open-Source-Bibliothek nicht bewusst sind. Außerdem haben Entwickler in großen Unternehmen wie Equifax oft nicht die nötigen Befugnisse, um „über den Tellerrand zu blicken“ und Verantwortung für mehr als das ausdrücklich Angeforderte zu übernehmen.

Betrachtet man die formalen Zuständigkeiten, liegt die Schuld beim Sicherheitsteam von Equifax.

Es ist offiziell dafür zuständig, die Systeme zu schützen, und hat diese Aufgabe offensichtlich nicht erfüllt. Zweifellos hat das Team versagt. Doch wenn das Sicherheitsteam von Equifax so aufgestellt ist wie alle anderen, die ich kenne, fehlen ihm vermutlich die Voraussetzungen, um die Anwendungen des Unternehmens erfolgreich abzusichern. Sicherheitsteams sind Entwicklern oft im Verhältnis 1 zu 100 zahlenmäßig unterlegen und können mit dem Tempo der modernen Softwareentwicklung, das durch genau diese Open-Source-Bibliotheken zusätzlich beschleunigt wird, schlicht nicht Schritt halten. Wenn allein das Sicherheitsteam für die Sicherheit zuständig ist, ist ein schwerwiegender Sicherheitsvorfall so gut wie sicher.

Damit kommen wir zum letzten Verantwortlichen für dieses Fiasko – dem Führungsteam von Equifax.

Es trägt moralisch und rechtlich die Verantwortung für unsere persönlichen Daten und entscheidet, wie viel in deren Schutz investiert wird – auch auf Kosten von Gewinn und Wachstum. Außerdem muss es dafür sorgen, dass sich das gesamte Unternehmen um Sicherheit kümmert und diese nicht einem kleinen Team überlassen wird. Schließlich muss es verstehen, dass moderne Entwicklungsmethoden wie die Verwendung von Open-Source-Bibliotheken auch neue Risiken mit sich bringen und diese Risiken angemessen gemanagt werden müssen. An der Verantwortung des Führungsteams gibt es für mich nichts zu relativieren. Allerdings ist kein Unternehmen vollkommen sicher, und ein Versagen bedeutet nicht zwangsläufig Fahrlässigkeit oder Inkompetenz.

So vermeiden Sie, zum nächsten Equifax zu werden

Statt nach Schuldigen zu suchen, sollten wir uns einen Moment Zeit nehmen und darüber sprechen, wie Sie verhindern können, dass Ihr Unternehmen als Nächstes in der Ruhmeshalle der Sicherheitsvorfälle landet. Hier sind einige Maßnahmen, mit denen Sie sich jetzt und dauerhaft schützen können.

1. Lassen Sie Ihre Anwendungen testen. Prüfen Sie Ihre Anwendungen mit einem Open-Source-Sicherheitstool, das anfällige Open-Source-Bibliotheken erkennt – einschließlich der Struts-RCE-Schwachstellen. Testen Sie unbedingt alle Ihre Anwendungen.

2. Beheben Sie die gefundenen Probleme. Die Scheuklappen abzulegen und anfällige Bibliotheken zu erkennen, ist ein notwendiger erster Schritt. Wenn Sie die gefundenen Probleme jedoch nicht beheben, bleiben Sie genauso anfällig. Es reicht nicht, Schwachstellen lediglich zu protokollieren – lassen Sie sie beheben.

3. Überwachen Sie Schwachstellen in den von Ihnen verwendeten Bibliotheken. Es ist gut, jetzt nach anfälligen Bibliotheken zu suchen. Sie können jedoch sicher sein, dass morgen neue Schwachstellen entdeckt werden – wie wir gerade bei Struts gesehen haben. Richten Sie Benachrichtigungen zu neu bekannt gewordenen Schwachstellen ein und sorgen Sie dafür, dass Sie sie beheben können, bevor Angreifer sie ausnutzen.

4. Finden Sie Sicherheitstools, die Entwickler gerne verwenden. Ihr Sicherheitsteam lässt sich nicht beliebig vergrößern, und Entwickler stellen andere Anforderungen an ihre Tools als Sicherheitsexperten. Finden Sie Sicherheitstools, die Entwickler gerne nutzen, und bringen Sie Ihre Entwicklungsteams dazu, sie einzusetzen. Wie bei DevOps brauchen wir mehr Menschen, die Verantwortung für Sicherheit übernehmen (oft als DevSecOps bezeichnet).

Wenn Sie nicht wissen, wo Sie anfangen sollen, starten Sie mit einem Scan über die CLI oder die GitHub-Integration von Snyk. Ich bin natürlich voreingenommen, wenn ich das vorschlage. Doch zumindest weist Sie der kostenlose Tarif von Snyk auf Probleme in Ihren Anwendungen hin und hilft Ihnen dabei, sie zu beheben. Wenn Sie Snyk nicht verwenden möchten, suchen Sie sich ein anderes Tool – aber unternehmen Sie etwas, bevor Ihnen das Problem über den Kopf wächst.

Das ist kein Struts-Problem

Abschließend sei darauf hingewiesen, dass dieses Problem weder auf Struts noch auf das Java-Maven-Ökosystem beschränkt ist. Allein im vergangenen Monat wurden eine Schwachstelle zur Ausführung beliebigen Codes im beliebten Node.js-npm-Paket pg sowie eine Cross-Site-Scripting-Schwachstelle im Python-Framework django bekannt.

Im Monat davor wurden unter anderem eine XSS-Schwachstelle in Spark Core, einer beliebten Java-basierten Big-Data-Plattform, bekannt. Außerdem wurden Dutzende schädliche Pakete in der npm-Registry entdeckt. Studien aus diesem Jahr zeigen, dass 77 % der Websites auf ihrer Startseite eine anfällige JS-Bibliothek verwenden.

Die Liste ließe sich endlos fortsetzen. Entscheidend ist: Schwachstellen in Ihren Open-Source-Bibliotheken zu verfolgen und zu beheben, ist für jedes Unternehmen heute unverzichtbar. Wirksam gelingt das nur, wenn Sie diesen Schritt in Ihren Entwicklungsprozess integrieren. Wenn Sie dazu Unterstützung benötigen, schreiben Sie uns eine E-Mail – wir helfen Ihnen beim Einstieg. Was auch immer Sie tun: Lernen Sie aus dem Fehler von Equifax und wiegen Sie sich nicht in falscher Sicherheit.