<summary><strong>Aprende a hackear AWS desde cero hasta convertirte en un experto con</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Si deseas ver tu **empresa anunciada en HackTricks** o **descargar HackTricks en PDF** Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Obtén [**artículos oficiales de PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubre [**La Familia PEASS**](https://opensea.io/collection/the-peass-family), nuestra colección exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Únete al** 💬 [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **sígueme** en **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Comparte tus trucos de hacking enviando PRs a los** [**HackTricks**](https://github.com/carlospolop/hacktricks) y [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositorios de github.
La Plataforma Docker es la plataforma de contenedores líder en la industria para una innovación continua y de alta velocidad, que permite a las organizaciones construir y compartir de manera fluida cualquier aplicación, desde legado hasta lo que viene a continuación, y ejecutarlas de forma segura en cualquier lugar.
* [containerd](http://containerd.io) es un tiempo de ejecución de contenedores que puede **gestionar todo el ciclo de vida de un contenedor, desde la transferencia/almacenamiento de imágenes hasta la ejecución del contenedor**, supervisión y redes. **Más información sobre containerd a continuación.**
* container-shim maneja contenedores sin cabeza, lo que significa que una vez que runc inicializa los contenedores, sale entregando los contenedores al container-shim que actúa como intermediario.
* [runc](http://runc.io) es un tiempo de ejecución de contenedores universal y ligero, que cumple con la especificación OCI. **runc es utilizado por containerd para generar y ejecutar contenedores según la especificación OCI**. También es el empaquetado de libcontainer.
* [grpc](http://www.grpc.io) se utiliza para la comunicación entre containerd y docker-engine.
* [OCI](https://www.opencontainers.org) mantiene la especificación OCI para tiempo de ejecución e imágenes. Las versiones actuales de Docker admiten las especificaciones de imagen y tiempo de ejecución OCI.
Containerd fue diseñado para ser utilizado por Docker y Kubernetes, así como por cualquier otra plataforma de contenedores que desee **abstraer las llamadas al sistema o la funcionalidad específica del sistema operativo para ejecutar contenedores** en Linux, Windows, Solaris u otros sistemas operativos. Con estos usuarios en mente, queríamos asegurarnos de que containerd tenga solo lo que necesitan y nada más. Realísticamente esto es imposible, pero al menos eso es lo que intentamos. Cosas como **la red están fuera del alcance de containerd**. La razón de esto es que, al construir un sistema distribuido, la red es un aspecto muy central. Con SDN y el descubrimiento de servicios hoy en día, la red es mucho más específica de la plataforma que abstraer las llamadas de netlink en Linux.
Ten en cuenta que **Docker utiliza Containerd, pero solo proporciona un subconjunto de las características que Docker ofrece**. Por ejemplo, ContainerD no tiene las características de gestión de red de Docker, ni puedes usar ContainerD solo para crear enjambres de Docker.
Un motor de contenedores de código abierto y compatible con OCI ([Open Container Initiative](https://github.com/opencontainers)) conocido como Podman es mantenido por Red Hat. Se caracteriza por varias distinciones clave con respecto a Docker, incluida su estructura sin demonio y el soporte para contenedores que no requieren acceso de root. La función principal de ambas herramientas es gestionar imágenes y contenedores. Un objetivo notable de Podman es la compatibilidad con la API de Docker, lo que permite el uso de casi todos los comandos de CLI de Docker dentro de Podman.
Dentro del ecosistema de Podman, se encuentran dos herramientas adicionales, Buildah y Skopeo. Buildah sirve como una herramienta de CLI para construir imágenes de contenedores, mientras que Skopeo se utiliza para operaciones en imágenes como push, pull o inspectar. Para obtener más información sobre estas herramientas y su integración con Podman, [consulte su página de GitHub](https://github.com/containers/buildah/tree/master/docs/containertools).
La diferencia más significativa entre Docker y Podman radica en su diseño arquitectónico. Docker opera en un modelo cliente-servidor, lo que requiere el uso de la CLI de Docker para interactuar con un demonio en segundo plano responsable de la construcción de imágenes y la ejecución de contenedores, que opera con privilegios de root. En contraste, Podman emplea una arquitectura sin demonio, lo que permite que los contenedores se ejecuten bajo los privilegios del usuario iniciador sin necesidad de acceso de root. Este diseño garantiza que los usuarios de Podman solo puedan interactuar con sus propios contenedores, sin un demonio compartido para la comunicación de CLI.
Para dar cabida a la operación de contenedores en segundo plano sin un demonio, Podman se integra con **systemd**, lo que permite la gestión de contenedores a través de unidades de systemd. Esta integración varía con la versión de Podman, ofreciendo la capacidad de generar unidades tanto para contenedores existentes como para aquellos que aún no se han creado, así como facilitando la operación de systemd dentro de los contenedores. A diferencia de Podman, Docker tradicionalmente depende de systemd para la gestión de procesos de demonio.
Otra diferencia crítica radica en la ejecución de contenedores. Podman permite que los contenedores se ejecuten con los privilegios del usuario iniciador, no bajo un demonio. Esto introduce el concepto de contenedores sin root, que pueden iniciarse sin acceso de root, ofreciendo una ventaja de seguridad significativa al limitar el impacto potencial de violaciones de contenedores. Los contenedores sin root garantizan que el atacante de un contenedor comprometido posea solo los privilegios de un usuario normal en el host, evitando la escalada de privilegios más allá de los del usuario iniciador y, por lo tanto, mejorando la seguridad.
Tenga en cuenta que dado que Podman tiene como objetivo admitir la misma API que Docker, puede utilizar los mismos comandos con Podman que con Docker, como:
El API remoto se ejecuta de forma predeterminada en el puerto 2375 cuando está habilitado. El servicio, por defecto, no requerirá autenticación, lo que permite a un atacante iniciar un contenedor de Docker privilegiado. Al utilizar el API remoto, se puede adjuntar hosts / (directorio raíz) al contenedor y leer/escribir archivos del entorno del host.
Si puedes **contactar el API remoto de docker con el comando `docker`** puedes **ejecutar** cualquiera de los **comandos de docker** [**previamente comentados**](2375-pentesting-docker.md#basic-commands) para interactuar con el servicio.
A veces verás **2376** disponible para el punto final de **TLS**. No he podido conectarme a él con el cliente de docker, pero puedes hacerlo con curl sin problemas para acceder a la API de docker.
Si deseas obtener más información al respecto, puedes encontrar más información en el sitio desde donde copié los comandos: [https://securityboulevard.com/2019/02/abusing-docker-api-socket/](https://securityboulevard.com/2019/02/abusing-docker-api-socket/)
Abusando de esto es posible escapar de un contenedor, podrías ejecutar un contenedor débil en la máquina remota, escapar de él y comprometer la máquina:
Si te encuentras dentro de un host que está utilizando Docker, puedes [**leer esta información para intentar elevar privilegios**](../linux-hardening/privilege-escalation/#writable-docker-socket).
* Puedes usar la herramienta [https://github.com/docker/docker-bench-security](https://github.com/docker/docker-bench-security) para inspeccionar tu instalación actual de Docker.
* Puedes usar la herramienta [https://github.com/genuinetools/amicontained](https://github.com/genuinetools/amicontained) para conocer los privilegios que tendrá un contenedor al ejecutarse con diferentes opciones de seguridad. Esto es útil para comprender las implicaciones de usar ciertas opciones de seguridad para ejecutar un contenedor:
*`docker run --rm -it r.j3ss.co/amicontained`
*`docker run --rm -it --pid host r.j3ss.co/amicontained`
*`docker run --rm -it --security-opt "apparmor=unconfined" r.j3ss.co/amicontained`
* Puedes usar una imagen de Docker de [https://github.com/quay/clair](https://github.com/quay/clair) para escanear tus otras imágenes de Docker y encontrar vulnerabilidades.
* Puedes usar la herramienta [https://github.com/buddy-works/dockerfile-linter](https://github.com/buddy-works/dockerfile-linter) para **inspeccionar tu Dockerfile** y encontrar todo tipo de configuraciones incorrectas. A cada configuración incorrecta se le asignará un ID, puedes encontrar aquí [https://github.com/buddy-works/dockerfile-linter/blob/master/Rules.md](https://github.com/buddy-works/dockerfile-linter/blob/master/Rules.md) cómo corregir cada una de ellas.
* Puedes usar la herramienta [https://github.com/replicatedhq/dockerfilelint](https://github.com/replicatedhq/dockerfilelint) para **inspeccionar tu Dockerfile** y encontrar todo tipo de configuraciones incorrectas.
* Puedes usar la herramienta [https://github.com/RedCoolBeans/dockerlint](https://github.com/RedCoolBeans/dockerlint) para **inspeccionar tu Dockerfile** y encontrar todo tipo de configuraciones incorrectas.
* Puedes usar la herramienta [https://github.com/hadolint/hadolint](https://github.com/hadolint/hadolint) para **inspeccionar tu Dockerfile** y encontrar todo tipo de configuraciones incorrectas.
* Puedes usar la herramienta [https://github.com/falcosecurity/falco](https://github.com/falcosecurity/falco) para detectar **comportamientos sospechosos en contenedores en ejecución**.
* Observa en el siguiente fragmento cómo **Falco compila un módulo del kernel e lo inserta**. Después de eso, carga las reglas y **comienza a registrar actividades sospechosas**. En este caso, ha detectado 2 contenedores privilegiados iniciados, 1 de ellos con un montaje sensible, y después de algunos segundos detectó cómo se abrió una terminal dentro de uno de los contenedores.
mkdir: cannot create directory '/lib/modules/5.0.0-20-generic/kernel/extra': Read-only file system
cp: cannot create regular file '/lib/modules/5.0.0-20-generic/kernel/extra/falco-probe.ko': No such file or directory
depmod...
DKMS: install completed.
* Trying to load a dkms falco-probe, if present
falco-probe found and loaded in dkms
2021-01-04T12:03:20+0000: Falco initialized with configuration file /etc/falco/falco.yaml
2021-01-04T12:03:20+0000: Loading rules from file /etc/falco/falco_rules.yaml:
2021-01-04T12:03:22+0000: Loading rules from file /etc/falco/falco_rules.local.yaml:
2021-01-04T12:03:22+0000: Loading rules from file /etc/falco/k8s_audit_rules.yaml:
2021-01-04T12:03:24+0000: Starting internal webserver, listening on port 8765
2021-01-04T12:03:24.646959000+0000: Notice Privileged container started (user=<NA> command=container:db5dfd1b6a32 laughing_kowalevski (id=db5dfd1b6a32) image=ubuntu:18.04)
2021-01-04T12:03:24.664354000+0000: Notice Container with sensitive mount started (user=<NA> command=container:4822e8378c00 xenodochial_kepler (id=4822e8378c00) image=ubuntu:modified mounts=/:/host::true:rslave)
2021-01-04T12:03:24.664354000+0000: Notice Privileged container started (user=root command=container:4443a8daceb8 focused_brahmagupta (id=4443a8daceb8) image=falco:latest)
2021-01-04T12:04:56.270553320+0000: Notice A shell was spawned in a container with an attached terminal (user=root xenodochial_kepler (id=4822e8378c00) shell=bash parent=runc cmdline=bash terminal=34816 container_id=4822e8378c00 image=ubuntu)