Los atacantes firman applets con certificados robados

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.

http://4.bp.blogspot.com/-AEvP7X2QZJ0/UTcsbBQMvVI/AAAAAAAACU4/9iWKnJCE670/s1600/applet_firmado_1.png

El certificado usado es este:

http://4.bp.blogspot.com/-tRqQqZnvRPs/UTcsjbFR4PI/AAAAAAAACVA/m8PGH4EO5zY/s1600/applet_firmado_2.png

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:\Program
Files\Java\jre7\lib\security\blacklist) desde las últimas versiones.
Pero no dan información sobre cuáles ni por qué.

http://4.bp.blogspot.com/-Xf6GQVLTOAU/UTcsrQ_WIfI/AAAAAAAACVI/SV9Dzs75KBQ/s1600/applet_firmado_3.png

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