
Ceci est une preuve de travail pour abuser du filtre clean de git contre les IDE et Sublime.
Ceci est un problème documenté (connu), mais je l'ai découvert lors de mes recherches et il est plutôt utile pour RT/PT.
Résumé : La directive filter.<name>.clean dans .git/config pointe vers un script et .gitattributes associe ce filtre à un fichier suivi. Chaque fois que git génère un vrai git diff de ce fichier, il fait d'abord passer le contenu du répertoire de travail par la commande clean, donc git lance aveuglément le chemin que nous spécifions.
C'est là que ça devient intéressant. Nos éditeurs exécutent git diff automatiquement dès que vous cliquez sur un fichier modifié pour alimenter leur panneau SCM (Source Control Management) et les annotations en marge. Ouvrir le dossier seul ne suffit pas, mais consulter la modification suffit, et c'est une action assez naturelle quand on arrive dans un dépôt.
C'est la même idée que core.fsmonitor, mais sur une directive différente, et ce n'est pas fsmonitor, donc quiconque surveille cela ne le verra pas. Cette technique correspond aux engagements RT et aux scénarios assume-breach avec n'importe quel C2 ou notre XRayC2 pour obtenir un callback qui contourne les défenses réseau traditionnelles. (Bien sûr, des e-mails de phishing sont nécessaires pour tromper l'utilisateur final, mais ouvrir un dossier dans un IDE et cliquer sur un fichier semble une opération anodine.)
Preuve de concept. git clone ne transporte pas .git/config, il faut donc livrer le dossier avec .git/ intact. Configuration dans .git/config :
[filter "poc"]
clean = ./icons/clean.sh
smudge = cat
.gitattributes :
sample.txt filter=poc
sample.txt est commité mais livré modifié dans le répertoire de travail. Dès que git en fait un diff, le filtre clean se déclenche. clean.sh fait apparaître Calculatrice et transmet le contenu tel quel, de sorte que le répertoire de travail n'est jamais corrompu :
#!/bin/sh
pgrep -x Calculator >/dev/null 2>&1 || open -a Calculator 2>/dev/null
exec cat
Ouvrez le dossier dans votre éditeur, cliquez sur sample.txt pour voir sa modification, et une calculatrice apparaît. (Quittez Calculatrice pour la relancer.) Cette POC est spécifique à macOS, adaptez-la à votre environnement.
Testé sur Cursor (git CLI) et Sublime Text (libgit2).
Le filtre clean ne s'exécute que lors d'un git diff complet, pas lors d'un git status ; il se déclenche donc quand l'éditeur affiche la modification, et pas seulement à l'ouverture du dossier. Fait intéressant, Sublime le déclenche en interne via libgit2, le parent du payload est sublime_text lui-même, sans binaire git dans la chaîne, donc cela ne se limite pas aux outils qui invoquent git en externe.
https://github.com/user-attachments/assets/31ea495f-1ed8-44f8-bef3-8c6366a0eece
Comme fsmonitor, cela est conditionné par l'invite « faire confiance à ce dossier ? » de l'éditeur. La plupart des développeurs gardent ~/Downloads et les dossiers de premier niveau similaires comme dignes de confiance, et Cursor est livré avec la confiance d'espace de travail désactivée par défaut, donc la POC s'exécute silencieusement. Si un dépôt se trouve en dehors de ces chemins de confiance, l'IDE demandera « faire confiance à cet éditeur ? » avant de lire .git/config.
Docs Git : core.fsmonitor et filter.* sur https://git-scm.com/docs/gitattributes.