Me imagino como escenario el bunker secreto de Oracle, en algún desierto inhóspito de Nevada. En la mesa, muffins decorados con substancias de alto contenido calorico de forma cremosa, grandes cantidades de cafe insipido y unas carpetas azulgrana recién impresas.
El objetivo de la reunión... terminar con la golpiza mediática que reciben diariamente por su gran cantidad de vulnerabilidades.
Con el pasar del tiempo, la discusión se va poniendo cada vez mas caliente. Hay quienes sugieren incrementar el presupuesto de seguridad, otros acallar las voces de los investigadores ya sea contratándolos (el Caso Sami Koivu) o utilizando métodos menos ortodoxos. Inclusive, un desarrollador que lleva años en la empresa, sugiere la estrámbotica idea de implementar una SDL, pero rápidamente, se llama al silencio frente a las miradas atónitas de sus compañeros.
Quien parece ser el jefe, sentado en la punta de la mesa, se pone de pie, se acomoda la corbata y dice firmemente "Mañana la actualización de Java comienza con un nivel de seguridad Alto".
Puede ser que algo así haya ocurrido, o no. Lo cierto es que a partir del update 11 de Java 7, todas las instalaciones venían con ese nivel de seguridad. Y esto, traducido los que nos dedicamos a la seguridad ofensiva significa "Los applet de Java no corren ya de forma silenciosa", o por lo menos, eso creíamos....
La cuestión es que si uno ingresa a una web que está sirviendo un applet, recibirá un pop-up que le advierte sobre los peligros de ejecutar una aplicación de Java.
Y esto, para un atacante es casi una sentencia de muerte.
Es verdad, posiblemente un estudio de alguna universidad perdida de Massachusetts, indique que el 65% de los usuarios siempre dan aceptar a la ventana y esto ayuda a tener mejor sexo y prevenir el cancer, pero el punto es que ya no es mas silencioso.
Es más... las vulnerabilidades de Java ya no tienen sentido, porque por el mismo precio (una ventana con un warning), uno puede auto-firmar un applet y cuando el usuario acepta la ventana, el applet corre por fuera de la sandbox. Win.
Pero dejénme que les diga algo, los investigadores somos inconformistas y por sobre todo, tenemos una cierta tendencia a estar en contra de la ley. Es por eso, que charlando con nuestro experto en Java (tm) Esteban decidimos que esto no podia quedar así. En definitiva, estábamos hablando de Java, la empresa que hace que mitre dude si agregar un digito mas al CVE por la cantidad de bugs anuales que reciben de Oracle.
Asi fue que Esteban se embarcó en el proyecto, y a los 15 minutos, ya estaba listo.
Bug? Característica? Bochorno?
Posiblemente todos juntos. El gran punto a tener cuenta es que el cambio de nivel de seguridad era la gran novedad de esta release. El mundo de la seguridad se focalizó por un instante en esto, y en las consecuencia que esto traería.
Lo que nadie esperó, y muchos menos nosotros, es que fuese tan simple bypassearlo.
Lo primero que notarán, es que un applet se puede inicializar de dos formas distintas. A través de un objeto serializado (variable str1) o a través de CODE (variable str2), como lo muestran las líneas 7 y 8.
Si uno sigue la forma habitual de servir un applet, a traves de CODE, notará que en la linea 41 se llama a fireAppletSSVValidation() que es la función encargada de desplegar el pop-up de advertencia y largar una horrible excepción en el caso que no se acepte ejecutar el applet.
Y ahora, es cuando el lector sagaz se pregunta "Y si seguimos el code-flow de un objeto serializado?" y es también, cuando ese mismo lector se golpea contra su escritorio en rápidos intervalos.
Porque es así, Java se olvidó completamente de llamar a fireAppletSSVValidation para un objeto serializado. Por esto mismo, es que el fix que largó Java hace unos días simplemente agrega una llamada a esta función y nada mas.
Si quieren probarlo en sus casas, pueden levantar su applet (previa serialización) de la siguiente forma:
Si uno sigue la forma habitual de servir un applet, a traves de CODE, notará que en la linea 41 se llama a fireAppletSSVValidation() que es la función encargada de desplegar el pop-up de advertencia y largar una horrible excepción en el caso que no se acepte ejecutar el applet.
Y ahora, es cuando el lector sagaz se pregunta "Y si seguimos el code-flow de un objeto serializado?" y es también, cuando ese mismo lector se golpea contra su escritorio en rápidos intervalos.
Porque es así, Java se olvidó completamente de llamar a fireAppletSSVValidation para un objeto serializado. Por esto mismo, es que el fix que largó Java hace unos días simplemente agrega una llamada a esta función y nada mas.
Si quieren probarlo en sus casas, pueden levantar su applet (previa serialización) de la siguiente forma:
<embed object="object.ser" type="application/x-java-applet;version=1.6">
¿Es este el final de Java? No lo creo, en base a nuestra experiencia de años desarrollando exploits para CANVAS, siempre hay una forma mas de explotar oculta, sólo es cuestión de saber encontrarla.
Nico Waisman
