Secure Coding: Apache Maven gegen Cache-Poisoning-Attacken rĂĽsten
Dependency-Management-Systeme wie Maven sind immer wieder Ziel von Cache-Poisoning-Angriffen, gegen die nur konsequent umgesetzte Sicherheitspraktiken helfen.
(Bild: erstellt mit Chat-GPT / DALL-E)
- Sven Ruppert
Cache Poisoning ist ein spezifischer Angriffstyp, der auf die Art und Weise abzielt, wie Apache Maven Caches, Pakete und Abhängigkeiten in einem Softwareentwicklungsprozess verwaltet. Bevor man die Details von Cache Poisoning näher betrachten kann, ist es wichtig zu verstehen, wie das Dependency Management mit Maven funktioniert.
Ăśberblick zu Maven und seinen Caches
Apache Maven ist ein weit verbreitetes Build-Management-Tool, das hauptsächlich in Java-Projekten verwendet wird. Maven automatisiert die Verwaltung von Abhängigkeiten, den Build-Prozess und das Deployment von Anwendungen. Beim Verwenden von Maven kommen einige grundlegende Mechanismen zum Einsatz, die es notwendig machen, dass sich Entwicklerinnen und Entwickler Gedanken über die Sicherheit von Repositories und Abhängigkeiten machen.
Maven verwendet zum Verwalten von Bibliotheken und Abhängigkeiten sogenannte Repositories. Dabei sind zwei Arten zu unterscheiden:
Lokal: Eine Kopie aller heruntergeladenen Bibliotheken und Abhängigkeiten wird auf dem lokalen Rechner gespeichert.
Remote: Maven kann auf verschiedene entfernte Repositories zugreifen, beispielsweise das zentrale Maven Repository (Maven Central) oder auch benutzerdefinierte Repositories eines Unternehmens.
Maven speichert alle Abhängigkeiten im lokalen Repository (Cache), nachdem sie von einem entfernten Repository heruntergeladen wurden. Dadurch lassen sich Abhängigkeiten, die mehrfach benötigt werden, schneller laden, da nicht jedes Mal ein erneuter Zugriff auf das entfernte Repository erforderlich wird.
Was ist Cache Poisoning?
Cache Poisoning beschreibt eine Klasse von Angriffen, bei denen es einem Angreifer gelingt, den Cache eines Systems (in diesem Fall Maven Caches) mit manipulierten oder schädlichen Inhalten zu füllen. Dies kann dazu führen, dass legitime Anfragen an den Cache, nicht die korrekten Originaldaten vorfinden, sondern stattdessen die von einem Angreifer eingespeisten Daten erhalten. Im Fall von Maven bezieht sich Cache Poisoning darauf, dass ein Angreifer es schafft, schädliche Artefakte in den Cache eines Entwicklers oder eines Builds zu injizieren, indem er eine Schwachstelle im Maven-Build-Prozess oder in den Repository-Servern ausnutzt.
Das Ziel des Angriffs ist es, schädliche Abhängigkeiten zu liefern, die dann in Softwareprojekte integriert werden. Diese vergifteten Abhängigkeiten können bösartigen Code enthalten, um sensible Daten zu stehlen, die Kontrolle über das System zu übernehmen oder das Projekt zu sabotieren.
Arten von Cache-Poisoning-Attacken auf Maven Caches
Es gibt mehrere Szenarien, wie sich Cache-Poisoning-Angriffe auf Maven-Repositories ausfĂĽhren lassen:
Man-in-the-Middle (MITM) Cache Poisoning
Durch eine Man-in-the-Middle-Attacke kann es einem Angreifer gelingen, den Netzwerkverkehr zwischen dem Entwicklungsrechner und dem entfernten Maven-Repository abzufangen und zu manipulieren. Ist die Kommunikation nicht verschlüsselt, kann ein Angreifer manipulierte Artefakte injizieren und diese in den lokalen Maven-Cache einbringen, sodass die Entwickler weiterhin glauben können, dass sie Abhängigkeiten aus einem vertrauenswürdigen Repository nutzen, während diese tatsächlich manipuliert sind.
Ein solcher Angriff ist insbesondere dann erfolgversprechend, wenn Maven über ungesicherte HTTP-Verbindungen mit den Repositories kommuniziert. Das zentrale Maven-Repository (Maven Central) akzeptiert inzwischen ausschließlich HTTPS, um solche Angriffe zu verhindern, aber es gibt immer noch private oder ältere Repositories, die HTTP verwenden.
Repository-Schwachstellen ausnutzen
Erhält ein Angreifer Zugriff auf das entfernte Repository, kann er beliebige Artefakte hochladen oder dort vorliegende Versionen ersetzen. Dies passiert beispielsweise, wenn das Repository schlecht gesichert ist oder sich eine Schwachstelle im Repository-Management-Tool (wie Sonatype Nexus oder JFrog Artifactory) ausnutzen lässt. In diesem Fall kann der Angreifer Schadsoftware direkt in das Repository einbringen, was dazu führt, dass Entwickler weltweit das manipulierte Artefakt herunterladen und in ihren Maven-Cache speichern.
Dependency Confusion
Ein besonders gefährlicher Angriffsvektor, der in den letzten Jahren große Aufmerksamkeit erregt hat, ist die sogenannte "Dependency Confusion". Dieser Angriff basiert auf der Tatsache, dass viele moderne Softwareprojekte Abhängigkeiten sowohl aus internen, privaten als auch aus öffentlichen Repositories wie Maven Central beziehen. Das Hauptziel eines Dependency-Confusion-Angriffs besteht darin, bösartige Pakete über öffentlich zugängliche Repositories in ein Unternehmen oder Projekt einzuschleusen, das "glaubt", interne oder private Abhängigkeiten zu nutzen.
Grundlagen der Dependency Confusion
Viele Unternehmen und Projekte betreiben interne Maven-Repositories, in denen sie eigene Bibliotheken und Abhängigkeiten speichern, die nicht öffentlich zugänglich sind. Diese internen Bibliotheken können spezifische Funktionalitäten implementieren oder Anpassungen an öffentliche Bibliotheken vornehmen. Entwickler definieren in der Maven-Konfiguration (pom.xml) oft den Namen und die Version der Abhängigkeiten, ohne sich bewusst zu sein, dass Maven bei der Auflösung von Abhängigkeiten eine Priorität festlegt, bei der öffentliche Repositories wie Maven Central gegenüber internen bevorzugt werden – es sei denn, dies wird ausdrücklich anders konfiguriert.
Ein Dependency-Confusion-Angriff nutzt genau diese Prioritätsreihenfolge aus. Der Angreifer veröffentlicht im öffentlichen Maven-Repository ein Paket mit dem gleichen Namen wie eine interne Bibliothek, oft mit einer höheren Versionsnummer als diejenige, die intern verwendet wird. Wenn Maven dann nach dieser Abhängigkeit sucht, bevorzugt es häufig das öffentlich verfügbare Paket, anstatt die private interne Version zu verwenden. Dadurch wird das bösartige Paket heruntergeladen und im Maven-Cache des Entwicklers gespeichert, von wo es bei zukünftigen Builds verwendet wird.
Wie Dependency Confusion entdeckt wurde
Ein Sicherheitsforscher namens Alex Birsan machte diesen Angriff im Jahr 2021 bekannt, als er Demonstrationen durchführte, um zu zeigen, wie einfach es ist, Abhängigkeiten in Projekten großer Technologieunternehmen zu vergiften. Indem er Pakete mit denselben Namen wie die internen Bibliotheken großer Unternehmen wie Apple, Microsoft und Tesla veröffentlichte, konnte er erfolgreich Dependency-Confusion-Angriffe gegen diese Unternehmen durchführen.
Birsan verwendete in seinen Angriffen keine schädlichen Inhalte, sondern lediglich harmlosen Code – nur um zu beweisen, dass das System anfällig war. Er konnte nachweisen, dass in vielen Fällen die Build-Systeme der Unternehmen das bösartige (in seinem Fall harmlose) Paket anstelle der echten internen Bibliothek heruntergeladen und verwendet hatten. Diese Offenlegung stärkte nachhaltig das Bewusstsein in der Sicherheits-Community für die Risiken von Dependency Confusion.
Warum funktioniert Dependency Confusion so effektiv?
Der Erfolg eines Dependency-Confusion-Angriffs liegt in der Standardkonfiguration vieler Build-Systeme und der Art und Weise, wie Maven Abhängigkeiten auflöst. Es gibt mehrere Gründe, warum dieser Angriffsvektor so effektiv ist:
- Automatische Priorisierung öffentlicher Repositories
- Vertrauen in die Versionsnummer
- Fehlende SignaturprĂĽfung
- Vertrauen in externen Code
Typosquatting
Die Angriffstechnik Typosquatting macht sich die Unachtsamkeit von Anwendern zunutze, indem sie auf häufige Tippfehler abzielt, die während der Eingabe von Paketnamen in der Softwareentwicklung, wie zum Beispiel in Maven, auftreten können. Angreifer veröffentlichen Pakete mit ähnlichen oder leicht falsch geschriebenen Namen, die legitimen Bibliotheken nahezu gleichen. Die Details können geringfügige Abweichungen wie fehlende Buchstaben, zusätzliche Zeichen oder alternative Schreibweisen umfassen. Tragen Entwickler versehentlich den falschen Paketnamen in ihre Abhängigkeitsdefinitionen ein oder automatische Tools lösen diese Pakete auf, dann laden sie das bösartige Paket herunter. Typosquatting ist eine der bekanntesten Angriffsmethoden im Zusammenhang mit der Manipulation von Paketmanagern wie Maven, npm, PyPI und anderen, die öffentlich zugängliche Bibliotheken hosten.
Typische Techniken des Typosquatting
Falsch geschriebene Paketnamen: Eine der einfachsten Techniken besteht darin, einen Buchstaben im Namen einer bekannten Bibliothek zu ändern oder hinzuzufügen. Ein Beispiel wäre das Paket com.google.common, das oft verwendet wird. Ein Angreifer könnte ein Paket mit dem Namen com.gooogle.common (mit einem zusätzlichen "o") veröffentlichen, das leicht übersehen wird.
Verschiedene Schreibweisen: Angreifer können auch alternative Schreibweisen von bekannten Bibliotheken oder Namen verwenden. Beispielsweise könnte ein Angreifer ein Paket mit dem Namen com.apache.loggin veröffentlichen, das dem beliebten com.apache.logging ähnlich sieht, aber durch die fehlende Buchstabenkombination von "n" und "g" bei "logging" leicht übersehen wird.
Verwendung von Prä- oder Suffixen: Eine weitere Möglichkeit besteht darin, Präfixe oder Suffixe hinzuzufügen, die die Ähnlichkeit zu legitimen Paketen erhöhen. Ein Angreifer könnte z.B. Pakete wie com.google.common-utils oder com.google.commonx veröffentlichen, die dem legitimen Paket com.google.common ähneln.
Ähnlichkeit in der Namensgebung: Angreifer können sich auch die Konventionen der Namensgebung in der Open-Source-Community zunutze machen, indem sie Pakete veröffentlichen, die allgemeine Begriffe oder Abkürzungen enthalten, die oft in Kombination mit anderen Bibliotheken verwendet werden. Ein Beispiel wäre die Veröffentlichung eines Pakets wie common-lang3-utils, das an die beliebte Apache-Commons-Bibliothek commons-lang3 erinnert.
Gefahren von Typosquatting
Die Bedrohung durch Typosquatting ist besonders gravierend, da es schwer zu erkennen ist. Entwickler verlassen sich oft darauf, dass Build-Tools wie etwa Maven Pakete zuverlässig herunterladen und in ihre Projekte integrieren. Wird ein falscher Paketname eingegeben, bemerken sie möglicherweise nicht sofort, dass sie eine bösartige Abhängigkeit eingebunden haben. Typosquatting ist eine Form des Social Engineering, da es die Fehleranfälligkeit von Menschen ausnutzt.
Ein erfolgreicher Typosquatting-Angriff kann schwerwiegende Folgen nach sich ziehen:
- Datenverlust
- Einschleusen von Schadsoftware
- Vertrauensverlust
Bekanntgewordene Maven-Typosquatting-Fälle
Auch in der Maven-Community gab es Vorfälle von Typosquatting. In einem Fall wurde ein Paket mit dem Namen commons-loggin veröffentlicht, das dem legitimen ApacheCommons-Logging-Paket commons-logging ähnelte. Entwickler, die den Namen des Pakets falsch eingaben, luden das bösartige Paket herunter und integrierten es in ihre Projekte, was zu potenziellen Sicherheitsrisiken führte.
Typosquatting ist eine raffinierte und häufig schwer zu erkennende Angriffsmethode, die auf menschliche Fehler abzielt. Angreifer profitieren von der weit verbreiteten Verwendung von Paketmanagern wie Maven, npm und PyPI, indem sie leicht falsch geschriebene oder ähnlich klingende Pakete veröffentlichen, die bösartigen Code enthalten. Entwickler und Organisationen müssen sich dieser Bedrohung bewusst sein und geeignete Schutzmaßnahmen ergreifen, um sicherzustellen, dass nur legitime und vertrauenswürdige Pakete in ihre Projekte integriert werden.