Verseuchte Open-Source-Pakete explodieren

Einem Bericht des Software-Supply-Chain-Management-Unternehmens Sonatype zufolge dringt MalwareMalware alarmierend schnell in das Ökosystem der Open-Source-Softwareentwicklung ein. So hat das Unternehmen seit November 2023 über 500.000 neue bösartige Pakete in den beliebten Java-, JavaScript-, Python- und .NET-Paket-Registries erfasst. Alles zu Malware auf CIO.de

Neue bösartige Komponenten machen mehr als 70 Prozent der rund 700.000 Malware-Pakete aus, die das Unternehmen seit 2019 verfolgt hat. Damals begann der Anbieter, diese Statistik in seinen jährlichen State of the Software Supply Chain Report aufzunehmen.

Sonatype zufolge enthält jede Unternehmensanwendung im Durchschnitt mindestens 180 Komponenten von Drittanbietern. Das macht deren Verwaltung schwierig.

Im Schnitt ein Jahr ungepatcht

Das Unternehmen fand heraus, dass über 80 Prozent der anfälligen Anwendungsabhängigkeiten länger als ein Jahr ungepatcht bleiben, obwohl für 95 Prozent sicherere Alternativen verfügbar sind. Selbst wenn Updates eingespielt werden, werden in 3,6 Prozent der Fälle gefährdete Abhängigkeiten auf andere, unsichere Versionen aktualisiert.

Nehmen wir zum Beispiel Log4j. Die Protokollierungsbibliothek für Java, die in Millionen von Anwendungen verwendet wird, wies im Dezember 2021 eine kritische Sicherheitslücke auf, die auf den Namen "Log4Shell" getauft wurde. Diese Lücke und einige andere, die kurz darauf folgten, machten zwar viele Schlagzeilen, aber fast drei Jahre später sind immer noch 13 Prozent der Log4j-Downloads aus dem Maven Central Java Repository für anfällige Versionen vorhanden.

"Das Management von Open-Source-Risiken erfordert die Optimierung von Sicherheitsrichtlinien und -praktiken, um mit der rasanten Entwicklung neuer OSS-Bibliotheken Schritt zu halten", schreibt Sonatype in seinem Bericht. Unternehmen kämpften damit, DevOps-Prozesse für manuelle Schwachstellenprüfungen langsamer machen zu müssen. Das frustriere die Entwicklungsteams.

Malware-Risiko für Lieferketten

Wie Malware, die auf Desktop-Computer abzielt, können auch bösartige Komponenten, die in Open-Source-Paket-Repositories hochgeladen werden, unterschiedlichen Zwecken dienen. Nicht alle haben dieselben Auswirkungen.

Sonatype katalogisiert fast die Hälfte aller bösartigen Komponenten als "potenziell unerwünschte Anwendungen" (PUAs). Diese sind in der Praxis meist harmlos, besitzen aber Funktionen, die die User nicht kennen.

Weitere 12 Prozent sind als "SecuritySecurity Holding Packages" gekennzeichnet. Sie wurden von den Betreuern des Ökosystems irgendwann als bösartig eingestuft und durch ein sauberes Platzhalter-Paket ersetzt, um die Benutzer darauf aufmerksam zu machen. Alles zu Security auf CIO.de

Der Rest hat schwerwiegende Folgen, die die Lieferkette gefährden können. Etwa 14 Prozent der Pakete werden durch Phishing-Techniken verbreitet. Sie nutzen Verwirrung bezüglich Abhängigkeiten, um sich als interne Pakete von Unternehmen auszugeben. Das Ziel: weitere Malware auf Entwicklungssystemen ablegen.

Etwa 14 Prozent der bösartigen Pakete sind darauf ausgelegt, sensible Dateien und Daten von Rechnern zu stehlen. Dazu zählen etwa Umgebungsvariablen, Authentifizierungs-Token, Kennwortdateien und andere Informationen, die den Angreifern helfen könnten, später weitere Systeme zu kompromittieren. Eine Untergruppe von 3 Prozent der Pakete zielt auch auf persönlich identifizierbare Informationen (PII) ab. Weitere 3 Prozent installieren Backdoors und Trojaner auf Rechnern.

Zu den anderen Arten bösartiger Aktionen gehören:

• Programme zum Schürfen von Kryptowährungen einzuschleusen (1,2 Prozent)

• Dateisysteme zu beschädigen oder

• IDE-Tools zu kompromittieren, die Entwickler zum Schreiben von Code oder für Plattformen zur kontinuierlichen Integration verwenden.

Einige aktuelle Beispiele für Vorfälle mit unerwünschten Paketen: Ein Entwickler lud rund 14.000 gefälschte Pakete auf NPM hoch, um von einem Kryptowährungsprogramm zu profitieren, das Beiträge zu Open SourceOpen Source belohnte. Angreifer verwendeten Typosquatting, um ein Python-Paket mit einem Namen zu verbreiten, der einer beliebten Bibliothek sehr ähnlich war, die den Lumma-Windows-Stealer einsetzte. Ein jahrelanger Infiltrationsangriff auf ein legitimes Projekt über die ZX Utils-Backdoor, bei der ein bösartiger Entwickler den Code vergiften wollte. Alles zu Open Source auf CIO.de

"Herkömmliche Malware-Scan-Lösungen sind nicht in der Lage, diese neuartigen Angriffsformen zu erkennen, was dazu führt, dass Entwickler und DevOps-Umgebungen einem besonderen Risiko ausgesetzt sind", schreiben die Sonatype-Forscher. "Da das Volumen weiter zunimmt, wird auch die klare und gegenwärtige Gefahr für Unternehmen steigen."

Einige Schwachstelleninformationen sind unzuverlässig

Sonatype fand heraus, dass jede Unternehmensanwendung jedes Jahr im Durchschnitt 13 kritische oder hochgefährliche Schwachstellen aufweist, die aus Abhängigkeiten übernommen werden.

Es werden nicht nur automatisierte Tools benötigt, die alle direkten und transitiven Abhängigkeiten - Abhängigkeiten von Abhängigkeiten - zusammen mit den in ihnen entdeckten Schwachstellen verfolgen können. Auch die Quellen der Schwachstelleninformationen sind nicht gleich.

Die National Vulnerability Database (NVD) zum Beispiel hat einen Rückstand von über 17.000 Schwachstellen, die noch nicht bearbeitet wurden. Sonatype hat festgestellt, dass mehr als zwei Drittel der Schwachstellen, die ursprünglich mit einem CVSS-Schweregrad von unter 7 (mittel) eingestuft wurden, bei einer genaueren Überprüfung durch einen Sicherheitsforscher auf über 7 (hoch oder kritisch) korrigiert wurden.

Je nachdem, aus welcher Quelle die Informationen über Schwachstellen stammen, kann es vorkommen, dass Unternehmen Schwachstellen ganz übersehen. Sie könne auch beschließen, sie erst später zu beheben, weil sie sie für weniger kritisch halten, als sie tatsächlich sind. Wenn sich die Schwere einer Schwachstelle ändert, nachdem eine Anwendung bewertet wurde, ist es schwer zu sagen, wie lange es dauert, bis sie erneut gescannt wird.

"Das anhaltende Risiko lässt sich verringern, indem man sich auf Tools konzentriert, die bei der Verwaltung von Abhängigkeiten und der Erkennung von Sicherheitslücken in Echtzeit helfen", schreiben die Forscher. "In der Tat haben wir festgestellt, dass Projekte, die eine Software Bill of Materials (SBOM) zur Verwaltung von OSS-Abhängigkeiten verwenden, eine um 264 Tage kürzere Zeitspanne für die Behebung von Schwachstellen aufwiesen als Projekte, die dies nicht taten."

Die zunehmende Verbreitung von SBOM-Standards und staatliche Vorschriften, die diese stark fördern, haben immer mehr Open-Source-Entwickler dazu veranlasst, sie zu übernehmen. Leider werden schneller neue Komponenten veröffentlicht als die Standards übernommen. In den letzten 12 Monaten wurden fast 7 Millionen neue Open-Source-Komponenten veröffentlicht, von denen nur 61.000 SBOMs enthielten.

Ein beunruhigender Trend ist die zunehmende durchschnittliche Zeit, um Sicherheitslücken zu beheben, unabhängig vom Schweregrad:

Bei kritischen Schwachstellen lag die durchschnittliche Behebungszeit früher zwischen 200 und 250 Tagen, heute beträgt sie in einigen Fällen über 500 Tage.

Bei Schwachstellen mit hohem Schweregrad hat sich die Zeit bis zur Behebung von 150 bis 300 Tagen auf mehr als 400 Tage verlängert.

Bei Schwachstellen mit niedrigem Schweregrad beträgt die Zeit bis zur Behebung 500 bis 700 Tage, in einigen Fällen sogar bis zu 800 Tage.

"Dieser starke Anstieg deutet darauf hin, dass die Herausgeber überfordert sind und damit kämpfen, sowohl mit der Menge der Sicherheitsprobleme als auch mit den ständigen Anforderungen an Innovation und Funktionsentwicklung Schritt zu halten", so die Forscher.