git-clean-filter

Questo è un problema documentato (noto), ma l'ho trovato durante la mia ricerca ed è piuttosto utile per RT/PT.

Riepilogo: La direttiva filter.<name>.clean in .git/config punta a uno script e .gitattributes vincola quel filtro a un file tracciato. Ogni volta che git esegue un vero git diff di quel file, passa prima il contenuto della working tree attraverso il comando clean, quindi git lancia alla cieca qualunque percorso specifichiamo lì.

Ed è qui che la cosa diventa interessante. I nostri editor eseguono git diff automaticamente nel momento in cui clicchi un file modificato per popolare il pannello SCM (Source Control Management) e le annotazioni a margine (gutter). Aprire la cartella da sola non basta, ma visualizzare la modifica sì, ed è una cosa abbastanza naturale quando arrivi in un repository.

Questa è la stessa idea di core.fsmonitor, solo su una direttiva diversa, e non è fsmonitor, quindi chiunque stia cercando quello non lo vedrà. La tradecraft si adatta a impegni di red team e a scenari assume-breach con qualsiasi C2 o con il nostro XRayC2 per ottenere una callback che eluda le difese di rete tradizionali. (Ovviamente servono email di phishing per ingannare l'utente finale, ma aprire una cartella in un IDE e cliccare un file sembra un'operazione lecita.)

Prova di funzionamento. git clone non trasporta .git/config, quindi consegna la cartella con .git/ intatto. Configurazione in .git/config:

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

.gitattributes:

sample.txt filter=poc

sample.txt è committato ma viene consegnato modificato nella working tree. Nel momento in cui git ne fa il diff, il filtro clean scatta. clean.sh apre Calculator e lascia passare il contenuto invariato, così la working tree non viene mai corrotta:

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

Apri la cartella nel tuo editor, clicca sample.txt per visualizzarne la modifica e si apre una calcolatrice. (Esci da Calculator per rieseguirlo.) Questa POC è specifica per macOS, adattala al tuo ambiente.

Testato su Cursor (git CLI) e Sublime Text (libgit2).

Il filtro clean viene eseguito solo su un git diff completo, non su git status, quindi scatta quando l'editor rende la modifica, non solo all'apertura della cartella. Curiosamente Sublime lo attiva in-process tramite libgit2: il parent del payload è sublime_text stesso senza alcun binario git nella catena, quindi non è limitato a strumenti che richiamano git tramite shell.

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

Come fsmonitor, anche questo è condizionato dal prompt "ti fidi di questa cartella?" dell'editor. La maggior parte degli sviluppatori tiene ~/Downloads e cartelle di primo livello simili come fidate, e Cursor viene distribuito con workspace trust disattivato di default, quindi la PoC gira in silenzio. Se un repository si trova al di fuori di questi percorsi fidati, l'IDE chiederà "ti fidi di questo publisher?" prima di leggere .git/config.

Documentazione Git: core.fsmonitor e filter.* su https://git-scm.com/docs/gitattributes.