Analysieren und Beheben der Git-Schwachstelle CVE-2024-32002

Dez 17, 2024 von OPSWAT

Jetzt teilen

Minh Pham und Thai Do, Studenten der Technischen Universität Ho Chi Minh, die am OPSWAT teilnahmen — Studenten nahmen am OPSWAT Fellowship-Programm teil.

Vor kurzem wurde eine kritische Sicherheitslücke in Git bekannt, die RCE-Angriffe (Remotecodeausführung) ermöglicht und mehrere Versionen von Git und Microsoft Visual Studio 2017 betrifft. Die Schwachstelle ermöglicht es Angreifern, Git-Repositorys mithilfe von Submodulen zu manipulieren, indem sie einen Fehler in Git ausnutzen, der es ermöglicht, Dateien außerhalb des Arbeitsbaums des Submoduls und in das Verzeichnis .git/ zu schreiben. Dieser Fehler ermöglicht die Ausführung eines bösartigen Hooks, während ein Repository-Klonvorgang noch läuft [1].

Die Sicherheitslücke CVE-2024-32002 betrifft Microsoft Visual Studio 2017 Version 15.9 und Git-Versionen vor 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2 und 2.39.4. Er kann in Umgebungen ausgenutzt werden, in denen die Unterstützung für symbolische Links auf Betriebssystemen, die Groß- und Kleinschreibung nicht berücksichtigen, aktiviert ist.

CVSS (Common Vulnerability Scoring System) 3.x Schweregrad- und Vektorinformationen mit einem Basiswert von 9,0, der als kritisch eingestuft wird, bereitgestellt von GitHub, Inc.

Git verstehen

Git ist ein freies und quelloffenes, verteiltes Versionskontrollsystem, das Softwareentwicklern helfen soll, ihre Codebasen schnell und effizient zu verwalten. Es verbessert die Zusammenarbeit zwischen den Mitgliedern des Entwicklungsteams, indem es Änderungen an Dateien und Verzeichnissen auf eine standardisierte, strukturierte Weise organisiert und verfolgt.

Git ist in der Softwareentwicklung weit verbreitet. Plattformen wie GitHub, GitLab und Bitbucket bauen auf Git auf, um die Zusammenarbeit zwischen Entwicklern aufgrund seiner leistungsstarken Funktionen zu verbessern:

Aufzeichnung nachvollziehbarer Änderungen an Codedateien, so genannter Commits.
Rückgängigmachung von Code-Bearbeitungen auf frühere Versionen, falls erforderlich.
Effizientes Kombinieren von Änderungen aus verschiedenen Zweigen oder von verschiedenen Mitwirkenden.
Aufzeichnung der Historie, wer welche Änderungen vorgenommen hat und wann diese erfolgt sind.

Eine visuelle Darstellung einer .git-Ordnerstruktur, die Verzeichnisse wie config, HEAD, hooks, objects und refs anzeigt.

Git-Haken

Wenn ein Git-Repository mit den Befehlen git init oder git clone erstellt oder geklont wird, wird ein .git-Verzeichnisan der Wurzel des Arbeitsbaums erzeugt. Die Verzeichnisstruktur des .git-Verzeichnisses sieht zunächst wie folgt aus:

Die Git-Hooks sind ausführbare Skripte, die sich entweder im Verzeichnis .git/hooks oder im Verzeichnis .git/modules/module_type/module_name/hooks befinden. Hooks werden automatisch ausgelöst, wenn bestimmte Ereignisse in einem Git-Repository auftreten.

Wenn eine Datei im Hooks-Verzeichnis kein Suffix .sample hat, werden die Befehle in dieser Datei vor oder nach einer bestimmten Git-Aktion ausgeführt, die im Dateinamen enthalten ist, z. B. pre-commit, post-commit und post-checkout.

Git-Untermodule

Ein Git-Submodul ist ein Eintrag in einem Git-Repository, der auf eine bestimmte Übertragung in einem externen Repository verweist. Wenn ein Submodul zu einem Repository hinzugefügt wird, wird eine neue Datei im Verzeichnis .gitmodules mit Metadaten für die Zuordnung zwischen der URL des Submoduls und seinem lokalen Verzeichnis erstellt. Wenn ein Repository mehrere Submodule enthält, enthält die .gitmodules-Datei für jedes einen Eintrag. [3]

Diagramm zur Interaktion von Repositories und Submodulen, das die Beziehung zwischen Repository A, Submodul B und Ordner C veranschaulicht

Beispiel für den Inhalt einer .gitmodules-Datei, die die Konfiguration für ein Submodul mit dem Namen "Example" zeigt — Das folgende Bild zeigt, wie eine .gitmodules-Datei aussieht:

Symbolische Verknüpfungen (Symlinks)

Ein symbolischer Link, auch Symlink oder Softlink genannt, ist eine Datei, die durch Angabe ihres Pfades auf eine andere Datei oder ein anderes Verzeichnis (als "Ziel" bezeichnet) verweist. Wenn ein Symlink gelöscht wird, bleibt sein Ziel davon unberührt. [4]

Ein Symlink in Git wird als Datei mit Metadaten erstellt, damit er als Verweis oder Verknüpfung zu einer anderen Datei funktioniert. Symlinks können verwendet werden, um mehrere Verweise auf eine Datei zu erstellen, ohne deren Inhalt zu replizieren.

Diagramm mit symbolischen und harten Links zu einer Datei (Datei A), das zeigt, wie diese Links auf denselben Dateiinhalt zugreifen — Git behandelt symbolische Links als spezielle Dateien, die den Pfad zu der Datei oder dem Verzeichnis speichern, auf die sie verweisen.

Visualisierung von symbolischen Links innerhalb eines Git-Repositorys, Darstellung von Verzeichnis- und Dateistrukturen und deren Symlink-Pfaden — Wenn ein Repository oder ein Zweig, der einen symbolischen Link enthält, geklont oder ausgecheckt wird, wird der in Git gespeicherte Symlink in einen Symlink auf dem lokalen Dateisystem umgewandelt.

Analyse der Sicherheitslücken in GIT

Patch-Analyse

Um ein tieferes Verständnis der Sicherheitsschwachstellen zu erlangen, führen Sicherheitsspezialisten häufig Patch-Analysen durch. Dabei handelt es sich um eine Technik, die hilft, anfällige Funktionen und potenzielle Angriffsvektoren zu identifizieren. Die OPSWAT untersuchten die Änderungen, die in der gepatchten Version vorgenommen wurden, um die Sicherheitslücke CVE-2024-32002 zu schließen, und fanden heraus, dass zwei Dateien aktualisiert wurden, um diese Sicherheitslücke zu schließen.

Eine der aktualisierten Dateien ist die Datei submodule--helper.c, die den Code für das Klonen von Git-Submodulen enthält. Der neue Commit in der gepatchten Version enthält die folgenden zwei:

Hinzufügen der Funktion dir_contains_only_dotgit, um sicherzustellen, dass das Verzeichnis submodules keine .git-Dateien oder -Verzeichnisse enthält.

Code-Änderungen in einer Datei namens submodule-helper.c innerhalb der Git-Schnittstelle, mit 83 Hinzufügungen und keinen Löschungen

Die Funktion clone_submodule() wurde dahingehend geändert, dass sie eine Bedingung enthält, mit der geprüft wird, ob das Submodulverzeichnis existiert und leer ist. Wenn das Verzeichnis nicht leer ist, wird der Klonvorgang abgebrochen.

Detaillierter Codeschnipsel aus einer Git-Übertragung, der eine Funktion hervorhebt, die bei Submodul-Operationen den Verzeichnisinhalt überprüft

Die zweite Aktualisierung in der neuen Übergabe war in der Datei t/t7406-submodule-update.sh, die ein Testskript hinzufügt, um zu überprüfen, ob die Sicherheitslücke behoben wurde.

Erweiterte Code-Änderungen in einer Testdatei T7406-submodule-update.sh, die Testkonfigurationen für Submodulpfade und Symlinks detailliert beschreibt

Von der Analyse zur Verwertung

Workflow-Analyse von Symlinks und Submodulen in Git

Zusätzlich zu den Erkenntnissen aus der Patch-Analyse und der Beschreibung der Sicherheitslücke CVE-2024-32002 untersuchten die OPSWAT den Workflow von Symlinks und Submodulen in Git. Sie untersuchten die Abfolge der Ereignisse, die stattfinden, wenn ein Benutzer ein Repository klont:

Git beginnt mit dem Herunterladen von Dateien und Verzeichnissen aus dem primären Repository.
Es verwendet die in den Symlink-Dateien angegebenen Definitionen, um die entsprechenden Symlinks im lokalen Dateisystem neu zu erstellen.
Wenn der Symlink auf eine vorhandene Datei zeigt, ist der Symlink funktionsfähig; andernfalls bleibt der Symlink funktionslos, bis das Ziel wiederhergestellt ist.
Wenn das Repository mit der Option --recursive geklont wird, klont Git die Submodule (externe Repositories) und legt sie in den in der Datei .gitmodules angegebenen Verzeichnispfaden ab.
Wenn ein Symlink Teil des Submodulpfads ist (z. B. util/module/test, wobei util ein Symlink ist, der auf ein anderes Verzeichnis verweist, wie z. B. symlink_folder), speichert Git den Inhalt des Submoduls in dem tatsächlichen Verzeichnis, auf das der Symlink verweist (z. B. symlink_folder/module/test), während der Zugriff über den ursprünglichen Symlinkpfad möglich ist.

Ein visuelles Flussdiagramm, das die Schritte des Klonens eines Repositorys, des Herunterladens von Dateien und Verzeichnissen, des Wiederherstellens von Symlinks, des Klonens von Submodulen und des Verschiebens in den richtigen Pfad zeigt

Verstehen der Sicherheitslücke CVE-2024-32002 in Git

Erstellen bösartiger Repositories

Die OPSWAT untersuchten die Erstellung bösartiger Repositories auf der Grundlage der Aktualisierungen für die Dateit/t7406-submodule-update.sh und unterteilten diesen Prozess in die folgenden Schritte:

Erstellen eines Repositorys mit einem Post-Checkout-Haken

Ein Terminal-Codefragment, das die Befehle zum Einrichten eines Post-Checkout-Hooks in Git zeigt, einschließlich der Erstellung von Verzeichnissen und dem Hinzufügen von Skripten

Erstellen eines weiteren Repositorys, das ein Submodul enthält, das sich im Pfad A/modules/x befindet. Das neue Submodul verweist auf das zuvor erstellte Repository.

Ein Terminal-Codeausschnitt, der das Hinzufügen eines Submoduls zu einem Repository mit Git-Befehlen demonstriert

Erstellen eines symbolischen Links mit dem Namen a, der auf den Ordner .git im Git-Index verweist.

Ein Beispiel für ein Terminal-Skript, das Befehle zum Erstellen und Übertragen einer .git-Datei als Dienstprogramm in einem Repository enthält

Ein Flussdiagramm, das ein Angriffsszenario beschreibt, bei dem ein bösartiges Hook-Repository als Submodul zu einem Haupt-Repository hinzugefügt wird, was zur Ausführung eines Skripts führt — Ein Diagramm, das zeigt, wie ein Angreifer das CVE durch Klonen eines Repositorys ausnutzen kann

Verstehen der Sicherheitslücke

Wenn ein Benutzer ein bösartiges Repository, das im vorherigen Schritt erstellt wurde, mit der Option --recursive klont, wird das bösartige Skript aus dem Post-Checkout-Hook ausgelöst, was dem Angreifer ermöglicht, das Gerät des Benutzers zu kompromittieren.

Diese entfernte Codeausführung tritt auf, weil das Hauptrepository einen symbolischen Link namens a erkennt, der beim Klonen auf das .git-Verzeichnis verweist. Wenn der rekursive Modus aktiviert ist, werden auch Untermodule in das geklonte Repository gezogen. Dieses Repository enthält einen Ordner "hooks", der das Hook-Skript nach dem Auschecken enthält, und sein lokales Verzeichnis befindet sich in A/modules/x.

Da a auf das Verzeichnis.git verweist und das Dateisystem Groß- und Kleinschreibung nicht berücksichtigt, wird A als Äquivalent zu a interpretiert. Git wird dazu verleitet, das Post-Checkout-Hook-Skript in das Verzeichnis .git/modules/query/fast/hooks/ zu schreiben. Wenn ein Post-Checkout-Hook-Skript im Ordner . git/modules/{module_type}/{module_name}/hooks gefunden wird, wird es ausgelöst, wenn das Hauptrepository mit der Option --recursive geklont wird. Infolgedessen können Angreifer erfolgreich das Gerät des Benutzers kompromittieren, indem sie entfernten Code ausführen.

Ein Diagramm, das die Interaktion des Opfers mit einem bösartigen Repository veranschaulicht, einschließlich Klonen, Ziehen von Untermodulen und unbeabsichtigter Skriptausführung — Ein Diagramm, das den Ablauf des Angriffs zeigt

Simulierte Ausnutzung der Git-Schwachstelle

Auf der Grundlage der bisherigen Erkenntnisse erstellten die OPSWAT ein Haupt-Repository und einen Hook, um die Erstellung eines bösartigen Repositorys zu simulieren:

Es wird empfohlen, Git zunächst so zu konfigurieren, dass die protocol.file immer erlaubt ist, core.symlinks zu aktivieren und den Standardzweignamen auf main zu setzen (um Warnmeldungen zu vermeiden).

Ein Terminal-Schnipsel mit Befehlen zur globalen Konfiguration der Git-Einstellungen für die Behandlung von Symlinks und die Einrichtung von Standardzweigen

Ein bösartiges Post-Checkout-Hook-Skript wird dem Verzeichnis hooks hinzugefügt. Um sicherzustellen, dass das Post-Checkout-Skript auf dem Gerät des Benutzers ausgeführt werden kann, enthält das Bash-Skript, das diesen Hook erstellt, den Befehl chmod +x fast/hooks/post-checkout.

Ein Terminal-Skript, das einen bösartigen verschlüsselten Python-Befehl anzeigt, der in einen Git-Post-Checkout-Hook eingebettet ist

Im Haupt-Repository wird ein symbolischer Link erstellt, der auf das .git-Verzeichnis verweist.

Ein Terminal-Skript, das den Prozess der Übergabe von Änderungen an Include-Utilities und eine .git-Datei im Repository demonstriert

Ein Screenshot eines Repository-Verzeichnisses mit Ordnern wie src, libs und .gitmodules, die in einer Git-Oberfläche angezeigt werden — Das verwundbare Haupt-Repository

Bildschirmbild einer Git-Repository-Schnittstelle mit einem Verzeichnis und einem Post-Checkout-Hook — Der Ordner */hooks* mit einem Post-Checkout-Haken

Screenshot mit Terminalbefehlen zum Klonen eines Git-Repositorys und einer PowerShell-Sitzung bei bestehender Netzwerkverbindung — Wenn der Benutzer dieses bösartige Repository klont, kann der Angreifer das Gerät des Opfers gefährden.

Sanierung

Um die Bedrohung zu neutralisieren, können Benutzer Git deinstallieren oder den neuesten Sicherheitspatch anwenden. Alternativ kann eine Lösung wie MetaDefender Endpoint den Benutzer sofort benachrichtigen und alle bekannten CVEs innerhalb der Umgebung über seine intuitive Schnittstelle anzeigen. MetaDefender Endpoint kann die neuesten CVEs erkennen und entschärfen, indem es seine Fähigkeiten mit über 3 Millionen Datenpunkten und über 30.000 assoziierten CVEs mit Schweregradinformationen nutzt. Durch die Implementierung einer der beiden Gegenmaßnahmen wird die CVE vollständig eingedämmt, wodurch das Risiko eines verheerenden Cyberangriffs eliminiert wird.

Sind Sie bereit, MetaDefender Endpoint an die vorderste Front Ihrer Cybersecurity-Strategie zu stellen?

Sprechen Sie mit einem Experten