Wie sicher ist Open Source?

Durch den Einsatz von Open-Source-Komponenten sparen Entwickler Zeit und Geld. Lesen Sie im folgenden Beitrag, warum Open Source ein Risiko für das Unternehmen sein kann. [...]

Es ist oft schwierig, alle laufenden Software-Komponenten zu lokalisieren. (c) vege - Fotolia
Es ist oft schwierig, alle laufenden Software-Komponenten zu lokalisieren. (c) vege - Fotolia

Der Equifax-Vorfall hat daran erinnert, dass Open-Source–Software und Komponenten trotz ihrer zahlreichen Vorteile ein riesiges Risiko für die Unternehmenssicherheit darstellen, insbesondere wenn sie nicht ordnungsgemäß gewartet werden.

Im April gaben Forscher von Flashpoint Intelligence bekannt, dass Kriminelle Brute-Force-Passwort-Attacken gegen die beliebte Open-Source-Magento-E-Commerce-Plattform nutzten und den kompromittierten Zugriff auf Kreditkartendaten ermöglichten sowie Malware installierten, die auf Kryptowährungs-Mining fokussiert war.

Die Forscher entdeckten mindestens 1.000 kompromittierte Magento-Admin-Panels und erklärten, dass das Interesse an der Plattform im Deep Web und Dark Web seit 2016 ungebrochen ist. Darüber hinaus gibt es ein breites Interesse an Powerfront CMS und OpenCart.

Agil mit Open Source

Open-Source-Code hat im Laufe der Jahre an Popularität gewonnen und wird von Unternehmen aller Größen in allen Industriezweigen verwendet. Neben den weit verbreiteten Open-Source-Betriebssystemen nutzen Unternehmen Open-Source-Produktivitätssoftware, Tools für Administratoren und Entwickler sowie verschiedene Code-Bibliotheken, die zum Erstellen eigener Software verwendet werden. Sogar kommerzielle Software ist typischerweise auf Basis von Open-Source–Code aufgebaut.

„Ich erkenne eine breite Akzeptanz von Open-Source–Software im Unternehmen“, sagt Andrew Howard, CTO bei Kudelski Security. „Wenn Unternehmen zu agilen Methoden übergehen, wird Open Source interessanter und es stehen ihnen mehr Tools zur Verfügung. Junge Softwareentwickler, die heute auf den Markt kommen, sind darin geschult, sich mit Open Source-Technologien sehr gut auszukennen.“

Sicherheitsvorteile von Open Source

„Unternehmen sind besonders mit großen Open-Source-Projekten zufrieden, in denen große Gruppen involviert sind“, sagt Howard. „Außerdem zählt hier das Viele-Augen-Prinzip. Das ist der Hauptvorteil der Verwendung von Open-Source–Software – abgesehen von den geringeren Kosten.“

Ein weiterer Sicherheitsvorteil von Open-Source–Code ist, dass ein Unternehmen bei einem Problem die Datei öffnen und sofort reparieren kann. „Wenn der Code unter proprietären Vereinbarungen lizenziert ist, müssen Unternehmen in der Regel darauf warten, bis der Anbieter reagiert“, meint Mel Llaguno, Open Source Solution Manager bei Synopsys.

Warum Open-Source-Software eine Sicherheitsbedrohung darstellt

Synopsys verwaltet Coverity Scan, einen kostenlosen Dienst, der den offenen Quellcode auf Fehler scannt. „Insgesamt hat sich die Qualität von Open-Source–Software verbessert“, sagt Llaguno. „Wir haben etwa 750 Millionen Zeilen Open Source Code, die an unseren Scan-Projekten teilnehmen. Davon sind rund 1,1 Millionen fehlerhaft. 650.000 Fehler wurden bereits behoben.“ Er fügt hinzu, dass viele Projekte, insbesondere kleinere, ihren Code nicht auf mögliche Sicherheitslücken untersuchen.

Black Duck Software verfolgt mehr als 10 Milliarden Zeilen Open-Source–Code in mehr als 550.000 Projekten. Auch das ist kein vollständiges Bild. Die Linux Foundation berichtet, dass 31 Milliarden Zeilen Code für Open-Source-Repositories bereitgestellt wurden.

Wer nutzt die offenen Quellcodes? Jeder. Laut dem neuesten Black-Duck-Bericht haben 96 Prozent der kommerziellen Anwendungen Open-Source-Komponenten. Anwendungen haben durchschnittlich 147 verschiedene Open-Source-Komponenten – und 67 Prozent der verwendeten Komponenten haben bekannte Schwachstellen.

Die US-Regierung sponsert die Liste der Common Vulnerability Enumeration und die National Vulnerability Database. Im Jahr 2017 wurden der CVE-Liste mehr als 8.000 neue Schwachstellen hinzugefügt, ein Rekordwert. „In einer durchschnittlichen Anwendung ist mehr als ein Drittel der Codebasis Open Source„, sagt Mike Pittenger, Sicherheitsstratege von Black Duck bei Synopsys. „Um dieses Drittel der Codebasis zu ersetzen, müsste man das Entwicklungsteam oder die Entwicklungszeit um 50 Prozent erhöhen. Ich denke nicht, dass dies in der heutigen Welt praktikable Optionen sind.“

Nehmen wir zum Beispiel die in London ansässige Reisesuchmaschine Skyscanner. Das Angebot lief früher auf proprietären, geschlossenen Plattformen wie .NET. „In den letzten Jahren wurde es in eine breitere Palette von Sprachen und Technologien migriert, einschließlich Open Source„, sagt Skyscanners Sicherheitsingenieur Alex Harriss. „Dies bedeutet, dass unsere Ingenieure nun in der Lage sind, Komponeneten aus mehreren Quellen zu beziehen und ihren Code innerhalb von Minuten zu implementieren.“

Dies habe auch Sicherheitsprobleme geschaffen, ist Harriss überzeugt. „Ich denke, dass es da ein trügerisches Vertrauen in die Community gibt, die die Bibliotheken auf Sicherheitslücken überprüfen sollten. In Wirklichkeit scheint dies nicht immer der Fall zu sein.“

Es gibt gut dokumentierte Schwachstellen in vielen der gebräuchlichsten Bibliotheken. Da Ingenieure nur Code aus diesen Bibliotheken abrufen und bereitstellen, führt dies zu einem Sichtbarkeitsproblem: „Wir waren uns der Anzahl der Abhängigkeiten in unseren Produkten einfach nicht bewusst“, so Harris.

Mehr Sorgfalt bei der Sicherheit von Open-Source-Software

Skyscanner ist mit seinem Problem nicht allein. Laut dem neuesten Veracode-Bericht führen nur 28 Prozent der Unternehmen eine regelmäßige Analyse durch, um herauszufinden, welche Komponenten in ihren Anwendungen enthalten sind. Mit zunehmendem Einsatz von Open Source Code steigt das Risiko.

Im Open-Source–Code werden ständig neue Sicherheitslücken gefunden, und in vielen Projekten gibt es keine Prozesse, um Probleme zu finden und zu beheben. Laut einer aktuellen Snyk-Umfrage unter Open-Source-Maintainern hatten 44 Prozent noch nie ein Sicherheitsaudit, und nur 17 Prozent gaben an, über ein hohes Sicherheits-Knowhow zu verfügen.

Es gibt auch keine standardisierte Möglichkeit, die Sicherheit von Open-Source-Projekten zu dokumentieren. In den obersten 400.000 öffentlichen Repositorien auf GitHub hatten nur 2,4 Prozent eine Sicherheitsdokumentation.

Wenn das Problem behoben ist, gibt es oft keine Möglichkeit, alle Benutzer des alten Codes zu finden und zu benachrichtigen. „Die Open-Source-Community hat keine Ahnung, wer ihre Komponenten verwendet“, sagt Black Ducks Pittenger.

Laut der Snyk-Umfrage fügen 88 Prozent der Open-Source–Code-Betreuer sicherheitsrelevante Ankündigungen zu den Versionshinweisen hinzu 34 Prozent geben an, dass sie die ältere, unsichere Version ablehnen. Fünfundzwanzig Prozent sagen, dass sie sich überhaupt nicht darum bemühen, Benutzer über Sicherheitslücken zu informieren, und nur 10 Prozent reichen einen „Common Vulnerabilities and Exposures“ (CVE) ein.

„Viele sind sich nicht bewusst, wie der CVE-Prozess funktioniert oder haben keine Zeit, ihn durchzugehen“, sagt Guy Podjarny, CEO und Mitbegründer von Snyk. „In Javascript beispielsweise haben nur 13 Prozent der Schwachstellen, die wir verfolgen, eine CVE-Nummer. Der Rest wird nur als Fehler protokolliert.“

Snyk hat ein Sicherheits-Forschungsteam, das nach Anzeichen von Sicherheitsproblemen in Open-Source-Bibliotheken sucht, indem er an Orten wie den Versionshinweisen und den GitHub- und Apache-Problemverfolgungssystemen nach Hinweisen sucht. Die Ergebnisse werden in seiner Schwachstellendatenbank veröffentlicht, und wenn möglich, übermittelt Snyk sie auch an die CVE-Liste.

Die Erstellung eines CVE kann jedoch ein komplizierter Prozess sein und erfordert, dass sich ein Ausschuss auf die CVE-Details und die Zustimmung durch den Project Owner einigen muss. „Die Art, wie der Prozess derzeit läuft, skaliert er nicht“, sagt Podjarny.

Wenn schließlich eine Sicherheitslücke gefunden, gepatcht und der Patch allgemein veröffentlicht wird, wissen Unternehmen, die diesen Code verwenden, möglicherweise nicht, dass sie von diesem Fehler betroffen sind oder haben möglicherweise Probleme, alle relavanten Instanzen zu finden. Der Equifax-Vorfall zum Beispiel beinhaltete eine Sicherheitslücke in der Apache Struts-Open-Source–Software. Der Patch kam ein paar Monate vor dem Vorfall heraus. Equifax kannte den Patche zwar, war aber nicht in der Lage, die Korrekturen rechtzeitig zu machen.

Ein weiteres Problem ist, dass einige Unternehmen ältere Versionen des Codes ausführen und aufgrund von Kompatibilitätsproblemen, Compliance oder anderen Gründen nicht auf die neueste Version wechseln können. Laut Snyk werden nur 16 Prozent der Sicherheitslücken in andere Versionen portiert.

Finden und beheben

In einer idealen Welt würden sich Anwendungen automatisch aktualisieren, sobald ein Sicherheitspatch verfügbar ist, ohne dass ein Eingreifen erforderlich ist. In der Praxis ist dies jedoch nicht immer möglich.

Stattdessen müssen Unternehmen eine Möglichkeit haben, alle Instanzen von Open Source–Code in ihren Umgebungen zu finden, diese Liste ständig zu aktualisieren, Entwickler von alten, unsicheren Bibliotheken wegzugekommen und Patches zu veröffentlichen, sobald neue Schwachstellen entdeckt werden.

„Das Entfernen gefährlicher Bibliotheken aus den Produkten ist nur dann möglich, wenn man weiß, wo sie sich befinden. Und je früher man aktiv wird, desto billiger und einfacher ist es“, sagt Harriss von Skyscanners .

Viele Unternehmen wenden sich an Anbieter wie Snyk, Black Duck und Veracode. Harriss; „Snyk ermöglichte uns, zu sehen, welche Pakete in welchen Projekten verwendet wurden, welche Sicherheitslücken sie enthielten und wie sie in unseren Code eingeführt wurden.“ Darüber hinaus würde Snyk Sicherheitslücken sofort erkennen, sobald die Entwickler Code schreiben. Damit können die Probleme behoben werden, bevor der Code produktiv geht.

Die Integration von Open-Source–Schwachstellen-Scans in den Entwicklungsprozess ist besonders wichtig für große Unternehmen, da es schwierig sein kann, den gesamten verwendeten Code aufzuspüren. „Die meisten Unternehmen, mit denen wir zu tun haben, kennen nicht die vollständige Liste ihrer Anwendungen, was ein wenig unheimlich ist“, sagt Chris Eng, Vice President of Research bei Veracode.

Wenn Veracode einen Schwachstellenscan durchführt, laden die Unternehmen ihren Binärcode hoch und Veracode prüft ihn auf Basis der National Vulnerability Database. Um Unternehmen dabei zu helfen, herauszufinden, welche Anwendungen ausgeführt werden, von denen sie möglicherweise nichts wissen, kann Veracode auch das Perimeter des Unternehmens scannen.

„Es gibt auch Netzwerk-Tools, die Unternehmen verwenden können, um herauszufinden, was intern läuft“, fügt Eng hinzu, „aber es kann blinde Flecken geben, wenn das Netzwerk segmentiert ist. Unternehmen können auch Agenten auf Endpunktgeräten installieren, um zu verfolgen, was läuft. Und Sie könnten immer noch einige blinde Flecken haben, wenn Sie den Agenten nicht überall installiert haben. Es gibt kein Rezept, um all dies hinzubekommen, weshalb es ein so schwieriges Problem ist.“

Es war sicherlich ein schwieriges Problem für Equifax. Im letzten Oktober sagte der ehemalige CEO Richard Smith dem US-Kongress, dass die Abteilung für Informationssicherheit des Unternehmens Scans durchgeführt habe, um nach der Apache-Struts-Schwachstelle zu suchen, die schließlich zur Verletzung führte. Die Scans „identifizierten keine Versionen von Apache Struts, die dieser Sicherheitslücke ausgesetzt waren, und die Sicherheitslücke blieb in einer Equifax-Webanwendung viel länger als sie sollte“, sagte er.

„Sie müssen sicherstellen, dass Sie jeden Server in Ihrer Umgebung kennen, um ihn mit diesem Tool zu scannen“, sagt Pittenger von Black Ducks. „Selbst wenn die Scans vollständig und genau sind, verursachen sie einen hohen Verwaltungsaufwand für die Organisationen. Wenn die Sicherheitsprüfungen nicht in den Entwicklungsprozess integrierte sind, müssen diese Scans kontinuierlich ausgeführt und Anwendungen einzeln immer wieder auf Schwachstellen überprüft werden.“

Entwickler bringen nicht nur neue, anfällige Bibliotheken in ihre Anwendungen ein, sondern auch alte Bibliotheken, die zuvor als sicher galten, aber nun neue Schwachstellen haben. „Software altert nicht wie Wein, sie altert wie Milch“, bringt es Eng auf den Punkt.

Entwickler überprüfen die Bibliotheken, die sie in alten Projekten verwendeten, nur selten. Ich lade die aktuellste Version herunter, übernehme sie in meine App und denke nie wieder darüber nach“, sagt Eng.

*Maria Korolov ist Redakteurin des US-Magazins CSO.

Werbung


Mehr Artikel

Be the first to comment

Leave a Reply

Your email address will not be published.


*


Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahren Sie mehr darüber, wie Ihre Kommentardaten verarbeitet werden .