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 de 2012, 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... 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 anti-ROP (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 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 riesgo 

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, 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. Las instrucciones para deshabilitarlo 
(independientemente del navegador) para Windows y Mac están en estas 
páginas. 
http://blogs.technet.com/b/mmpc/archive/2012/07/25/how-to-protect-yourself-from-java-based-malware.aspx
y http://osxdaily.com/2012/04/07/tips-secure-mac-from-virus-trojan/. 
Otros métodos de protección incluyen, según el navegador, evitar los 
applets en páginas desconocidas, o directamente evitar el JavaScript 
selectivamente. 

From: hispasec.com

  FEELPCS
www.FEELPCS.com
In god we trust