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.
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.
Java (por fin) eliminará las
versiones antiguas al actualizar
How to protect yourself from Java-based malware
Ditching Java might be a good move
A Month Without Java: The Results
Sergio de los Santos
Twitter: @ssantosv
