Kürzlich wurde eine kritische Sicherheitslücke in Git bekannt gegeben, die RCE-Angriffe (Remote Code Execution) ermöglicht und mehrere Versionen von Git sowie Microsoft Visual Studio 2017 betrifft. Die Sicherheitslücke ermöglicht es Angreifern, Git-Repositorys mithilfe von Submodulen zu manipulieren, indem sie einen Fehler in Git ausnutzen, der es erlaubt, Dateien außerhalb des Arbeitsverzeichnisses des Submoduls 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.
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.
Git-Haken
Wenn ein Git-Repository mit den Befehlen „git init“ oder „git clone“ erstellt oder geklont wird, wird im Stammverzeichnis des Arbeitsverzeichnisses ein Verzeichnis namens „.git“ angelegt. Die Verzeichnisstruktur des Verzeichnisses „.git“ sieht anfangs 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]
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.
Analyse der Sicherheitslücken in GIT
Patch-Analyse
Um ein tieferes Verständnis für Sicherheitslücken zu erlangen, führen Sicherheitsexperten häufig Patch-Analysen durch. Dabei handelt es sich um eine Methode, mit deren Hilfe anfällige Funktionen und potenzielle Angriffsvektoren identifiziert werden können. Die Mitarbeiter von „ OPSWAT “ untersuchten die Änderungen, die in der gepatchten Version zur Behebung der Sicherheitslücke CVE-2024-32002 vorgenommen wurden, und stellten fest, dass zwei Dateien aktualisiert wurden, um diese CVE zu beheben.
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.
- 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.
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.
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.
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
- 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.
- Erstellen eines symbolischen Links mit dem Namen a, der auf den Ordner .git im Git-Index verweist.
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 nicht zwischen Groß- und Kleinschreibung unterscheidet, wird „A“ als gleichbedeutend mit „a“ interpretiert. Git wird dadurch dazu verleitet, das Skript für den „post-checkout“-Hook in das Verzeichnis „.git/modules/query/fast/hooks/“ zu schreiben. Wird ein Post-Checkout-Hook-Skript im Ordner „.git/modules/{module_type}/{module_name}/hooks“ gefunden, wird es ausgelöst, wenn das Haupt-Repository mit der Option „--recursive“ geklont wird. Infolgedessen können Angreifer das Gerät des Benutzers erfolgreich kompromittieren, indem sie Remote-Code ausführen.
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:
- Zunächst wird empfohlen, Git so zu konfigurieren, dass das Protokoll „protocol.file“ stets zugelassen wird, „core.symlinks“ aktiviert ist und der Standardzweig auf „main“ gesetzt wird (um Warnmeldungen zu vermeiden).
- 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.
- Im Haupt-Repository wird ein symbolischer Link erstellt, der auf das .git-Verzeichnis verweist.
Sanierung
Um die Sicherheitslücke zu beheben, können Nutzer Git deinstallieren oder den neuesten Sicherheitspatch installieren. Alternativ kann eine Lösung wie MetaDefender Endpoint den Nutzer umgehend benachrichtigen und über ihre intuitive Benutzeroberfläche alle bekannten CVEs in der Umgebung anzeigen. MetaDefender Endpoint kann die neuesten CVEs erkennen und abwehren, indem es seine Funktionen mit über 3 Millionen Datenpunkten und über 30.000 zugehörigen CVEs mit Schweregradinformationen nutzt. Durch die Umsetzung einer der beiden Gegenmaßnahmen wird die CVE vollständig eingedämmt, wodurch das Risiko eines verheerenden Cyberangriffs beseitigt wird.
Sind Sie bereit, MetaDefender Endpoint an die vorderste Front Ihrer Cybersecurity-Strategie zu stellen?
Referenzen
(1) https://nvd.nist.gov/vuln/detail/CVE-2024-32002
(3) https://www.atlassian.com/git/
(4) Symbolische Verbindung - Wikipedia
(5) https://www.vicarius.io/vsociety/posts/exploiting-git-rce-cve-2024-32002
