Si no actualizas Java, estás infectado

Los applets de Java, unidos a una máquina virtual JRE vulnerable, son hoy por hoy la combinación perfecta para que los atacantes infecten a sus víctimas. No importa qué hábitos se sigan en el sistema: no tener actualizado JRE, es garantía de infección. Veamos por qué y cómo protegerse.

En nuestro laboratorio realizamos habitualmente análisis forenses a máquinas infectadas con troyanos bancarios. Así podemos detectar el binario, aislarlo y estudiar su comportamiento. De esta manera comprobamos cómo y con qué se infecta la gente ahí fuera, en el mundo real donde el malware limpia las cuentas bancarias de los usuarios (una media de 3.000 euros por robo). Entre otros descubrimientos, en los últimos meses,  hemos comprobado que en el 100% de los análisis realizados (y no han sido pocos) la razón de la infección con troyanos bancarios era una máquina virtual Java desactualizada. En concreto dos vulnerabilidades (aunque también otras más antiguas):

• El fallo CVE-2012-0507, corregido el 14 de febrero por Oracle, permite la ejecución de código. Desde entonces, se ha usado para el malware de la policía, los últimos Zbot,SpyEye... y para la botnet de Mac OS X recientemente destapada. Desde el 25 de marzo además, la vulnerabilidad se incorporó a varios kits de explotación usados por atacantes, como Blackhole, de los más completos y sofisticados actualmente. Contra esta vulnerabilidad además, no son efectivos ASLR, DEP o incluso otras técnicas para evitar que los atacantes eludan esas medidas en sus exploits.
     
• CVE-2012-1723. La sucesora de la anterior. Solucionada el 12 de junio por Oracle. Más compleja de ofuscar por los atacantes y diferente, puesto que se trata de un problema en la implementación de la propia JRE.

http://www.microsoft.com/security/portal/blog-images/CVE-2012-1723/CVE-2012-1723-fig2_trend.png 

Cómo suele funcionar el exploit

La víctima visita cualquier web. Cualquiera: desde páginas pornográficas hasta webs de ganchillo (ejemplos reales). No importa el navegador. De forma más o menos transparente (según el navegador) se carga el applet que explota la vulnerabilidad. El usuario quedará infectado. Una curiosidad es que el código Java se encargará de descargar "a trozos" un ejecutable que ensambla en local. También, que el ejecutable será "único" para la víctima. Aunque su funcionalidad sea la de intentar robar las credenciales del banco, su "hash" o firma será diferente en cada caso, y no funcionará en otra máquina que no sea la que ha infectado. Una especie de poliformismo del lado del servidor pero "en tiempo de ensamblado en local".

Por si fuera poco, el malware no necesita de privilegios de administrador para funcionar. Se instala en %appdata%, dentro de un directorio con nombres aleatorios donde suele tener permisos de escritura, y se asegura la supervivencia posicionándose en la rama del registro del usuario CurrenVersion\Run donde también puede escribir.

¿Qué hace mal Oracle?

Oracle no es un buen ejemplo en el campo de la gestión de seguridad. Sun tampoco lo era (la compró en abril de 2009). Por ejemplo, tuvimos que esperar a finales de 2008 para que Sun hiciera algo muy simple: desinstalar las versiones vulnerables cuando un usuario se actualizaba. Sí, dejaban en el sistema la versión vulnerable dentro de la misma rama.

Pero el problema es que en cierta medida, Oracle sigue haciéndolo. Si bien dentro de la misma rama se borran las anteriores... no se eliminan, ni se actualizan, ramas anteriores. Muchos usuarios se encuentran en este momento con dos ramas de JRE en su sistema. La 6 (que va por su update 33), y la 7 (que va por su update 5). Conservar alguna anterior es más que arriesgado. Por ejemplo si con la rama 6 update 18 (arcaica) el usuario decide instalar la última versión 7 update 5 desde la web oficial, se encontrará con esto:

No solo no se elimina la rama 6, sino que tampoco se actualiza de la 18 a la última 33. Ni siquiera advierte del peligro de mantener esa rama. Y lo que es peor... los dos serán accesibles para el atacante desde el navegador.

Oracle tampoco se ha pasado a la "autoactualización", a la que se ha visto obligada Adobe con su Flash recientemente. Primero permitía a los usuarios que se actualizasen libremente. Luego mejoró, con  un mensaje claro cuando aparecía una nueva versión (y en este estadio se encuentra Oracle). Pero más tarde se ha visto obligado a actualizar, sí o sí por defecto, y despreocupar al usuario. Oracle no quiere hacer eso. Tiene pánico a que los diferentes programas no funcionen en sus muchas ramas (todavía actualiza la rama 1.4).

Tal es el problema, que Firefox, Chrome e incluso Safari, bloquean las versiones antiguas de Java, para evitar más infecciones.

Protección

Las medidas de protección son las de siempre... más alguna otra. Por ejemplo, son varios los profesionales como Brian Krebs o Larry Seltzer que directamente aconsejan desinstalar Java por completo. Ambos alegan que no se echará de menos. Esto es discutible y depende del perfil de cada usuario. Pero sí es cierto que, al menos, se debe evitar que sea accesible desde el navegador. Existen varias páginas que ofrecen instrucciones para deshabilitarlo (independientemente del navegador) para Windows y Mac.

Otros métodos de protección incluyen, según el navegador, evitar los applets en páginas desconocidas, o directamente evitar el JavaScript selectivamente.

Más información:

Don’t Need Java? Junk It.

http://krebsonsecurity.com/2010/06/dont-need-java-junk-it/

Java (por fin) eliminará las versiones antiguas al actualizar

http://unaaldia.hispasec.com/2008/10/java-por-fin-eliminara-las-versiones.html

How to protect yourself from Java-based malware

http://blogs.technet.com/b/mmpc/archive/2012/07/25/how-to-protect-yourself-from-java-based-malware.aspx

Ditching Java might be a good move

http://www.net-security.org/secworld.php?id=12136

A Month Without Java: The Results

http://www.pcmag.com/article2/0,2817,2365365,00.asp

Sergio de los Santos

ssantos@hispasec.com

Twitter: @ssantosv