Trotz bester Bemühungen, Software-Abhängigkeiten zu verfolgen, gibt es immer noch tote Winkel, die zu stummen Sicherheitslücken in Software führen. [...]
Schwachstellen, die durch den Code von Drittanbietern vererbt werden, plagen Anwendungen schon seit Jahren, aber im Zeitalter der von Regierungen gesponserten Angriffe auf die Software-Lieferkette ist das Problem aktueller denn je. Tools zur Analyse der Softwarezusammensetzung können dabei helfen, einige dieser Risiken aufzudecken, aber es gibt immer noch subtile Schwachstellen in Abhängigkeiten, die es selbst sicherheitsbewussten Entwicklern schwer machen, alle vererbten Schwachstellen zu erkennen.
Bei einer kürzlichen Überprüfung des NuGet-Repository durch Sicherheitsforscher von ReversingLabs wurden 50.000 Pakete entdeckt, die eine veraltete und anfällige Version einer beliebten Bibliothek namens zlib verwendeten. In vielen dieser Pakete war sie nicht ausdrücklich als Abhängigkeit aufgeführt.
Die Verfolgung von Abhängigkeiten ist nicht immer erfolgreich
Um alle Schwachstellen zu entdecken, müssen Entwickler nicht nur verfolgen, welche Komponenten sie in ihren eigenen Anwendungen verwenden, sondern auch die Bibliotheken und Pakete Dritter, auf denen diese Komponenten basieren. Die Abhängigkeitsketten können viele Schichten tief gehen. Eine 2019 von Forschern der Universität Darmstadt durchgeführte Analyse des npm-Repository ergab, dass der Import eines JavaScript-Pakets im Durchschnitt implizites Vertrauen für 79 andere Pakete von 39 verschiedenen Betreuern einführte. Damals fanden die Forscher auch heraus, dass fast 40 Prozent der Pakete auf Code mit mindestens einer öffentlich bekannten Schwachstelle basierten.
Ein Problem besteht darin, dass nur die Abhängigkeiten, die sich auf Pakete desselben Repositorys beziehen, von den Paket-Repositories und ihren entsprechenden Paketverwaltungswerkzeugen verfolgt werden. Aber das ist nicht der einzige Weg, wie Code von Drittanbietern in die Projekte gelangt. Einige Entwickler verlinken statisch Bibliotheken oder kompilieren manuell Code aus anderen Projekten, die sich außerhalb von Paket-Repositories befinden, und diese Informationen sind mit automatischen Scanning-Tools nicht leicht zu finden.
ReversingLabs fand über 50 NuGet-Pakete, die aktiv ausgenutzte Schwachstellen enthielten, weil sie veraltete und anfällige Versionen von 7Zip, WinSCP und PuTTYgen enthielten. Dabei handelt es sich um beliebte Komprimierungs- oder Netzwerkverbindungsprogramme, die nicht direkt in NuGet gehostet werden, für die aber möglicherweise von anderen Entwicklern erstellte Wrapper-Pakete in NuGet verfügbar sind.
NuGet ist das wichtigste Repository für die .NET-Programmiersprache, und die meisten der dort gehosteten Komponenten werden als ZIP-Archive mit der Erweiterung .nupkg ausgeliefert und enthalten vorkompilierte Windows-.DLL-Bibliotheken, die für den Import in andere Softwareprojekte bestimmt sind.
Ein anfälliges NuGet-Paket, das von ReversingLabs gefunden wurde, heißt WinSCPHelper und ist eine Wrapper-Bibliothek für WinSCP. Sie ermöglicht Anwendungen, die sie integrieren, die Verwaltung von Dateien auf entfernten Servern über das SFTP-Protokoll. WinSCPHelper wurde seit 2017 nicht mehr über NuGet aktualisiert, aber die letzte Version wurde seit ihrer Veröffentlichung über 34.000 Mal heruntergeladen und in den letzten 6 Wochen etwa 700 Mal. Die neueste WinSCP-Version ist 5.17.10 und enthält einen Patch für eine kritische Sicherheitslücke bei der Remotecodeausführung, aber die mit WinSCPHelper gebündelte Version ist viel älter – 5.11.2.
„Während in diesem Fall das analysierte Paket klar angibt, dass es WinSCP verwendet, wird die Version in der Liste der Abhängigkeiten nicht angegeben, und man kann nicht einfach herausfinden, welche Sicherheitslücken die zugrunde liegende Abhängigkeit betreffen“, so die Forscher. „Es handelt sich um manuelle Arbeit, die zwar machbar ist, aber einen gewissen Aufwand erfordert.“
Stille Schwachstellen identifizieren
Aber das Aufspüren von Abhängigkeiten kann sogar noch schwieriger sein als das. Nehmen wir den Fall von zlib, einer der am weitesten verbreiteten Open-Source-Bibliotheken zur Datenkomprimierung, die ursprünglich im Jahr 1995 geschrieben wurde. Diese Bibliothek hat sich fast zu einem De-facto-Standard entwickelt und wird von ihren Betreuern als Quellcode zur Verfügung gestellt. Das bedeutet, dass Entwickler dazu neigen, sie selbst zu kompilieren und statisch in ihren Projekten zu verlinken, oft ohne ihre Präsenz zu erwähnen, da sie so allgegenwärtig ist.
Durch die Analyse statischer Dateien hat ReversingLabs über 50.000 NuGet-Pakete identifiziert, die zlib in der Version 1.2.8 verwenden, die 2013 veröffentlicht wurde und vier Sicherheitslücken von hohem oder kritischem Schweregrad enthält. Einige der identifizierten Pakete haben diese alte zlib-Version und ihre Schwachstellen durch andere Komponenten von Drittanbietern geerbt, die nicht eindeutig als Abhängigkeiten aufgelistet sind, was die Forscher dazu veranlasst, diese als stille Schwachstellen zu bezeichnen.
Ein von ReversingLabs bereitgestelltes Beispiel ist ein NuGet-Paket namens DicomObjects, das das DICOM-Protokoll (Digital Imaging and Communications in Medicine) implementiert. DICOM ist ein Standard für die Übertragung und Verwaltung von medizinischen Bilddaten. Er ist in Krankenhäusern weit verbreitet und wird von vielen bildgebenden Geräten wie medizinischen Scannern, Druckern, Servern und Workstations unterstützt.
DicomObjects, das von Entwicklern von Software für das Gesundheitswesen zur einfachen Erstellung von DICOM-Lösungen verwendet wird, wurde bereits fast 54.000 Mal heruntergeladen und wird von dem britischen Unternehmen Medical Connections verwaltet. Das Paket führt Microsoft.AspNet.WebApi.Client, Newtonsoft.Json und System.Net.Http als Abhängigkeiten auf, bündelt aber laut ReversingLabs auch eine kommerzielle PDF-Bibliothek namens ceTe.DynamicPDF.Viewer.40.x86.dll, die nirgends explizit erwähnt wird. DynamicPDF Viewer ist bei NuGet als separates Paket aufgeführt, aber die in DicomObjects gebündelte Version ist eine viel ältere, die zlib 1.2.8 enthält.
„Dies ist eines der häufigsten Probleme bei der Softwarepflege„, so die Forscher. „Die Entwickler erstellen ein Softwarepaket, entscheiden sich für die Verwendung von Software von Drittanbietern, aber bei späteren Updates werden die Abhängigkeiten übersehen. In diesem Fall ist es noch schlimmer, weil nirgends explizit erwähnt wird, dass das DicomObjects-Paket von DynamicPDF.Viewer abhängt. Es gibt keine Möglichkeit zu erkennen, dass DynamicPDF.Viewer von der verwundbaren zlib-Bibliothek abhängt. Das Stapeln von versteckten Abhängigkeiten auf diese Weise führt zu mehreren Ebenen von stillen Schwachstellen und erschwert die Wartung und Überprüfung der Software erheblich.“
Medical Connections reagierte nicht sofort auf eine Bitte um Stellungnahme.
Ein weiteres Beispiel ist ein sehr beliebtes Paket namens librdkafka.redist, eine C-Bibliothek, die das Apache Kafka-Protokoll implementiert. Apache Kafka ist ein Open-Source-Hochleistungs-Framework für die Verarbeitung von Echtzeit-Datenströmen. Das Paket librdkafka.redist wurde 18,9 Millionen Mal heruntergeladen, davon 312.000 Mal in der neuesten Version 1.7.0, die vor 2 Monaten veröffentlicht wurde. Diese Version von librdkafka.redist verwendet zlib 1.2.8, was aber weder in der Abhängigkeitsliste des Projekts auf NuGet noch auf GitHub explizit angegeben ist.
Das Problem wurde vor über einem Jahr im Bug-Tracker des Projekts auf GitHub gemeldet und ist derzeit zur Behebung in Version 1.8.0 vorgesehen. Der leitende Entwickler des Projekts, Magnus Edenhill, überprüfte die vier zlib-Schwachstellen und sagte, dass nur zwei davon auf librdkafka zutreffen und dass das Risiko, sie durch von Kafka konsumierte Nachrichten erfolgreich auszunutzen, sehr gering erscheint. Edenhill reagierte nicht sofort auf eine Anfrage nach einem Kommentar.
Dreizehn weitere NuGet-Pakete hängen von librdkafka.redist ab, darunter einige, die von einem Dateninfrastrukturunternehmen namens Confluent entwickelt wurden, das viele große Unternehmenskunden hat.
„Sichere Softwareentwicklung ist ein komplexes Problem, da sie viele Beteiligte über mehrere Entwicklungsstufen hinweg einbezieht“, so die Forscher von ReversingLabs. „Unabhängig davon, welche Art von Software Ihr Unternehmen herstellt, wird es eher früher als später notwendig sein, Abhängigkeiten von Dritten in Ihre Lösung zu integrieren. Dies wird dazu führen, dass Sicherheits– und Codequalitätsrisiken verwaltet werden müssen. Angriffe auf die Software-Lieferkette stellen eine wachsende Bedrohung für die Cyber-Community dar. Sie sind das DDoS-Pendant zu den traditionellen Sicherheitsverletzungen.
Risiken in der Lieferkette
NuGet ist nicht das einzige Paket-Repository, in dem dieses Problem der anfälligen Abhängigkeiten besteht, und man könnte argumentieren, dass es nicht an NuGet oder anderen Repositories liegt, Entwickler zu zwingen, diesen Problemen mehr Aufmerksamkeit zu schenken. Einige Plattformen sind jedoch proaktiver als andere. GitHub scannt aktiv die öffentlichen Code-Repositorys, die auf seiner Plattform gehostet werden, analysiert ihre Abhängigkeiten und benachrichtigt ihre Besitzer, wenn eine dieser Abhängigkeiten bekannte Schwachstellen aufweist. Das Unternehmen unterhält eine öffentliche Advisory-Datenbank mit bekannten Schwachstellen in npm (JavaScript), RubyGems (Ruby), NuGet (.NET), pip (Python), Maven (Java) und kündigte gerade Unterstützung für Go-Module an.
In seinem 2020 Software Supply Chain Report stellte das Open-Source-Governance-Unternehmen Sonatype einen Anstieg von 430 % gegenüber dem Vorjahr bei der Zahl der Angriffe der nächsten Generation fest, bei denen Hacker versuchten, aktiv Schadsoftware in Open-Source-Softwareprojekte einzuschleusen, um weitere Projekte und Anwendungen in der höheren Abhängigkeitskette zu vergiften. Traditionelle Angriffe, bei denen Hacker bekannte Schwachstellen in Open-Source-Komponenten ausnutzen, sind nach wie vor stark, aber die Zeit bis zur Ausnutzung hat sich verringert, da Angreifer neu entdeckte Schwachstellen innerhalb weniger Tage nach ihrer Veröffentlichung ausnutzen. Inzwischen braucht die Hälfte der Unternehmen mehr als eine Woche, um von solchen Schwachstellen zu erfahren, und danach eine Woche oder länger, um Abhilfemaßnahmen zu ergreifen.
Angreifer sind eindeutig daran interessiert, die Software-Lieferkette auszunutzen, doch Tausende von Softwarepaketen mit vererbten Schwachstellen befinden sich noch immer in öffentlichen Repositories und dienen als Grundbausteine für Unternehmenssoftware.
*Lucian Constantin ist Senior-Autor bei CSO und berichtet über Informationssicherheit, Privatsphäre und Datenschutz.
Be the first to comment