Im Laufe der Softwareentwicklung im Lebenszyklus der Softwarelieferkette wird die Paketphase zu einem entscheidenden Wendepunkt, da hier Quellcode in ausführbare Artefakte umgewandelt wird, die für die Verteilung vorbereitet sind. Diese kritische Phase ist jedoch nicht immun gegen Schwachstellen und daher ein Hauptziel für böswillige Akteure, die die Integrität und Sicherheit der Software untergraben möchten. Dieser Blogbeitrag befasst sich mit den häufigsten Bedrohungen, die in dieser Phase auftreten können, und skizziert wirksame Strategien zu deren Eindämmung. Dieser Inhalt ist die Fortsetzung unserer Blogserie über software supply chain security über den SDLC.
Die Paketphase im Softwareentwicklungslebenszyklus
Die Paketphase im Lebenszyklus der Softwarelieferkette umfasst den Prozess des Verpackens und Vorbereitens der Software für die Verteilung an Benutzer. In dieser Phase werden Installationspakete erstellt, Abhängigkeiten verwaltet und Metadaten für die Software generiert.
Bedrohungen der Buildintegrität sind Schwachstellen, die es Angreifern ermöglichen könnten, während des Paketierungsprozesses nicht autorisierte Änderungen an der Software vorzunehmen. Diese Bedrohungen können auf verschiedene Weise eingeführt werden, z. B. durch die Kompromittierung der Paketregistrierung, das Ausnutzen von Schwachstellen in Paketierungstools oder das Manipulieren von Abhängigkeiten von Drittanbietern.
Die völlige Abhängigkeit von Open-Source-Komponenten in moderner Software machte diese Phase zur häufigsten SSCA Ziel. Die Einführung von Stealth-Malware in eine beliebte Open-Source-Komponente ist für viele Cyberkriminelle ein Traum. Deshalb Im Jahr 245,000 wurden 2023 bösartige Pakete gefunden.
Beispiele Software Supply Chain Security Bedrohungen in der Paketphase
Kompromittiertes Paket verwenden
Dies bezieht sich auf die Bereitstellung oder Verwendung eines Softwarepakets, das von einem Angreifer manipuliert oder geändert wurde.
Dies kann passieren, nachdem das Paket das offizielle Paketregister verlassen hat, entweder durch direkten Zugriff auf das System des Benutzers oder durch Social-Engineering-Taktiken, die den Benutzer dazu verleiten, ein bösartiges Paket herunterzuladen oder zu installieren. Ein Beispiel für diesen Vektor war der Browserify Typosquatting Angriff.
Ein Angreifer, der Linux- und Mac-Systeme kompromittieren wollte, drang in den Entwicklungsprozess einer beliebten Node.js-Bibliothek namens Browserify ein. Der Angreifer schleuste Schadcode in den Quellcode des Projekts ein und beabsichtigte, ihn über das NPM-Paketregister zu verteilen. Nachdem das infizierte Browserify-Paket in das NPM-Paket hochgeladen worden war, luden es ahnungslose Entwickler herunter und installierten es, weil sie glaubten, es handele sich um die legitime Version. Der im Paket eingebettete Schadcode wurde unbemerkt ausgeführt und gefährdete die Integrität der von ihm infizierten Systeme. Dies könnte zu Datendiebstahl, Systeminstabilität oder sogar Fernzugriff für den Angreifer führen.
Kompromittierung der Paketregistrierung
Bei einem kompromittierten Paketregister handelt es sich um ein Software-Repository, das von einem Angreifer infiltriert wurde, der sich unbefugten Zugriff auf die Verwaltungsschnittstelle oder Infrastruktur des Registers verschafft hat.
Auf diese Weise kann der Angreifer legitime Softwarepakete ändern oder durch bösartige ersetzen, die dann an ahnungslose Benutzer verteilt werden können. Ein Beispiel für diese Art von Bedrohung war die Angriff auf Paketspiegel: Ein Forscher hat mit der Absicht, Open-Source-Software zu fördern, mehrere beliebte Paketregister kompromittiert, darunter Maven Central, NPM und RubyGems. Durch den Zugriff auf diese Register konnte der Forscher Spiegel und Replikate der ursprünglichen Repositories erstellen, die Entwicklern eine bequeme Alternative zum Herunterladen von Paketen boten.
Diese Spiegel dienten jedoch einem finsteren Zweck. Die kompromittierten Spiegel dienten den Forschern als Kanäle zur Verbreitung bösartiger Pakete. Diese Pakete ersetzten legitime Pakete, ohne von den primären Registern erkannt zu werden, und ahnungslose Entwickler luden sie unwissentlich herunter und installierten sie. Nach der Installation setzten diese bösartigen Pakete ihre Nutzlast frei, führten beliebigen Code aus, stahlen vertrauliche Daten oder störten den Betrieb.
Geändertes Paket hochladen
Ein Angreifer lädt ein geändertes Paket in ein Repository oder einen Verteilungskanal hoch, das schädlichen Code oder Nutzdaten enthält. Dies kann durch die Änderung des Quellcodes, der Verpackung oder der Metadaten des Pakets erfolgen.
Eine der berüchtigtsten Bedrohungen dieser Art war die CodeCov-Angriff im Jahr 2021. Ein Angreifer, der versucht, Softwareprojekte mithilfe von CodeCov, einer beliebten Methode zur kontinuierlichen Integration und Bereitstellung (CI/CD) nutzte geleakte Anmeldeinformationen, um sich unbefugten Zugriff auf den Google Cloud Storage (GCS)-Bucket eines Projekts zu verschaffen. Sobald der Angreifer Zugriff auf den GCS-Bucket erlangt hatte, lud er ein schädliches Artefakt hoch, eine modifizierte Version des CodeCov-Pakets, das dann über den CodeCov-Dienst an Benutzer verteilt wurde. Ahnungslose Entwickler, die sich auf die automatische Update-Funktion verließen, luden das schädliche Paket herunter und installierten es im Glauben, es sei legitim. Nach der Installation wurde der Schadcode unbemerkt ausgeführt und gefährdete die Integrität der infizierten Systeme. Dies konnte zu Datendiebstahl, Systeminstabilität oder sogar Fernzugriff für den Angreifer führen.
Angriffe auf die Paketregister sind so weit verbreitet, dass einige Angriffsmuster einen Namen erhalten haben:
In Tippfehler, lädt der böswillige Akteur mehrere bösartige Pakete mit leichten Tippfehlern oder ähnlichen Namen wie legitime, beliebte Pakete in das Register hoch, in der Hoffnung, dass die Entwickler den beabsichtigten Paketnamen durch einen bösartigen verwechseln. Oftmals tarnt sich das bösartige Paket als das legitime, um unentdeckt zu bleiben, was die Wahrscheinlichkeit erhöht, Opfer von Stargazing zu werden.
Abhängigkeitsverwirrung nutzt die Art und Weise, wie einige Paketmanager die angeforderten Pakete aus mehreren Registern auflösen. Wenn eine Organisation interne Komponenten verwendet, die in einem internen Register veröffentlicht sind, kann ein Angreifer, der dies weiß, eine bösartige Komponente mit demselben Namen in einem öffentlichen Register veröffentlichen. Wenn der für die interne Komponente verwendete Name nicht gültig ist, holen einige Paketmanager die bösartige Komponente anstelle der internen ab.
Mit Trojan-Pakete, versteckt der Cyberkriminelle Malware unter nützlichem gültigen Code. Dies könnte vom tatsächlichen Autor oder von einem Mitwirkenden verwendet werden, der sich anbietet, das Paket zu pflegen. Dies wird auch als Paket-HijackingAngreifer verwendeten viele Techniken, um ein bestehendes Paket zu kapern, wie Domainübernahme wo der Angreifer eine verlassene, abgelaufene Domäne übernahm, die alte E-Mail des Betreuers neu erstellte und eine Kennwortwiederherstellung durchführte, um das Betreuerkonto zu übernehmen.
Schlussbemerkungen
Da Unternehmen zunehmend Softwareentwicklungsmethoden anwenden, bei denen Automatisierung und kontinuierliche Bereitstellung im Vordergrund stehen, war die Absicherung der Softwarepaketphase noch nie so wichtig. Durch die Implementierung robuster Sicherheitsmaßnahmen in dieser kritischen Phase können Unternehmen das Risiko böswilliger Angriffe, die die Integrität und Sicherheit ihrer Software gefährden können, erheblich verringern.
Die in diesem Blogbeitrag beschriebenen Strategien und die angeführten Beispiele erinnern deutlich daran, dass die Paketphase einen Schwachpunkt in der Softwarelieferkette darstellt. Unternehmen müssen diese Bedrohungen beachten und die erforderlichen Sicherheitsmaßnahmen ergreifen, um ihre Software vor Angriffen zu schützen. Auf diese Weise können sie die Integrität, Sicherheit und Zuverlässigkeit ihrer Software für ihre Benutzer und Kunden gewährleisten.
Begleiten Sie uns auf unserem Weg zu einem sicheren Software-Ökosystem
Verpassen Sie nicht die Chance, immer einen Schritt voraus zu sein im Bereich der software supply chain security. Abonnieren Sie noch heute unseren Blog und seien Sie einer der Ersten, die unsere neuesten Erkenntnisse erhalten, damit Ihr Unternehmen trotz sich entwickelnder Bedrohungen widerstandsfähig und sicher bleibt. Gemeinsam können wir ein robusteres und sichereres Software-Ökosystem für alle aufbauen.
Denken Sie daran, software supply chain security ist eine fortlaufende Reise, kein Ziel. Durch die kontinuierliche Bewertung und Anpassung von Sicherheitspraktiken zur Bewältigung neuer Bedrohungen können Unternehmen ihre Softwarelieferkette schützen und ihren Benutzern vertrauenswürdige Software bereitstellen.
Sehen Sie sich unsere Video-Demo an
