Git-sync nei guai: analisi dei difetti Command Injection in Kubernetes
Analisi riassuntiva
Tomer Peled, ricercatore di Akamai, ha individuato un difetto di progettazione nel progetto git-sync correlato di Kubernetes, che consente di attivare una potenziale vulnerabilità Command Injection. Questi risultati sono stati presentati in occasione del DEF CON 2024.
Questo difetto di progettazione può causare un'esfiltrazione dei dati di un qualsiasi file presente nel pod (inclusi i token dell' account di servizio ) o l'esecuzione di un comando con i privilegi dell'utente di git_sync .
Per sfruttare questa vulnerabilità, tutto ciò che deve fare il criminale è applicare un file YAML sul cluster, ossia un'operazione che richiede privilegi minimi.
Questa vulnerabilità può essere sfruttata sulle installazioni predefinite di Kubernetes su tutte le piattaforme (incluse Amazon Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS), Google Kubernetes Engine (GKE) e Linode).
In questo blog, forniamo un file YAML dei temi PoC (Proof-of-Concept) , nonché demo che mostrano il potenziale impatto.
Poiché a questo difetto di progettazione non è stato assegnato un codice CVE, non esistono patch per correggerlo, pertanto può essere sfruttato.
Il team di Kubernetes ci ha incoraggiato a condividere questa ricerca per aumentare la consapevolezza su questi vettori di attacco.
Introduzione
Kubernetes non è estraneo alle vulnerabilità Command Injection. Solo nel 2023, sono state riscontrate 7 vulnerabilità di questo tipo, incluse quelle che abbiamo individuato.. I problemi legati alla sanificazione dell'input ci hanno fatto guardare in modo più approfondito ai vettori di attacco collaterali: questo vettore di attacco è esclusivo del progetto principale di Kubernetes o è più diffuso? Esistono vari progetti collaterali che sono associati a Kubernetes in cui si possono nascondere eventuali vulnerabilità, tra cui git-sync.
Il progetto git-sync è progettato per connettere un pod e un repository Git allo scopo di sincronizzare automaticamente i cambiamenti apportati al proprio sito/server invece di apportarli manualmente tramite una soluzione CI/CD. Ad esempio, gli utenti potrebbero usare questa funzione per collegare il proprio pod nginx con un repository che contiene i file da rendere visibili tramite un pod nginx.
In questo blog, descriveremo in dettaglio il difetto di progettazione, i problemi presenti nel codice sorgente di Kubernetes che l'hanno consentito e alcune soluzioni. Inoltre, spiegheremo come Kubernetes ha risposto ai nostri risultati.
Informazioni sui vettori di attacco
Se guardiamo alla pagina di utilizzo di git-sync, possiamo vedere che supporta molti possibili parametri di configurazione. Pertanto, un utente può personalizzare git-sync in base alle proprie esigenze. Questo aspetto offre ai criminali la possibilità di sfruttare una superficie di attacco potenzialmente ampia (Figura 1).
Figura 1. Alcuni parametri di git-sync
Il framework di Kubernetes utilizza i file YAML praticamente per tutto, dalla configurazione della CNI (Container Network Interface) alla gestione di vari componenti (dai pod ai segreti), pertanto una vulnerabilità presente nei file YAM può risultare alquanto preoccupante. In questo caso, è possibile creare un pod per far utilizzare git-sync allo scopo di connettersi ad un repository remoto (o ad un criminale).
Nella Figura 2 è riportato un esempio di un file di configurazione YAML che utilizza un pod con git-sync.
Figura 2. File di configurazione YAML che utilizza un pod con git-sync
I due parametri che si sono distinti maggiormente come potenziali vettori di attacco sono stati GITSYNC_GIT e GITSYNC_PASSWORD.
In base alla documentazione di git-sync ufficiale, GITSYNC_PASSWORD_FILE è il file da cui verranno letti i token per l'accesso personale o le password (vedere la documentazione di github) da usare per l'autenticazione git (vedere --username).Ciò determina una possibilità di esfiltrazione dei dati per iltoken di accessoo altri file presenti sul pod.
GITSYNC_GIT è (come riportato nuovamente nella documentazione ufficiale) il comando di git da eseguire (a seconda della ricerca del percorso , perlopiù per i test). L'impostazione predefinita è "git," quindi possiamo scegliere un file binario da eseguire invece del git e utilizzarlo per l'esecuzione di codice sul cluster.
Catena degli attacchi proposta
Considerando le informazioni riportate sopra, ci proponiamo di dimostrare le nostre teorie. Riteniamo che alcuni vettori di attacco possano essere sfruttati dai criminali.
Esecuzione di codice nascosto
Un criminale con privilegi minimi (Crea privilegi) sul cluster o sullo spazio dei nomi può applicare un file YAML dannoso, che contiene un percorso al proprio file binario, forzandone l'esecuzione con il nome git-sync.
Il file binario deve trovarsi all'interno del pod, un'operazione che può essere eseguita in diversi modi, ad esempio, tramite le sondeo i volumi di Kubernetesoppure mediante LOLBins che viene fornito con il pod git-sync (Figura 3).
Figura 3. Esempio di un file YAML con LOLBins
Dopo aver applicato il file YAML, per il personale di supporto git-sync comunica con un server remoto e, pertanto, si suppone ragionevolmente che potrà comunicare all'esterno in modo affidabile. In tal modo, i criminali possono aggirare le misure di sicurezza per eseguire il comando.
Nella Figura 4 è riportata una POC di un potenziale attacco che avvia un cryptominer XMrig nell'utente di git-sync.
Figura 4. PoC del potenziale cryptominer XMRig
Ora, quando un amministratore di rete controllerà i pod esistenti e le loro comunicazioni all'esterno della rete aziendale, molto probabilmente vedrà che l'utente di git-sync comunica con un server esterno.
Esfiltrazione dei dati
Un criminale con privilegi di modifica può modificare un'implementazione git-sync per cambiare o aggiungere il parametro GITSYNC_PASSWORD_FILE e puntarlo a qualsiasi file presente nel pod. In tal modo, git-sync invierà il file come mezzo di autenticazione alla sua successiva connessione al repository Git.
Se il criminale modifica anche la posizione del repository Git e configura un server come pseudo-repository, la successiva implementazione del processo di git-sync all'interno del pod invierà il file nel parametro GITSYNC_PASSWORD_FILE dal pod sul proprio sistema. Non esistono restrizioni per i percorsi dei file o permessi richiesti per il GITSYNC_PASSWORD_FILE.
Non è difficile immaginare un'esfiltrazione ad alto rischio. Consideriamo quanto segue: i criminali possono usare questa tecnica per recuperare il token di accesso del pod al fine di interagire con il cluster sotto forma del pod git-sync (Figura 5).
Figura 5. PoC di un potenziale attacco GITSYNC_PASSWORD_FILE
Divulgazione e risposta di Kubernetes
Originariamente, abbiamo divulgato i nostri risultati al team di Kubernetes a dicembre 2023. Dopo alcuni colloqui con il team di Kubernetes, si è deciso che la modifica dei file YAML è considerata un'operazione che richiede privilegi elevati, pertanto, i nostri risultati non oltrepassano una soglia di sicurezza. Tuttavia, dal nostro punto di vista, anche se le operazioni di modifica su un pod richiedono privilegi elevati, il movimento laterale è comunque consentito con questa tecnica. Si è manifestata anche una certa preoccupazione riguardo alla perdita di integrità: il criminale potrebbe riuscire a rubare le informazioni desiderate se fosse un utente di git-sync.
Per quanto riguarda il GITSYNC_GIT, il team di Kubernetes ha riconosciuto che i privilegi richiesti per questo tipo di azione sono minimi, ma non ha ritenuto che le operazioni che richiedono privilegi minimi possano condurre ad un comportamento dannoso. Tuttavia, riteniamo che il difetto di progettazione descritto potrebbe consentire ai criminali di eseguire i comandi desiderati falsificando la loro identità e l'unico modo per impedire un comportamento dannoso consiste nell'utilizzare i privilegi minimi sul cluster. Questo flusso dell'attacco è particolarmente pericoloso nelle organizzazioni in cui le comunicazioni git-sync sono preautorizzate nel proprio cluster.
In entrambi i casi, Kubernetes ci ha incoraggiato a condividere questa ricerca estremamente interessante online perché aiuta a ricordare agli amministratori di pensare attentamente all'area della superficie che espongono agli utenti.
Soluzioni di mitigazione
Poiché le tecniche di attacco descritte in questo blog non sono considerate vulnerabilità dal team di Kubernetes, non verrà rilasciata alcuna patch per correggerle. Pertanto, per ridurre la superficie di attacco consentita da queste "funzioni", consigliamo di adottare alcune potenziali mitigazioni.
Innanzitutto, incrementare il monitoraggio delle comunicazioni in uscita dall'organizzazione, specialmente dai pod di Kubernetes. Prestare estrema attenzione ai pod di git-sync, se questa granularità è consentita.
In secondo luogo, consigliamo di controllare i pod di git-sync per vedere quale comando stanno eseguendo. È possibile eseguire questa operazione con il seguente comando:
kubectl describe pod <git-sync-pod>
Ad esempio, durante l'esecuzione di questo comando sul cryptominer riportato nella Figura 4, possiamo vedere che l'argomento –git avrebbe dovuto allertare al momento del rilevamento, specialmente se il valore dell'argomento non è "git" (Figura 6).
Figura 6. Esecuzione del comando di audit nel cryptominer riportato nella Figura 4
Questo controllo è una buona prassi di sicurezza generica, pertanto consigliamo di eseguire questo comando su tutti i pod, non solo sui pod di git-sync.
Abbiamo anche scritta una regola OPA che può rilevare uno dei nostri vettori di attacco proposti, in cui gli attacchi sostituiscono il file binario git con un payload dannoso:
package kubernetes.admission
deny[msg] {
input.request.kind.kind == "<Deployment/Pod>"
path := input.request.object.spec.env.name
contains(path, "GITSYNC_GIT")
msg := sprintf("Gitsync binary parameter detected, possible payload alteration, verify new binary ", [path])
}
Conclusione
In questo blog, abbiamo mostrato i due vettori di attacco nel progetto collaterale git-sync di Kubernetes. Entrambi i vettori sono dovuti ad una mancanza di sanificazione dell'input, che evidenzia la necessità di adottare una solida difesa in questo contesto. Questi problemi di sanificazione di Kubernetes non sono esclusivi di git-sync, come abbiamo descritto in precedenza .
Il personale del supporto deve verificare la presenza di eventuali comportamenti insoliti da parte dell'utente di gitsync nella propria organizzazione. Riteniamo che questi vettori di attacco possano influire enormemente sulle aziende, pertanto è importante per noi aumentare la consapevolezza e aiutare gli amministratori della sicurezza a conoscere il potenziale pericolo.
L'Akamai Security Intelligence Group continuerà a ricercare minacce come queste e a segnalarle per i clienti dell'azienda e per la più vasta comunità della sicurezza. Per aggiornamenti in tempo reale sulle nostre ricerche, seguiteci su X (in precedenza Twitter).
Anche se non concordiamo con i risultati, desideriamo ringraziare il team di Kubernetes per la risposta e la trattazione efficace.