Si Usted es de las personas que no actualizan en su computadora Java JRE, ¡Puede estar infectada!, pues hoy por hoy la combinación perfecta para que los atacantes infecten a sus víctimas son: una máquina virtual JRE vulnerable mas los applets de Java. No importa qué hábitos se sigan en el sistema: o sea puede tener actualizado el sistema operativo, el o los navegadores, Flash Player, etc, pero si no tiene actualizado Java JRE, es garantía de infección. Veamos por qué y cómo debe protegerse.

En el laboratorio de Hispasec realizan habitualmente análisis forenses a computadoras infectadas con troyanos bancarios. Así pueden detectar el binario, aislarlo y estudiar su comportamiento. De esta manera comprueban cómo y con qué se infecta el usuario ahí fuera, en el mundo real donde el malware limpia las cuentas bancarias de los usuarios (con una media de 3.000 euros por robo). Entre otros descubrimientos, en los últimos meses,  han 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 por dos vulnerabilidades (aunque también hay otras más antiguas):

  • La vulnerabilidad CVE-2012-0507, corregida 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 recientemente descubierta botnet de Mac OS X . Además, desde el 25 de marzo del 2012 la vulnerabilidad se incorporó a varios kits de explotación usados por atacantes, como Blackhole, el cual es de los más completos y sofisticados actualmente. Además, contra esta vulnerabilidad , no son efectivos ASLR, DEP o incluso otras técnicas anti-ROP (para evitar que los atacantes eludan esas medidas en sus exploits).
  • CVE-2012-1723. La sucesora de la vulnerabilidad anterior. Solucionada el 12 de junio por Oracle. Diferente y más compleja de ofuscar por los atacantes, puesto que se trata de un problema en la implementación de la propia Java JRE.

 

Cómo puede funcionar el exploit

La víctima puede visitar cualquier web. Cualquiera: desde páginas pornográficas hasta webs de gancho (ejemplos reales). No importa el navegador que esté utilizando. De forma más o menos transparente según el navegador se carga el applet que explota la vulnerabilidad y el usuario quedará infectado. Una curiosidad es que el propio código Java se encargará de descargar a trozos un ejecutable que se ensambla en local y también, que el ejecutable será único para la computadora de 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 computadora que no sea la que ha infectado. Una especie de polimorfismo del lado del servidor pero en tiempo de ensamblado en local.

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

¿Qué hace Oracle mal?

En el campo de la gestión de seguridad la compañía Oracle no es un buen ejemplo. Ni tampoco lo era Sun (la cual fue comprada por Oracle en abril del 2009). Por ejemplo, hubo que esperar a finales del año 2008 para que Sun hiciera algo muy simple: cuando un usuario actualizaba Java JRE es desinstalar las versiones vulnerables. Pues simplemente dejaban en el sistema la versión vulnerable dentro de la misma rama.

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

Al instalar la versión 7 update 5, no se elimina la rama 6, sino que tampoco se actualiza del update 18 al último update el 33. Ni siquiera advierte del peligro de mantener esa rama. Y lo que es peor… las 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 recientemente la compañía Adobe con su Flash el cual 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 ese limbo se encuentra Oracle). Pero más tarde se ha visto obligada a actualizarse por defecto, y despreocupar al usuario. Oracle no quiere hacer eso, pues le tiene pánico a que los diferentes programas no funcionen en sus muchas ramas (todavía actualiza la rama 1.4).

De tal importancia es el problema, que para evitar más infecciones los navegadores Firefox, Chrome e incluso también Safari, bloquean las versiones antiguas de Java.

Medidas de Protección

Más alguna que otra, las medidas de protección son las de siempre…. La primera es tener actualizadas las versiones de Java y desinstalar las antiguas, también por ejemplo: hay varios profesionales como Brian Krebs o Larry Seltzer (enlaces a páginas en inglés) que son más directos pues aconsejan desinstalar por completo a Java. Ambos alegan que no se le echará de menos. Esta acción es discutible y va a depender del perfil de cada usuario. Pero lo que sí es cierto que, al menos, se debe evitar que sea accesible desde el navegador. Para deshabilitarlo independientemente del navegador que utilice el usuario, existen varias páginas web que ofrecen instrucciones de cómo hacerlo en los sistemas operativos Windows y Mac (enlaces a páginas en inglés).

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

Fuente: hispasec.com