Einem neuen Bericht des Software program-Provide-Chain-Administration-Unternehmens Sonatype zufolge dringt Malware alarmierend schnell in das Ökosystem der Open-Supply-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.
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 program Provide 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 quick 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 Administration von Open-Supply-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-Pc abzielt, können auch bösartige Komponenten, die in Open-Supply-Paket-Repositories hochgeladen werden, unterschiedlichen Zwecken dienen. Nicht alle haben dieselben Auswirkungen.
Sonatype katalogisiert quick 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 Consumer nicht kennen.
Weitere 12 Prozent sind als „Safety 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.
Der Relaxation 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, smart 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-Instruments 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 Supply belohnte. Angreifer verwendeten Typosquatting, um ein Python-Paket mit einem Namen zu verbreiten, der einer beliebten Bibliothek sehr ähnlich battle, die den Lumma-Home 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.
„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 Instruments 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 Nationwide 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 Instruments 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 program Invoice of Supplies (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-Requirements und staatliche Vorschriften, die diese stark fördern, haben immer mehr Open-Supply-Entwickler dazu veranlasst, sie zu übernehmen. Leider werden schneller neue Komponenten veröffentlicht als die Requirements übernommen. In den letzten 12 Monaten wurden quick 7 Millionen neue Open-Supply-Komponenten veröffentlicht, von denen nur 61.000 SBOMs enthielten.
Ein beunruhigender Development 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. (jd)
