È stata recentemente divulgata una vulnerabilità critica in Git che consente attacchi RCE (esecuzione di codice in remoto), con impatto su più versioni di Git e Microsoft Visual Studio 2017. La vulnerabilità consente agli aggressori di manipolare i repository Git utilizzando i sottomoduli, sfruttando un bug di Git che consente la scrittura di file al di fuori dell'albero di lavoro del sottomodulo e nella directory .git/. Questo bug consente l'esecuzione di un hook dannoso mentre un'operazione di clonazione del repository è ancora in corso [1].
La vulnerabilità CVE-2024-32002 interessa Microsoft Visual Studio 2017 versione 15.9 e le versioni di Git precedenti a 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2 e 2.39.4. Può essere sfruttato in ambienti in cui il supporto per i collegamenti simbolici è abilitato su sistemi operativi che non fanno distinzione tra maiuscole e minuscole.
Capire Git
Git è un sistema di controllo di versione distribuito, gratuito e open-source, progettato per aiutare gli sviluppatori di software a gestire le basi di codice in modo rapido ed efficiente. Migliora la collaborazione tra i membri del team di sviluppo organizzando e tracciando le modifiche ai file e alle directory in modo standardizzato e strutturato.
Git è ampiamente utilizzato nello sviluppo del software. Piattaforme come GitHub, GitLab e Bitbucket si basano su Git per migliorare la collaborazione tra gli sviluppatori grazie alle sue potenti funzioni:
- Registrazione di modifiche tracciabili ai file di codice, note come commit.
- Riportare le modifiche al codice a versioni precedenti, se necessario.
- Combinare in modo efficiente le modifiche provenienti da rami o collaboratori diversi.
- Tenere un registro della storia di chi ha apportato le modifiche e delle relative date.
Ganci Git
Quando viene creato o clonato un repository Git, usando i comandi git init o git clone, viene generata una directory .gitalla radice dell'albero di lavoro. La struttura della directory .git inizialmente appare come segue:
Gli hook di Git sono script eseguibili, situati nella cartella .git/hooks o nella cartella .git/modules/module_type/module_name/hooks. Gli hook vengono attivati automaticamente quando si verificano eventi specifici in un repository Git.
Quando un file nella directory hooks non ha il suffisso .sample, i comandi in quel file saranno eseguiti prima o dopo una particolare azione Git inclusa nel nome del file, come pre-commit, post-commit e post-checkout.
Sottomoduli Git
Un sottomodulo Git è un record all'interno di un repository Git che fa riferimento a un commit specifico in un repository esterno. Quando un sottomodulo viene aggiunto a un repository, viene creato un nuovo file nella directory .gitmodules con i metadati della mappatura tra l'URL del sottomodulo e la sua directory locale. Quando un repository contiene più sottomoduli, il file .gitmodules includerà una voce per ciascuno di essi. [3]
Collegamenti simbolici (Symlinks)
Un collegamento simbolico, detto anche link simbolico o soft link, è un file che punta a un altro file o directory (detto "target") specificandone il percorso. Se un collegamento simbolico viene cancellato, la sua destinazione rimane inalterata. [4]
Un link simbolico in Git è creato come un file con metadati che lo fanno funzionare come un riferimento o una scorciatoia a un altro file. I link simbolici possono essere usati per creare più riferimenti a un file senza replicarne il contenuto.
Analisi delle vulnerabilità della sicurezza di GIT
Analisi delle patch
Per comprendere più a fondo le vulnerabilità della sicurezza, gli specialisti della sicurezza eseguono spesso l'analisi delle patch. Si tratta di una tecnica che aiuta a identificare le funzioni vulnerabili e i potenziali vettori di attacco. I ricercatori OPSWAT hanno esaminato le modifiche apportate alla versione patchata per risolvere la vulnerabilità CVE-2024-32002 e hanno scoperto che due file sono stati aggiornati per risolvere questa CVE.
Uno dei file aggiornati è il file submodule--helper.c, che include il codice che gestisce la clonazione dei sottomoduli Git. I nuovi commit nella versione patchata includono i due seguenti:
- Aggiunta della funzione dir_contains_only_dotgit per garantire che la cartella dei sottomoduli non contenga file o directory .git.
- Sono state apportate modifiche alla funzione clone_submodule() per includere una condizione per verificare se la directory del sottomodulo esiste ed è vuota. Se la directory non è vuota, il processo di clonazione viene interrotto.
Il secondo aggiornamento del nuovo commit riguarda il file t/t7406-submodule-update.sh, che aggiunge uno script di test per verificare che la vulnerabilità sia stata risolta.
Dall'analisi allo sfruttamento
Oltre agli approfondimenti raccolti con l'analisi delle patch e la descrizione della vulnerabilità CVE-2024-32002, i borsisti OPSWAT hanno lavorato sull'analisi del flusso di lavoro dei link simbolici e dei sottomoduli in Git. Hanno analizzato la sequenza di eventi che si verifica quando un utente clona un repository:
- Git inizia scaricando i file e le directory dal repository primario.
- Utilizza le definizioni specificate nei file di collegamento simbolico per ricreare i corrispondenti collegamenti simbolici nel file system locale.
- Se il collegamento simbolico punta a un file esistente, il collegamento sarà funzionante; altrimenti, il collegamento simbolico rimarrà inoperante fino a quando non verrà ripristinata la destinazione.
- Se il repository viene clonato con l'opzione --recursive, Git clona i sottomoduli (repository esterni) e li colloca nei percorsi delle directory come indicato nel file .gitmodules.
- Se un link simbolico fa parte del percorso del sottomodulo (per esempio, util/modulo/test, dove util è un link simbolico che punta a un'altra cartella, come symlink_folder), Git memorizzerà il contenuto del sottomodulo nella cartella effettiva a cui fa riferimento il link simbolico (per esempio, symlink_folder/modulo/test), pur consentendo l'accesso attraverso il percorso originale del link simbolico.
Comprendere la vulnerabilità di sicurezza di Git CVE-2024-32002
Creazione di repository dannosi
I ricercatori OPSWAT hanno esaminato ulteriormente la creazione di repository dannosi sulla base degli aggiornamenti effettuati per il filet/t7406-submodule-update.sh e hanno suddiviso questo processo nelle seguenti fasi:
- Creazione di un repository contenente un hook post-checkout
- Creazione di un altro repository che include un sottomodulo, situato nel percorso A/moduli/x. Il nuovo sottomodulo fa riferimento al repository creato in precedenza.
- Creare un collegamento simbolico chiamato a, che punta alla cartella .git nell'indice di Git.
Comprendere la falla di sicurezza
Quando un utente clona un repository dannoso, creato nel passaggio precedente, utilizzando l'opzione --recursive, lo script dannoso dell'hook post-checkout verrà attivato, consentendo all'attaccante di compromettere il dispositivo dell'utente.
L'esecuzione di codice remoto avviene perché il repository principale rileva un collegamento simbolico denominato a che punta alla directory .git quando viene clonato. Con la modalità ricorsiva abilitata, anche i sottomoduli vengono estratti nel repository clonato. Questo repository contiene una cartella hooks, che contiene lo script di hook post-checkout, e la sua directory locale è in A/modules/x.
Poiché a punta alla cartella.git e il file system non fa distinzione tra maiuscole e minuscole, A viene interpretato come equivalente ad a. Git viene indotto a scrivere lo script dell'hook post-checkout nella cartella .git/modules/query/fast/hooks/. Se uno script di hook post-checkout viene trovato nella cartella . git/modules/{module_type}/{module_name}/hooks, verrà attivato quando il repository principale viene clonato con l'opzione --recursive. Di conseguenza, gli aggressori possono compromettere con successo il dispositivo dell'utente eseguendo codice remoto.
Simulazione dello sfruttamento della vulnerabilità di Git
Sulla base dei risultati precedenti, i membri di OPSWAT hanno creato un repository principale e un hook per simulare la creazione di un repository dannoso:
- Inizialmente, si consiglia di configurare Git in modo che consenta sempre il file protocol.file, abiliti i collegamenti simbolici core.symlinks e imposti il nome predefinito del ramo a main (per evitare il messaggio di avvertimento).
- Uno script di hook post-checkout dannoso viene aggiunto alla directory hooks. Per garantire che lo script post-checkout possa essere eseguito sul dispositivo dell'utente, lo script bash che crea questo hook include il comando chmod +x fast/hooks/post-checkout.
- Nel repository principale viene creato un collegamento simbolico che punta alla directory .git.
La cartella /hooks con un hook post-checkout
Bonifica
Per neutralizzare la minaccia, gli utenti possono disinstallare Git o applicare l'ultima patch di sicurezza. In alternativa, una soluzione come MetaDefender Endpoint può avvisare tempestivamente l'utente e visualizzare tutte le CVE note all'interno dell'ambiente attraverso la sua interfaccia intuitiva. MetaDefender Endpoint è in grado di rilevare e mitigare le CVE più recenti sfruttando le sue capacità con oltre 3 milioni di punti dati e oltre 30.000 CVE associate con informazioni sulla gravità. Implementando una delle due contromisure, la CVE sarà completamente contenuta, eliminando il rischio di un devastante attacco informatico.
Siete pronti a mettere MetaDefender Endpoint in prima linea nella vostra strategia di cybersecurity?
