Nach Log4Shell: gegen Open-Source-Exploits ohne Ende

Originalartikel von Anthony Musk

Ein Monat in der Cybersicherheit kann sich manchmal wie ein ganzes Leben anfühlen. Seit Mitte Dezember nunmehr sorgten Log4Shell-Angriffe und die dann im Logging-Tool Log4j gefundenen Schwachstellen für schlaflose Nächte. Das Protokollierungsprogramm ist so allgegenwärtig im Einsatz, dass die damit verbundenen Bedrohungen uns noch Monate oder sogar Jahre begleiten werden. Zum Leidwesen der Sicherheitsexperten, ihrer Arbeitgeber und Kunden gibt es ein noch viel größeres Problem. Trend Micro ist eine von mehreren Stimmen, die vor den Auswirkungen von Open-Source-Fehlern auf die Sicherheit der digitalen Welt warnen. Wenn wir nicht bald etwas unternehmen, könnte Log4Shell der Beginn eines äußerst unwillkommenen Trends sein: eine Cyber-Pandemie, die durch Open-Source-Exploits angeheizt wird.

Log4Shell wurde weithin als eine der schlimmsten Sicherheitslücken der letzten Jahre angesehen. Die CVSS-Wertung von 10,0 spiegelt einen relativ einfach auszunutzenden Fehler wider, der in einem fast überall genutzten Java-basierten Protokollierungstool vorhanden ist, aufgrund von verschiedenen Abhängigkeiten auch schwer zu finden sein kann, und der die Ausführung von Remote Code ermöglicht. Kurz nach den ersten Vorfällen wurden vier weitere Schwachstellen in demselben Paket entdeckt, die unterschiedlich kritisch sind.

Die Frage ist nun, welche Zero-Days in anderen Open-Source-Tools lauern könnten. Ein Blick auf die mehr als 200 laufenden Projekte des Open-Source-Giganten Apache, Verwalter von Log4j, zeigt auch andere weit verbreitete Software wie Hadoop und OpenOffice. Erst letzte Woche wurde ein kritischer „Log4Shell-ähnlicher“ Fehler in einer beliebten Java-SQL-Datenbank namens H2 entdeckt.

Die Zahl der in solchen Angeboten und in Software im Allgemeinen entdeckten Schwachstellen steigt rasant an. Tatsächlich war 2021 ein Rekordjahr für CVEs, das fünfte Jahr in Folge, in dem dies der Fall war. Die NIST-Analyse der Verteilung des CVSS-Schweregrads über die Zeit zeigt zudem einen deutlichen Anstieg ab 2016:

Die DevOps-Herausforderung

Die Herausforderung bei Open Source ist vor allem die Art und Weise, wie sie genutzt wird. Der Druck auf die Entwickler, Produkte schnell auf den Markt zu bringen, wird immer größer und häufig wird die Software nicht auf Sicherheitsmängel geprüft. Der aufgrund der Pandemie steigende Druck zur digitalen Transformation hat diese Trends nur noch beschleunigt.

Ein gängiger Weg mit diesem Druck fertig zu werden, besteht im Einsatz vorgefertigter Open-Source-Pakete, die in einer beliebigen Zahl von Repositories verfügbar sind. Es wird angenommen, dass Entwickler 2021 mehr als 2,2 Billionen Open-Source-Pakete aus den vier wichtigsten Ökosystemen anforderten: Java, JavaScript, Python und .NET. Das Problem dabei ist, dass das, was sie herunterladen, manchmal fehlerhaften Code enthält, der unwissentlich Cyberrisiken durch die Hintertür einführt. Es spricht auch einiges dafür, dass die meisten Open-Source-Tools weniger häufig gepatcht und aktualisiert werden als kommerzielle Software, so dass Hacker mehr Zeit haben, um Schwachstellen im Code zu finden.

Ein Anbieter behauptete sogar, dass Hacker proaktiv Fehler in den Code von Upstream-Repositories einfügen und sie dann ausnutzen, bevor sie entdeckt werden. Solche Angriffe sollen 2021 im Vergleich zum Vorjahr um 650 % zugenommen haben.

Was tun in 2022

Leider geben laut unserer Studie 92 % der IT-Entscheidungsträger an, ihr Unternehmen wäre bereit, zugunsten der digitalen Transformation, der Produktivität oder anderer Ziele Kompromisse bei der Sicherheit einzugehen. Das muss sich ändern. Tatsächlich brauchen Unternehmen keine Abstriche in puncto Sicherheit zu machen. Mit dem richtigen Ansatz können sie sicheren Code und sichere Produkte pünktlich liefern.

Hier sind einige Vorschläge für den Weg dorthin:

  • Sie sollten Ihr Software-Asset-Register, einschließlich aller Abhängigkeiten kennen – etwa welche Datenbanksoftware läuft hinter Anwendung X/Y?
  • Verstehen Sie das Datenrisiko, das mit jeder Anwendung einhergeht – wissen Sie wirklich, wie hoch Ihr Datenrisiko pro Anwendung tatsächlich ist und welche Auswirkungen dies auf Ihr Unternehmen haben könnte?
  • Wie hoch ist die laterale Bedrohung durch einen Anwendungseinbruch? Können Sie Ihr Netzwerk weiter segmentieren, um das Risiko zu verringern? Ist eine Zero-Trust-Strategie sinnvoll, um Notmaßnahmen wie reaktive Netzwerkumgestaltungen zu reduzieren?
  • Beginnen Sie links – bewerten Sie Code-Repositories zu Beginn der Build-Pipeline, um sicherzustellen, dass Sie keine bekannten Schwachstellen in Ihre Anwendungen einbauen. Und stellen Sie sicher, dass Ihre Bewertungs-Tools nachträglich prüfen können, ob neu entdeckte Schwachstellen gemeldet werden.
  • Binden Sie automatisierte Sicherheit über APIs in DevOps-Pipelines ein, um Reibungsverluste zu minimieren und eine maximale Wirkung zu erzielen.
  • Sicherheitsteams sind bereits überlastet, und der enorme weltweite Mangel an Fachkräften verheißt nichts Gutes, wenn man bedenkt, dass immer mehr Schwachstellen aufgedeckt werden, die Cyberrisiken zunehmen und die Tools überladen sind. Trend Micro bietet ein kostenloses Tool zur Bewertung von Schwachstellen an, um Unternehmen zu helfen – so ein gemeinsames Release von NSA, FBI und NCSC.

Die kommenden 12 Monate werden wahrscheinlich noch arbeitsintensiver sein als 2021. Da sich die Bedrohungslandschaft rund um Open Source ständig weiterentwickelt, sollten Sie sich darauf vorbereiten.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

*

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.