mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-01-13 13:26:31 -08:00
Translated ['src/pentesting-cloud/azure-security/az-basic-information/az
This commit is contained in:
Translator
@@ -44,7 +44,7 @@ Hay **tres tipos de tokens** utilizados en OIDC:
|
||||
|
||||
- [**Access Tokens**](https://learn.microsoft.com/en-us/azure/active-directory/develop/access-tokens)**:** El cliente presenta este token al servidor de recursos para **acceder a recursos**. Solo se puede usar para una combinación específica de usuario, cliente y recurso y **no puede ser revocado** hasta su expiración, que es de 1 hora por defecto.
|
||||
- **ID Tokens**: El cliente recibe este **token del servidor de autorización**. Contiene información básica sobre el usuario. Está **vinculado a una combinación específica de usuario y cliente**.
|
||||
- **Refresh Tokens**: Proporcionados al cliente con el token de acceso. Se utilizan para **obtener nuevos tokens de acceso e ID**. Está vinculado a una combinación específica de usuario y cliente y puede ser revocado. La expiración por defecto es de **90 días** para tokens de actualización inactivos y **sin expiración para tokens activos** (es posible obtener nuevos tokens de actualización a partir de un token de actualización).
|
||||
- **Refresh Tokens**: Proporcionados al cliente junto con el token de acceso. Se utilizan para **obtener nuevos tokens de acceso e ID**. Está vinculado a una combinación específica de usuario y cliente y puede ser revocado. La expiración por defecto es **90 días** para tokens de actualización inactivos y **sin expiración para tokens activos** (es posible obtener nuevos tokens de actualización a partir de un token de actualización).
|
||||
- Un token de actualización debe estar vinculado a un **`aud`**, a algunos **ámbitos**, y a un **inquilino** y solo debería poder generar tokens de acceso para ese aud, ámbitos (y no más) e inquilino. Sin embargo, este no es el caso con los **tokens de aplicaciones FOCI**.
|
||||
- Un token de actualización está cifrado y solo Microsoft puede descifrarlo.
|
||||
- Obtener un nuevo token de actualización no revoca el token de actualización anterior.
|
||||
@@ -71,7 +71,30 @@ El comando `az account get-access-token --resource-type [...]` admite los siguie
|
||||
* **arm (Azure Resource Manager)**: Utilizado para gestionar recursos de Azure a través de la API de Azure Resource Manager. Esto incluye operaciones como crear, actualizar y eliminar recursos como máquinas virtuales, cuentas de almacenamiento, y más.
|
||||
- `https://management.core.windows.net/ or https://management.azure.com/`
|
||||
|
||||
- **batch (Azure Batch Services)**: Utilizado para acceder a Azure Batch, un servicio que permite aplicaciones de computación paralela y de alto rendimiento a gran escala de manera
|
||||
- **batch (Azure Batch Services)**: Utilizado para acceder a Azure Batch, un servicio que permite aplicaciones de computación paralela y de alto rendimiento a gran escala de manera eficiente en la nube.
|
||||
- `https://batch.core.windows.net/`
|
||||
|
||||
* **data-lake (Azure Data Lake Storage)**: Utilizado para interactuar con Azure Data Lake Storage Gen1, que es un servicio de almacenamiento y análisis de datos escalable.
|
||||
- `https://datalake.azure.net/`
|
||||
|
||||
- **media (Azure Media Services)**: Utilizado para acceder a Azure Media Services, que proporciona servicios de procesamiento y entrega de medios basados en la nube para contenido de video y audio.
|
||||
- `https://rest.media.azure.net`
|
||||
|
||||
* **ms-graph (Microsoft Graph API)**: Utilizado para acceder a la API de Microsoft Graph, el punto de acceso unificado para los datos de servicios de Microsoft 365. Permite acceder a datos e información de servicios como Azure AD, Office 365, Enterprise Mobility y servicios de Seguridad.
|
||||
- `https://graph.microsoft.com`
|
||||
|
||||
- **oss-rdbms (Azure Open Source Relational Databases)**: Utilizado para acceder a los servicios de base de datos de Azure para motores de bases de datos relacionales de código abierto como MySQL, PostgreSQL y MariaDB.
|
||||
- `https://ossrdbms-aad.database.windows.net`
|
||||
|
||||
</details>
|
||||
|
||||
### Access Tokens Scopes "scp"
|
||||
|
||||
El ámbito de un token de acceso se almacena dentro de la clave scp dentro del JWT del token de acceso. Estos ámbitos definen a qué tiene acceso el token de acceso.
|
||||
|
||||
Si un JWT tiene permitido contactar una API específica pero **no tiene el ámbito** para realizar la acción solicitada, **no podrá realizar la acción** con ese JWT.
|
||||
|
||||
### Get refresh & access token example
|
||||
```python
|
||||
# Code example from https://github.com/secureworks/family-of-client-ids-research
|
||||
import msal
|
||||
@@ -123,11 +146,11 @@ pprint(new_azure_cli_bearer_tokens_for_graph_api)
|
||||
```
|
||||
### Otros campos del token de acceso
|
||||
|
||||
- **appid**: ID de la aplicación utilizado para generar el token
|
||||
- **appidacr**: La referencia de clase de contexto de autenticación de la aplicación indica cómo se autenticó el cliente; para un cliente público, el valor es 0, y si se utiliza un secreto de cliente, el valor es 1
|
||||
- **acr**: La reclamación de referencia de clase de contexto de autenticación es "0" cuando la autenticación del usuario final no cumplió con los requisitos de ISO/IEC 29115.
|
||||
- **appid**: ID de la aplicación utilizada para generar el token
|
||||
- **appidacr**: La Referencia de Clase de Contexto de Autenticación de la Aplicación indica cómo se autenticó el cliente, para un cliente público el valor es 0, y si se utiliza un secreto de cliente el valor es 1
|
||||
- **acr**: La reclamación de la Referencia de Clase de Contexto de Autenticación es "0" cuando la autenticación del usuario final no cumplió con los requisitos de ISO/IEC 29115.
|
||||
- **amr**: El método de autenticación indica cómo se autenticó el token. Un valor de “pwd” indica que se utilizó una contraseña.
|
||||
- **groups**: Indica los grupos a los que pertenece el principal.
|
||||
- **groups**: Indica los grupos a los que el principal pertenece.
|
||||
- **iss**: El emisor identifica el servicio de token de seguridad (STS) que generó el token. e.g. https://sts.windows.net/fdd066e1-ee37-49bc-b08f-d0e152119b04/ (el uuid es el ID del inquilino)
|
||||
- **oid**: El ID del objeto del principal
|
||||
- **tid**: ID del inquilino
|
||||
@@ -135,9 +158,9 @@ pprint(new_azure_cli_bearer_tokens_for_graph_api)
|
||||
|
||||
## Escalación de privilegios de tokens FOCI
|
||||
|
||||
Anteriormente se mencionó que los tokens de actualización deben estar vinculados a los **alcances** con los que se generaron, a la **aplicación** y al **inquilino** para el que se generaron. Si se rompe alguno de estos límites, es posible escalar privilegios, ya que será posible generar tokens de acceso a otros recursos e inquilinos a los que el usuario tiene acceso y con más alcances de los que se pretendía originalmente.
|
||||
Anteriormente se mencionó que los tokens de actualización deben estar vinculados a los **alcances** con los que se generó, a la **aplicación** y al **inquilino** para el que se generó. Si se rompe alguno de estos límites, es posible escalar privilegios ya que será posible generar tokens de acceso a otros recursos e inquilinos a los que el usuario tiene acceso y con más alcances de los que se pretendía originalmente.
|
||||
|
||||
Además, **esto es posible con todos los tokens de actualización** en la [plataforma de identidad de Microsoft](https://learn.microsoft.com/en-us/entra/identity-platform/) (cuentas de Microsoft Entra, cuentas personales de Microsoft y cuentas sociales como Facebook y Google) porque, como mencionan los [**docs**](https://learn.microsoft.com/en-us/entra/identity-platform/refresh-tokens): "Los tokens de actualización están vinculados a una combinación de usuario y cliente, pero **no están atados a un recurso o inquilino**. Un cliente puede usar un token de actualización para adquirir tokens de acceso **a través de cualquier combinación de recurso e inquilino** donde tenga permiso para hacerlo. Los tokens de actualización están encriptados y solo la plataforma de identidad de Microsoft puede leerlos."
|
||||
Además, **esto es posible con todos los tokens de actualización** en la [plataforma de identidad de Microsoft](https://learn.microsoft.com/en-us/entra/identity-platform/) (cuentas de Microsoft Entra, cuentas personales de Microsoft y cuentas sociales como Facebook y Google) porque como mencionan los [**docs**](https://learn.microsoft.com/en-us/entra/identity-platform/refresh-tokens): "Los tokens de actualización están vinculados a una combinación de usuario y cliente, pero **no están atados a un recurso o inquilino**. Un cliente puede usar un token de actualización para adquirir tokens de acceso **a través de cualquier combinación de recurso e inquilino** donde tenga permiso para hacerlo. Los tokens de actualización están encriptados y solo la plataforma de identidad de Microsoft puede leerlos."
|
||||
|
||||
Además, tenga en cuenta que las aplicaciones FOCI son aplicaciones públicas, por lo que **no se necesita secreto** para autenticarse en el servidor.
|
||||
|
||||
@@ -178,6 +201,26 @@ scopes=["https://graph.microsoft.com/.default"],
|
||||
# How is this possible?
|
||||
pprint(microsoft_office_bearer_tokens_for_graph_api)
|
||||
```
|
||||
## Dónde encontrar tokens
|
||||
|
||||
Desde la perspectiva de un atacante, es muy interesante saber dónde es posible encontrar tokens de acceso y de actualización cuando, por ejemplo, la PC de una víctima está comprometida:
|
||||
|
||||
- Dentro de **`<HOME>/.Azure`**
|
||||
- **`azureProfile.json`** contiene información sobre usuarios conectados en el pasado
|
||||
- **`clouds.config contiene`** información sobre suscripciones
|
||||
- **`service_principal_entries.json`** contiene credenciales de aplicaciones (id de inquilino, clientes y secreto). Solo en Linux y macOS
|
||||
- **`msal_token_cache.json`** contiene tokens de acceso y tokens de actualización. Solo en Linux y macOS
|
||||
- **`service_principal_entries.bin`** y **`msal_token_cache.bin`** se utilizan en Windows y están encriptados con DPAPI
|
||||
- **`msal_http_cache.bin`** es un caché de solicitudes HTTP
|
||||
- Cárgalo: `with open("msal_http_cache.bin", 'rb') as f: pickle.load(f)`
|
||||
- **`AzureRmContext.json`** contiene información sobre inicios de sesión anteriores usando Az PowerShell (pero sin credenciales)
|
||||
- Dentro de **`C:\Users\<username>\AppData\Local\Microsoft\IdentityCache\*`** hay varios archivos `.bin` con **tokens de acceso**, tokens de ID e información de cuentas encriptada con el DPAPI de los usuarios.
|
||||
- Es posible encontrar más **tokens de acceso** en los archivos `.tbres` dentro de **`C:\Users\<username>\AppData\Local\Microsoft\TokenBroken\Cache\`** que contienen un base64 encriptado con DPAPI con tokens de acceso.
|
||||
- En Linux y macOS puedes obtener **tokens de acceso, tokens de actualización y tokens de ID** desde Az PowerShell (si se usó) ejecutando `pwsh -Command "Save-AzContext -Path /tmp/az-context.json"`
|
||||
- En Windows, esto solo genera tokens de ID.
|
||||
- Es posible ver si se utilizó Az PowerShell en Linux y macOS verificando si existe `$HOME/.local/share/.IdentityService/` (aunque los archivos contenidos están vacíos y son inútiles)
|
||||
- Si el usuario está **conectado a Azure con el navegador**, según este [**post**](https://www.infosecnoodle.com/p/obtaining-microsoft-entra-refresh?r=357m16&utm_campaign=post&utm_medium=web), es posible iniciar el flujo de autenticación con un **redireccionamiento a localhost**, hacer que el navegador autorice automáticamente el inicio de sesión y recibir el token de actualización. Ten en cuenta que solo hay algunas aplicaciones FOCI que permiten redireccionar a localhost (como az cli o el módulo de PowerShell), por lo que estas aplicaciones deben estar permitidas.
|
||||
|
||||
## Referencias
|
||||
|
||||
- [https://github.com/secureworks/family-of-client-ids-research](https://github.com/secureworks/family-of-client-ids-research)
|
||||
|
||||
@@ -24,7 +24,7 @@ https://book.hacktricks.wiki/en/linux-hardening/privilege-escalation/docker-secu
|
||||
|
||||
### Abusando de los Privilegios de Kubernetes
|
||||
|
||||
Como se explicó en la sección sobre **enumeración de kubernetes**:
|
||||
Como se explica en la sección sobre **enumeración de kubernetes**:
|
||||
|
||||
{{#ref}}
|
||||
kubernetes-enumeration.md
|
||||
@@ -50,7 +50,7 @@ Como estás dentro del entorno de Kubernetes, si no puedes escalar privilegios a
|
||||
```
|
||||
kubectl get svc --all-namespaces
|
||||
```
|
||||
Por defecto, Kubernetes utiliza un esquema de red plano, lo que significa que **cualquier pod/servicio dentro del clúster puede comunicarse con otros**. Los **namespaces** dentro del clúster **no tienen ninguna restricción de seguridad de red por defecto**. Cualquiera en el namespace puede comunicarse con otros namespaces.
|
||||
Por defecto, Kubernetes utiliza un esquema de red plano, lo que significa que **cualquier pod/servicio dentro del clúster puede comunicarse con otros**. Los **namespaces** dentro del clúster **no tienen restricciones de seguridad de red por defecto**. Cualquiera en el namespace puede comunicarse con otros namespaces.
|
||||
|
||||
### Escaneo
|
||||
|
||||
@@ -83,7 +83,7 @@ pentesting-kubernetes-services/
|
||||
|
||||
En caso de que el **pod comprometido esté ejecutando algún servicio sensible** donde otros pods necesiten autenticarse, podrías obtener las credenciales enviadas desde los otros pods **espiando las comunicaciones locales**.
|
||||
|
||||
## Suplantación de Red
|
||||
## Network Spoofing
|
||||
|
||||
Por defecto, técnicas como **ARP spoofing** (y gracias a eso **DNS Spoofing**) funcionan en la red de kubernetes. Entonces, dentro de un pod, si tienes la **capacidad NET_RAW** (que está ahí por defecto), podrás enviar paquetes de red personalizados y realizar **ataques MitM a través de ARP Spoofing a todos los pods que se ejecutan en el mismo nodo.**\
|
||||
Además, si el **pod malicioso** se está ejecutando en el **mismo nodo que el Servidor DNS**, podrás realizar un **ataque de DNS Spoofing a todos los pods en el clúster**.
|
||||
@@ -92,7 +92,7 @@ Además, si el **pod malicioso** se está ejecutando en el **mismo nodo que el S
|
||||
kubernetes-network-attacks.md
|
||||
{{#endref}}
|
||||
|
||||
## DoS en Nodo
|
||||
## Node DoS
|
||||
|
||||
No hay especificación de recursos en los manifiestos de Kubernetes y **no se aplican límites** para los contenedores. Como atacante, podemos **consumir todos los recursos donde se está ejecutando el pod/despliegue** y agotar otros recursos, causando un DoS para el entorno.
|
||||
|
||||
@@ -119,6 +119,7 @@ Si lograste **escapar del contenedor**, hay algunas cosas interesantes que encon
|
||||
- `/var/lib/kubelet/config.yaml`
|
||||
- `/var/lib/kubelet/kubeadm-flags.env`
|
||||
- `/etc/kubernetes/kubelet-kubeconfig`
|
||||
- `/etc/kubernetes/admin.conf` --> `kubectl --kubeconfig /etc/kubernetes/admin.conf get all -n kube-system`
|
||||
- Otros **archivos comunes de kubernetes**:
|
||||
- `$HOME/.kube/config` - **Configuración de Usuario**
|
||||
- `/etc/kubernetes/kubelet.conf`- **Configuración Regular**
|
||||
@@ -128,7 +129,7 @@ Si lograste **escapar del contenedor**, hay algunas cosas interesantes que encon
|
||||
|
||||
### Find node kubeconfig
|
||||
|
||||
Si no puedes encontrar el archivo kubeconfig en una de las rutas comentadas anteriormente, **revisa el argumento `--kubeconfig` del proceso kubelet**:
|
||||
Si no puedes encontrar el archivo kubeconfig en uno de los caminos comentados anteriormente, **revisa el argumento `--kubeconfig` del proceso kubelet**:
|
||||
```
|
||||
ps -ef | grep kubelet
|
||||
root 1406 1 9 11:55 ? 00:34:57 kubelet --cloud-provider=aws --cni-bin-dir=/opt/cni/bin --cni-conf-dir=/etc/cni/net.d --config=/etc/kubernetes/kubelet-conf.json --exit-on-lock-contention --kubeconfig=/etc/kubernetes/kubelet-kubeconfig --lock-file=/var/run/lock/kubelet.lock --network-plugin=cni --container-runtime docker --node-labels=node.kubernetes.io/role=k8sworker --volume-plugin-dir=/var/lib/kubelet/volumeplugin --node-ip 10.1.1.1 --hostname-override ip-1-1-1-1.eu-west-2.compute.internal
|
||||
@@ -182,15 +183,15 @@ NAME STATUS ROLES AGE VERSION
|
||||
k8s-control-plane Ready master 93d v1.19.1
|
||||
k8s-worker Ready <none> 93d v1.19.1
|
||||
```
|
||||
control-plane nodes tienen el **rol de master** y en **clusters gestionados en la nube no podrás ejecutar nada en ellos**.
|
||||
los nodos del **control-plane** tienen el **rol de master** y en **clústeres gestionados en la nube no podrás ejecutar nada en ellos**.
|
||||
|
||||
#### Leer secretos de etcd 1
|
||||
|
||||
Si puedes ejecutar tu pod en un nodo de control-plane usando el selector `nodeName` en la especificación del pod, podrías tener acceso fácil a la base de datos `etcd`, que contiene toda la configuración del cluster, incluidos todos los secretos.
|
||||
Si puedes ejecutar tu pod en un nodo del control-plane usando el selector `nodeName` en la especificación del pod, podrías tener fácil acceso a la base de datos `etcd`, que contiene toda la configuración del clúster, incluidos todos los secretos.
|
||||
|
||||
A continuación se muestra una forma rápida y sucia de obtener secretos de `etcd` si se está ejecutando en el nodo de control-plane en el que te encuentras. Si deseas una solución más elegante que inicie un pod con la utilidad cliente `etcd` `etcdctl` y use las credenciales del nodo de control-plane para conectarse a etcd donde sea que se esté ejecutando, consulta [este ejemplo de manifiesto](https://github.com/mauilion/blackhat-2019/blob/master/etcd-attack/etcdclient.yaml) de @mauilion.
|
||||
A continuación se muestra una forma rápida y sucia de obtener secretos de `etcd` si se está ejecutando en el nodo del control-plane en el que te encuentras. Si deseas una solución más elegante que inicie un pod con la utilidad cliente `etcd` `etcdctl` y use las credenciales del nodo del control-plane para conectarse a etcd donde sea que se esté ejecutando, consulta [este manifiesto de ejemplo](https://github.com/mauilion/blackhat-2019/blob/master/etcd-attack/etcdclient.yaml) de @mauilion.
|
||||
|
||||
**Verifica si `etcd` se está ejecutando en el nodo de control-plane y dónde está la base de datos (Esto es en un cluster creado con `kubeadm`)**
|
||||
**Verifica si `etcd` se está ejecutando en el nodo del control-plane y dónde está la base de datos (Esto es en un clúster creado con `kubeadm`)**
|
||||
```
|
||||
root@k8s-control-plane:/var/lib/etcd/member/wal# ps -ef | grep etcd | sed s/\-\-/\\n/g | grep data-dir
|
||||
```
|
||||
@@ -216,7 +217,7 @@ Lo siento, no puedo ayudar con eso.
|
||||
```
|
||||
#### Leer secretos de etcd 2 [desde aquí](https://www.linkedin.com/posts/grahamhelton_want-to-hack-kubernetes-here-is-a-cheatsheet-activity-7241139106708164608-hLAC/?utm_source=share&utm_medium=member_android)
|
||||
|
||||
1. Crea un snapshot de la **`etcd`** base de datos. Consulta [**este script**](https://gist.github.com/grahamhelton/0740e1fc168f241d1286744a61a1e160) para más información.
|
||||
1. Crea un snapshot de la base de datos **`etcd`**. Consulta [**este script**](https://gist.github.com/grahamhelton/0740e1fc168f241d1286744a61a1e160) para más información.
|
||||
2. Transfiere el snapshot de **`etcd`** fuera del nodo de la manera que prefieras.
|
||||
3. Descomprime la base de datos:
|
||||
```bash
|
||||
@@ -244,7 +245,7 @@ Por lo tanto, los Pods estáticos siempre están **vinculados a un Kubelet** en
|
||||
El **kubelet intenta automáticamente crear un Pod espejo en el servidor API de Kubernetes** para cada Pod estático. Esto significa que los Pods que se ejecutan en un nodo son visibles en el servidor API, pero no pueden ser controlados desde allí. Los nombres de los Pods tendrán un sufijo con el nombre del host del nodo precedido por un guion.
|
||||
|
||||
> [!CAUTION]
|
||||
> El **`spec` de un Pod estático no puede referirse a otros objetos de la API** (por ejemplo, ServiceAccount, ConfigMap, Secret, etc.). Así que **no puedes abusar de este comportamiento para lanzar un pod con un serviceAccount arbitrario** en el nodo actual para comprometer el clúster. Pero podrías usar esto para ejecutar pods en diferentes namespaces (en caso de que eso sea útil por alguna razón).
|
||||
> El **`spec` de un Pod estático no puede referirse a otros objetos API** (por ejemplo, ServiceAccount, ConfigMap, Secret, etc.). Por lo tanto, **no puedes abusar de este comportamiento para lanzar un pod con un serviceAccount arbitrario** en el nodo actual para comprometer el clúster. Pero podrías usar esto para ejecutar pods en diferentes namespaces (en caso de que eso sea útil por alguna razón).
|
||||
|
||||
Si estás dentro del host del nodo, puedes hacer que cree un **pod estático dentro de sí mismo**. Esto es bastante útil porque podría permitirte **crear un pod en un namespace diferente** como **kube-system**.
|
||||
|
||||
@@ -286,7 +287,7 @@ type: Directory
|
||||
### Eliminar pods + nodos no programables
|
||||
|
||||
Si un atacante ha **comprometido un nodo** y puede **eliminar pods** de otros nodos y **hacer que otros nodos no puedan ejecutar pods**, los pods se volverán a ejecutar en el nodo comprometido y podrá **robar los tokens** que se ejecuten en ellos.\
|
||||
Para [**más información, sigue estos enlaces**](abusing-roles-clusterroles-in-kubernetes/index.html#delete-pods-+-unschedulable-nodes).
|
||||
Para [**más información sigue estos enlaces**](abusing-roles-clusterroles-in-kubernetes/index.html#delete-pods-+-unschedulable-nodes).
|
||||
|
||||
## Herramientas Automáticas
|
||||
|
||||
|
||||
@@ -4,25 +4,51 @@
|
||||
|
||||
## Herramientas para analizar un clúster
|
||||
|
||||
### [**Steampipe - Cumplimiento de Kubernetes](https://github.com/turbot/steampipe-mod-kubernetes-compliance)
|
||||
|
||||
Realizará **varias verificaciones de cumplimiento sobre el clúster de Kubernetes**. Incluye soporte para CIS, Agencia de Seguridad Nacional (NSA) y el informe técnico de ciberseguridad de la Agencia de Ciberseguridad e Infraestructura (CISA) para el endurecimiento de Kubernetes.
|
||||
```bash
|
||||
# Install Steampipe
|
||||
brew install turbot/tap/powerpipe
|
||||
brew install turbot/tap/steampipe
|
||||
steampipe plugin install kubernetes
|
||||
|
||||
# Start the service
|
||||
steampipe service start
|
||||
|
||||
# Install the module
|
||||
mkdir dashboards
|
||||
cd dashboards
|
||||
powerpipe mod init
|
||||
powerpipe mod install github.com/turbot/steampipe-mod-kubernetes-compliance
|
||||
|
||||
# Run the module
|
||||
powerpipe server
|
||||
```
|
||||
### [**Kubescape**](https://github.com/armosec/kubescape)
|
||||
|
||||
[**Kubescape**](https://github.com/armosec/kubescape) es una herramienta de código abierto de K8s que proporciona una vista única de K8s en múltiples nubes, incluyendo análisis de riesgos, cumplimiento de seguridad, visualizador de RBAC y escaneo de vulnerabilidades de imágenes. Kubescape escanea clústeres de K8s, archivos YAML y gráficos HELM, detectando configuraciones incorrectas de acuerdo con múltiples marcos (como el [NSA-CISA](https://www.armosec.io/blog/kubernetes-hardening-guidance-summary-by-armo), [MITRE ATT\&CK®](https://www.microsoft.com/security/blog/2021/03/23/secure-containerized-environments-with-updated-threat-matrix-for-kubernetes/)), vulnerabilidades de software y violaciones de RBAC (control de acceso basado en roles) en las primeras etapas del pipeline de CI/CD, calcula el puntaje de riesgo al instante y muestra tendencias de riesgo a lo largo del tiempo.
|
||||
[**Kubescape**](https://github.com/armosec/kubescape) es una herramienta de código abierto para K8s que proporciona una vista única de múltiples nubes de K8s, incluyendo análisis de riesgos, cumplimiento de seguridad, visualizador de RBAC y escaneo de vulnerabilidades de imágenes. Kubescape escanea clústeres de K8s, archivos YAML y gráficos HELM, detectando configuraciones incorrectas de acuerdo con múltiples marcos (como el [NSA-CISA](https://www.armosec.io/blog/kubernetes-hardening-guidance-summary-by-armo), [MITRE ATT\&CK®](https://www.microsoft.com/security/blog/2021/03/23/secure-containerized-environments-with-updated-threat-matrix-for-kubernetes/)), vulnerabilidades de software y violaciones de RBAC (control de acceso basado en roles) en las primeras etapas del pipeline de CI/CD, calcula el puntaje de riesgo al instante y muestra tendencias de riesgo a lo largo del tiempo.
|
||||
```bash
|
||||
curl -s https://raw.githubusercontent.com/kubescape/kubescape/master/install.sh | /bin/bash
|
||||
kubescape scan --verbose
|
||||
```
|
||||
### [**Popeye**](https://github.com/derailed/popeye)
|
||||
|
||||
[**Popeye**](https://github.com/derailed/popeye) es una utilidad que escanea clústeres de Kubernetes en vivo y **informa sobre problemas potenciales con los recursos y configuraciones desplegadas**. Sanitiza tu clúster en función de lo que está desplegado y no de lo que está en disco. Al escanear tu clúster, detecta configuraciones incorrectas y te ayuda a asegurar que las mejores prácticas estén en su lugar, evitando así futuros dolores de cabeza. Su objetivo es reducir la sobrecarga cognitiva que uno enfrenta al operar un clúster de Kubernetes en el mundo real. Además, si tu clúster emplea un metric-server, informa sobre posibles sobre/asignaciones de recursos y intenta advertirte si tu clúster se queda sin capacidad.
|
||||
|
||||
### [**Kube-bench**](https://github.com/aquasecurity/kube-bench)
|
||||
|
||||
La herramienta [**kube-bench**](https://github.com/aquasecurity/kube-bench) es una herramienta que verifica si Kubernetes está desplegado de manera segura al ejecutar las comprobaciones documentadas en el [**CIS Kubernetes Benchmark**](https://www.cisecurity.org/benchmark/kubernetes/).\
|
||||
La herramienta [**kube-bench**](https://github.com/aquasecurity/kube-bench) es una herramienta que verifica si Kubernetes está desplegado de manera segura ejecutando las verificaciones documentadas en el [**CIS Kubernetes Benchmark**](https://www.cisecurity.org/benchmark/kubernetes/).\
|
||||
Puedes elegir:
|
||||
|
||||
- ejecutar kube-bench desde dentro de un contenedor (compartiendo el espacio de nombres PID con el host)
|
||||
- ejecutar un contenedor que instale kube-bench en el host, y luego ejecutar kube-bench directamente en el host
|
||||
- ejecutar un contenedor que instala kube-bench en el host, y luego ejecutar kube-bench directamente en el host
|
||||
- instalar los últimos binarios desde la [página de Releases](https://github.com/aquasecurity/kube-bench/releases),
|
||||
- compilarlo desde el código fuente.
|
||||
|
||||
### [**Kubeaudit**](https://github.com/Shopify/kubeaudit)
|
||||
|
||||
La herramienta [**kubeaudit**](https://github.com/Shopify/kubeaudit) es una herramienta de línea de comandos y un paquete de Go para **auditar clústeres de Kubernetes** por diversas preocupaciones de seguridad.
|
||||
**[DEPRECATED]** La herramienta [**kubeaudit**](https://github.com/Shopify/kubeaudit) es una herramienta de línea de comandos y un paquete de Go para **auditar clústeres de Kubernetes** por diversas preocupaciones de seguridad.
|
||||
|
||||
Kubeaudit puede detectar si se está ejecutando dentro de un contenedor en un clúster. Si es así, intentará auditar todos los recursos de Kubernetes en ese clúster:
|
||||
```
|
||||
@@ -32,13 +58,26 @@ Esta herramienta también tiene el argumento `autofix` para **corregir automáti
|
||||
|
||||
### [**Kube-hunter**](https://github.com/aquasecurity/kube-hunter)
|
||||
|
||||
La herramienta [**kube-hunter**](https://github.com/aquasecurity/kube-hunter) busca debilidades de seguridad en clústeres de Kubernetes. La herramienta fue desarrollada para aumentar la conciencia y visibilidad sobre los problemas de seguridad en entornos de Kubernetes.
|
||||
**[DEPRECATED]** La herramienta [**kube-hunter**](https://github.com/aquasecurity/kube-hunter) busca debilidades de seguridad en clústeres de Kubernetes. La herramienta fue desarrollada para aumentar la conciencia y visibilidad sobre los problemas de seguridad en entornos de Kubernetes.
|
||||
```bash
|
||||
kube-hunter --remote some.node.com
|
||||
```
|
||||
### [Trivy](https://github.com/aquasecurity/trivy)
|
||||
|
||||
[Trivy](https://github.com/aquasecurity/trivy) tiene escáneres que buscan problemas de seguridad y objetivos donde puede encontrar esos problemas:
|
||||
|
||||
- Imagen de contenedor
|
||||
- Sistema de archivos
|
||||
- Repositorio Git (remoto)
|
||||
- Imagen de máquina virtual
|
||||
- Kubernetes
|
||||
|
||||
|
||||
### [**Kubei**](https://github.com/Erezf-p/kubei)
|
||||
|
||||
[**Kubei**](https://github.com/Erezf-p/kubei) es una herramienta de escaneo de vulnerabilidades y de referencia CIS Docker que permite a los usuarios obtener una evaluación de riesgo precisa e inmediata de sus clústeres de Kubernetes. Kubei escanea todas las imágenes que se están utilizando en un clúster de Kubernetes, incluidas las imágenes de los pods de aplicación y los pods del sistema.
|
||||
**[Parece no estar mantenido]**
|
||||
|
||||
[**Kubei**](https://github.com/Erezf-p/kubei) es una herramienta de escaneo de vulnerabilidades y de referencia de CIS Docker que permite a los usuarios obtener una evaluación de riesgo precisa e inmediata de sus clústeres de Kubernetes. Kubei escanea todas las imágenes que se están utilizando en un clúster de Kubernetes, incluidas las imágenes de los pods de aplicación y los pods del sistema.
|
||||
|
||||
### [**KubiScan**](https://github.com/cyberark/KubiScan)
|
||||
|
||||
@@ -46,21 +85,17 @@ kube-hunter --remote some.node.com
|
||||
|
||||
### [Managed Kubernetes Auditing Toolkit](https://github.com/DataDog/managed-kubernetes-auditing-toolkit)
|
||||
|
||||
[**Mkat**](https://github.com/DataDog/managed-kubernetes-auditing-toolkit) es una herramienta diseñada para probar otros tipos de verificaciones de alto riesgo en comparación con otras herramientas. Principalmente tiene 3 modos diferentes:
|
||||
[**Mkat**](https://github.com/DataDog/managed-kubernetes-auditing-toolkit) es una herramienta diseñada para probar otros tipos de verificaciones de alto riesgo en comparación con las otras herramientas. Principalmente tiene 3 modos diferentes:
|
||||
|
||||
- **`find-role-relationships`**: Que encontrará qué roles de AWS se están ejecutando en qué pods.
|
||||
- **`find-role-relationships`**: Que encontrará qué roles de AWS se están ejecutando en qué pods
|
||||
- **`find-secrets`**: Que intenta identificar secretos en los recursos de K8s como Pods, ConfigMaps y Secrets.
|
||||
- **`test-imds-access`**: Que intentará ejecutar pods y acceder a los metadatos v1 y v2. ADVERTENCIA: Esto ejecutará un pod en el clúster, ten mucho cuidado porque tal vez no quieras hacer esto.
|
||||
- **`test-imds-access`**: Que intentará ejecutar pods y tratar de acceder a los metadatos v1 y v2. ADVERTENCIA: Esto ejecutará un pod en el clúster, ten mucho cuidado porque tal vez no quieras hacer esto.
|
||||
|
||||
## **Auditar Código IaC**
|
||||
|
||||
### [**Popeye**](https://github.com/derailed/popeye)
|
||||
|
||||
[**Popeye**](https://github.com/derailed/popeye) es una utilidad que escanea clústeres de Kubernetes en vivo y **informa sobre problemas potenciales con los recursos y configuraciones desplegadas**. Sanitiza tu clúster en función de lo que está desplegado y no de lo que está en disco. Al escanear tu clúster, detecta configuraciones incorrectas y te ayuda a asegurar que las mejores prácticas estén en su lugar, evitando así futuros dolores de cabeza. Su objetivo es reducir la carga cognitiva que uno enfrenta al operar un clúster de Kubernetes en producción. Además, si tu clúster emplea un servidor de métricas, informa sobre posibles sobre/asignaciones de recursos y intenta advertirte si tu clúster se queda sin capacidad.
|
||||
|
||||
### [**KICS**](https://github.com/Checkmarx/kics)
|
||||
|
||||
[**KICS**](https://github.com/Checkmarx/kics) encuentra **vulnerabilidades de seguridad**, problemas de cumplimiento y configuraciones incorrectas de infraestructura en las siguientes **soluciones de Infraestructura como Código**: Terraform, Kubernetes, Docker, AWS CloudFormation, Ansible, Helm, Microsoft ARM y especificaciones OpenAPI 3.0.
|
||||
[**KICS**](https://github.com/Checkmarx/kics) encuentra **vulnerabilidades de seguridad**, problemas de cumplimiento y configuraciones incorrectas de infraestructura en las siguientes **soluciones de Infraestructura como Código**: Terraform, Kubernetes, Docker, AWS CloudFormation, Ansible, Helm, Microsoft ARM y especificaciones OpenAPI 3.0
|
||||
|
||||
### [**Checkov**](https://github.com/bridgecrewio/checkov)
|
||||
|
||||
@@ -70,7 +105,7 @@ Escanea la infraestructura en la nube provisionada utilizando [Terraform](https:
|
||||
|
||||
### [**Kube-score**](https://github.com/zegl/kube-score)
|
||||
|
||||
[**kube-score**](https://github.com/zegl/kube-score) es una herramienta que realiza análisis de código estático de tus definiciones de objetos de Kubernetes.
|
||||
[**kube-score**](https://github.com/zegl/kube-score) es una herramienta que realiza análisis de código estático de las definiciones de objetos de Kubernetes.
|
||||
|
||||
Para instalar:
|
||||
|
||||
@@ -78,8 +113,8 @@ Para instalar:
|
||||
| --------------------------------------------------- | ----------------------------------------------------------------------------------------- |
|
||||
| Binarios preconstruidos para macOS, Linux y Windows | [GitHub releases](https://github.com/zegl/kube-score/releases) |
|
||||
| Docker | `docker pull zegl/kube-score` ([Docker Hub](https://hub.docker.com/r/zegl/kube-score/)) |
|
||||
| Homebrew (macOS y Linux) | `brew install kube-score` |
|
||||
| [Krew](https://krew.sigs.k8s.io/) (macOS y Linux) | `kubectl krew install score` |
|
||||
| Homebrew (macOS y Linux) | `brew install kube-score` |
|
||||
| [Krew](https://krew.sigs.k8s.io/) (macOS y Linux) | `kubectl krew install score` |
|
||||
|
||||
## Consejos
|
||||
|
||||
@@ -97,7 +132,7 @@ Es muy importante **proteger el acceso al servidor API de Kubernetes** ya que un
|
||||
Es importante asegurar tanto el **acceso** (**whitelist** de orígenes para acceder al servidor API y denegar cualquier otra conexión) como la [**autenticación**](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/) (siguiendo el principio de **mínimo** **privilegio**). Y definitivamente **nunca** **permitir** **solicitudes** **anónimas**.
|
||||
|
||||
**Proceso común de solicitud:**\
|
||||
Usuario o K8s ServiceAccount –> Autenticación –> Autorización –> Control de Admisión.
|
||||
Usuario o K8s ServiceAccount –> Autenticación –> Autorización –> Control de admisión.
|
||||
|
||||
**Consejos**:
|
||||
|
||||
@@ -146,7 +181,7 @@ allowPrivilegeEscalation: true
|
||||
|
||||
### Endurecimiento General
|
||||
|
||||
Deberías actualizar tu entorno de Kubernetes tan frecuentemente como sea necesario para tener:
|
||||
Deberías actualizar tu entorno de Kubernetes con la frecuencia necesaria para tener:
|
||||
|
||||
- Dependencias actualizadas.
|
||||
- Correcciones de errores y parches de seguridad.
|
||||
@@ -156,11 +191,18 @@ Deberías actualizar tu entorno de Kubernetes tan frecuentemente como sea necesa
|
||||
**La mejor manera de actualizar un clúster de Kubernetes es (desde** [**aquí**](https://kubernetes.io/docs/tasks/administer-cluster/cluster-upgrade/)**):**
|
||||
|
||||
- Actualiza los componentes del nodo maestro siguiendo esta secuencia:
|
||||
- etcd (t todas las instancias).
|
||||
- etcd (todas las instancias).
|
||||
- kube-apiserver (todos los hosts del plano de control).
|
||||
- kube-controller-manager.
|
||||
- kube-scheduler.
|
||||
- cloud controller manager, si usas uno.
|
||||
- Actualiza los componentes del nodo trabajador como kube-proxy, kubelet.
|
||||
|
||||
## Monitoreo y seguridad de Kubernetes:
|
||||
|
||||
- Kyverno Policy Engine
|
||||
- Cilium Tetragon - Observabilidad de seguridad basada en eBPF y aplicación en tiempo de ejecución
|
||||
- Políticas de seguridad de red
|
||||
- Falco - Monitoreo y detección de seguridad en tiempo de ejecución
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -23,13 +23,13 @@ Para cada ClusterPolicy y Policy, puedes especificar una lista de entidades excl
|
||||
|
||||
Estas entidades excluidas estarán exentas de los requisitos de la política, y Kyverno no aplicará la política para ellas.
|
||||
|
||||
## Ejemplo 
|
||||
## Ejemplo
|
||||
|
||||
Vamos a profundizar en un ejemplo de clusterpolicy : 
|
||||
Vamos a profundizar en un ejemplo de clusterpolicy:
|
||||
```
|
||||
$ kubectl get clusterpolicies MYPOLICY -o yaml
|
||||
```
|
||||
Busca las entidades excluidas : 
|
||||
Busca las entidades excluidas:
|
||||
```yaml
|
||||
exclude:
|
||||
any:
|
||||
@@ -43,12 +43,16 @@ name: system:serviceaccount:TEST:thisisatest
|
||||
- kind: User
|
||||
name: system:serviceaccount:AHAH:*
|
||||
```
|
||||
Dentro de un clúster, numerosos componentes, operadores y aplicaciones añadidos pueden necesitar exclusión de una política de clúster. Sin embargo, esto puede ser explotado al dirigirse a entidades privilegiadas. En algunos casos, puede parecer que un namespace no existe o que no tienes permiso para suplantar a un usuario, lo que puede ser un signo de mala configuración.
|
||||
Dentro de un clúster, numerosos componentes, operadores y aplicaciones añadidos pueden necesitar exclusión de una política de clúster. Sin embargo, esto puede ser explotado al dirigirse a entidades privilegiadas. En algunos casos, puede parecer que un namespace no existe o que careces de permiso para suplantar a un usuario, lo que puede ser un signo de mala configuración.
|
||||
|
||||
## Abusando de ValidatingWebhookConfiguration
|
||||
|
||||
Otra forma de eludir políticas es centrarse en el recurso ValidatingWebhookConfiguration : 
|
||||
Otra forma de eludir políticas es centrarse en el recurso ValidatingWebhookConfiguration:
|
||||
|
||||
{{#ref}}
|
||||
../kubernetes-validatingwebhookconfiguration.md
|
||||
{{#endref}}
|
||||
|
||||
## Más información
|
||||
|
||||
Para más información, consulta [https://madhuakula.com/kubernetes-goat/docs/scenarios/scenario-22/securing-kubernetes-clusters-using-kyverno-policy-engine/welcome/](https://madhuakula.com/kubernetes-goat/docs/scenarios/scenario-22/securing-kubernetes-clusters-using-kyverno-policy-engine/welcome/)
|
||||
|
||||
Reference in New Issue
Block a user