La seguridad en Java sigue siendo un desastre. Además de los últimos 0-day y actualizaciones (al menos parece que sacan rápido nuevas correcciones), se ha encontrado un applet firmado con un certificado robado. Este applet no aprovecha una vulnerabilidad, sino que el hecho de estar firmado le permite comprometer el equipo. Además, en este caso concreto, la configuración de Java por defecto demasiado relajada, ayuda al atacante.

Malware Domain List anunció en Twitter que había encontrado un Jar que descargaba archivos maliciosos, incluso en la última versión conocida.

La primera impresión, por supuesto, fue la de encontrarse ante un nuevo 0-day. Teniendo en cuenta los últimos acontecimientos y que el año pasado la mitad de las infecciones vinieron por Java, era lo más lógico.

Por cierto, el último episodio (encontrado el día 28 siendo explotado y arreglado muy recientemente) se diferenciaba sustancialmente de los fallos anteriores. Este aprovechaba una vulnerabilidad en la propia máquina virtual, no un problema de escapada de la “sandbox”, como se ha venido haciendo últimamente. Pero no, este Jar no aprovechaba ningún fallo.

Había sido descargado de un sitio comprometido que, por supuesto, habían convertido en un punto de infección con un Exploit Kit. Lo “interesante” de este Jar es que no aprovecha nada extraño, solo que está firmado.

Como ya mencionados en la serie dedicada a Java hace unas semanas, los applets firmados son como ejecutables en los que confía el sistema totalmente.

Han firmado el applet con un certificado robado de una empresa que existe. Aunque a la víctima le aparece un mensaje, no es extraño que muchos confíen en él y lo ejecuten.

 

El certificado usado es este:

 

 

Con esta simple técnica, no necesitan de vulnerabilidades.

Pero la culpa sigue siendo de Java

Una nota curiosa, es que este applet estaba firmado con un certificado que fue revocado por GoDaddy el día 7 de diciembre (descubierto por Jindrich Kubec). En teoría, Java debería haberlo bloqueado, mirando la lista de certificados revocados de GoDaddy online (http://crl.godaddy.com/gds5-16.crl). ¿Por qué no lo ha hecho? Simple: esta opción no está activa por defecto. Como estudiamos en una-al-día anteriores, era una posibilidad para los atacantes ahora que la seguridad por defecto de Java está en “alta” y los applets no firmados no se ejecutarán sin preguntar. Con estos certificados robados, el ataque es más realista (aunque no tanto… la diferencia entre diálogos no es tanta). En ese momento recomendábamos activar la opción “Comprobar certificados para la revocación mediante listas de revocación”. Esto significa que se comprueba “online” si un certificado ha sido revocado.

Como no se hace por defecto, todo el sistema se invalida: basta con firmar un applet con un certificado (revocado o no), el usuario que no haya modificado esa opción no percibirá diferencia alguna.

 

Otra cosa es que Java haya incluido en su lista negra el certificado (cosa que no ha ocurrido). Sí que ha incluido dos nuevos bloqueos de applets en su lista negra (C:\ProgramFiles\Java\jre7\lib\security\blacklist) desde las últimas versiones.

Pero no dan información sobre cuáles ni por qué.

Quizás este caso sea anecdótico y no muestre una tendencia, pero parece relevante. En cualquier caso, en estos días la seguridad en Java está dando tanto que hablar, que han creado dos páginas “interesantes”:

* Una web que establece una línea de tiempo entre los 0-days encontrados y sus soluciones (para aclarar un poco el asunto):

http://eromang.zataz.com/uploads/oracle-java-exploits-0days-timeline.html

* Otra, un poco menos útil, que nos permite saber de un vistazo cuántos días lleva sin aparecer un 0-day en Java.

Fuente: Hispasec
Autor: Sergio de los Santos
Publicación realizada con autorización de la fuente.

Image: mack2happy / FreeDigitalPhotos.net

Descargar artículo en formato PDF