¡Aquí viene lo útil! Llevarte a explorar el escape de Docker
Docker es una de las tecnologías de contenedores de código abierto más utilizadas en la actualidad, con las ventajas de eficiencia y facilidad de uso. Sin embargo, si se adoptan políticas de seguridad inadecuadas al utilizar Docker, el sistema puede quedar expuesto a amenazas de seguridad.
En esta edición de Anzi Class, el profesor Zhang del Laboratorio ISEC le presentará cómo Docker escapa a un host externo en diferentes entornos.
1. Situaciones de escape al configurar el modo privilegiado
1.--privilegiado (modo privilegiado)
El modo privilegiado se introdujo en Docker en la versión 0.6, permitiendo Root en el contenedor tiene permisos de root en la máquina física externa. Anteriormente, el usuario root en el contenedor solo tenía permisos de usuario ordinarios en la máquina física externa.
El uso del modo privilegiado para iniciar el contenedor puede obtener acceso a una gran cantidad de archivos del dispositivo. Porque cuando el administrador ejecuta docker run --privileged, el contenedor Docker podrá acceder a todos los dispositivos en el host y podrá ejecutar el comando de montaje para montar.
Al controlar un contenedor iniciado en modo privilegiado, el administrador de Docker puede montar el dispositivo de disco host externo en el contenedor mediante el comando de montaje para obtener permisos de lectura y escritura de archivos para todo el host. Además, ejecuta comandos. en la máquina host escribiendo tareas programadas, etc.
Los pasos específicos son los siguientes:
1. Ejecute un contenedor en modo privilegiado: docker run -it --privileged ubuntu: 14.04 /bin/bash
2. Verifique los archivos del disco: fdisk -l
3. Verifique la ruta /dev/ y encontrará muchos archivos de dispositivo: ls /dev
4. Cree un nuevo directorio para montaje: mkdir /abc
5. Monte /dev/sda1 en /abc: mount /dev/sda1 /abc
6. Finalmente, podemos lograr esto accediendo al directorio / ruta abc dentro del contenedor El propósito de acceder a todo el host: ls /abc
7. Intente escribir archivos en el host: echo 123 gt /abc/home/botasky/escape2
8. Ver los archivos del host en: ls /home/botasky/escape2
2.--cap-add y SYS_ADMIN
El kernel de Linux introdujo el mecanismo de capacidades desde la versión 2.2 , rompiendo UNIX /El concepto de superusuario y usuario común en el sistema operativo LINUX permite a los usuarios comunes ejecutar comandos que solo se pueden ejecutar con privilegios de superusuario.
A partir de Linux 3.0, hay 38 capacidades en Linux. Los contenedores Docker están limitados a 14 capacidades de forma predeterminada y los administradores pueden usar las opciones --cap-add y --cap-drop para configurar con precisión las capacidades del contenedor.
Cuando un contenedor se inicia en modo privilegiado, se le otorgarán todas las capacidades. Además, entre las muchas opciones de --cap-add, SYSADMIN significa que el proceso del contenedor puede realizar una serie de operaciones de administración del sistema, como montar y desmontar. Por lo tanto, cuando el contenedor se inicia con --cap-add=. SYSADMIN, también enfrentará amenazas.
2. Situación de escape cuando la configuración de montaje es incorrecta
1. Docker.sock peligroso
Como todos sabemos, Docker adopta la arquitectura C/S, que Generalmente se usa En el comando Docker, Docker es el cliente y el papel del servidor lo desempeña el demonio de Docker. Hay tres métodos de comunicación entre los dos:
Entre ellos, usar docker.sock para la comunicación. es el método predeterminado Cuando el contenedor Cuando un proceso necesita comunicarse con el demonio Docker durante la producción, el contenedor mismo necesita montar el archivo /var/run/docker.sock.
Esencialmente, un proceso que puede acceder al socket de Docker o conectarse a la API HTTPS puede ejecutar cualquier comando que el servicio Docker pueda ejecutar. Un servicio Docker que se ejecuta con privilegios de root generalmente puede acceder a todo el sistema host.
Por lo tanto, cuando el contenedor accede al socket de la ventana acoplable, podemos manipularlo maliciosamente mediante la comunicación con el demonio de la ventana acoplable para escapar. Si el contenedor A puede acceder al socket de la ventana acoplable, podemos instalar el cliente (la ventana acoplable) dentro de él, interactuar con el servidor del host (el demonio de la ventana acoplable) a través de docker.sock, ejecutarlo y cambiar al contenedor B inseguro y, finalmente, en el contenedor B controlar el máquina anfitriona.
Los pasos específicos son los siguientes:
1. Ejecute un contenedor con /var/run/ montado: docker run -it -v /var/run/:/host/var /run /ubuntu: 14.04 /bin/bash
2. Instale Docker como cliente dentro del contenedor (este paso puede requerir cambiar la fuente): apt-get install docker.io
3. Vea la información de Host Docker: docker -H unix:///host/var/run/docker.sock info
4. Ejecute un nuevo contenedor y monte la ruta raíz del host: docker -H unix: /// //host/var/run/docker.sock run -v /：/aa -it ubuntu：14.04 /bin/bash
Puedes ver que el ID de Docker después del símbolo @ ha cambiado :
5. Acceso completo a los recursos del host en la nueva ruta contenedor/aa: ls /aa
3. Escape de situaciones en las que existe la vulnerabilidad Dirty Cow
1. Vulnerabilidad de Dirty Cow (CVE-2016-5195) y VDSO (Virtual Dynamic Shared Object)
Dirty Cow (CVE-2016-5195) es una vulnerabilidad de escalada de privilegios en el kernel de Linux, originada en el Kernel de Linux Existe una condición de carrera en el procesamiento de copia en escritura (Cow) del subsistema de memoria, lo que permite a un usuario malintencionado escalar privilegios y obtener acceso de escritura a otros mapas de memoria de sólo lectura.
Las condiciones de carrera significan que el orden de ejecución de la tarea es anormal, lo que puede causar que la aplicación falle o enfrentar amenazas de ejecución de código por parte de atacantes. Al explotar esta vulnerabilidad, un atacante puede aumentar los privilegios dentro del sistema de destino e incluso obtener privilegios de root. VDSO es un objeto virtual dinámico compartido, que es el .so virtual proporcionado por el kernel.
El archivo .so se encuentra en el kernel en lugar del disco. Cuando se inicia el programa, el kernel asigna la página de memoria que contiene un determinado .so a su espacio de memoria, y el programa correspondiente puede usar las funciones que contiene como un .so normal. .
El uso de la función "clock_gettime()" en el espacio de memoria VDSO en el contenedor puede lanzar un ataque a la vulnerabilidad Dirty Cow, bloquear el sistema y obtener un shell con privilegios de root y explorar archivos en el host. fuera del contenedor.
2.Entorno de verificación PoCamp;
Alguien ha proporcionado un entorno de prueba y PoC en GitHub, que podemos obtener mediante el siguiente comando.
1. Ejecute el contenedor de verificación: docker-compose run dirtycow /bin/bash
2. Inicie nc localmente y observe (la dirección de rebote establecida en el PoC es el puerto local 1234 ) ：nc -lvp 1234
3. Compile el PoC, ejecútelo y espere a que el shell rebote: make & ./0xdeadbeef
A través del comando ID, puede encontrar que este shell tiene permisos de root:
Cita de referencia