0-day en Java 1.7.x sin parche oficial: resumen de ideas y análisis |
El pasado domingo se publicó una vulnerabilidad en el blog de FireEye que afecta a la última versión de Java (1.7.x) y que se utilizó en un ataque dirigido, usando el RAT Poison Ivy como malware ejecutado, y con poca propagación del exploit. Eso fue hasta que se publicó el código fuente en pastie.org, como antesala de la publicación de un módulo de Metasploit. El código asignado para esta vulnerabilidad es CVE-2012-4681.
A partir de la publicación del código fuente y el módulo de Metasploit, el exploit ya era de dominio público, por lo que era cuestión de tiempo que se incluyera en las últimas versiones de conocidos exploit kits como BlackHole. Eso mismo ocurrió ayer, y surgieron gran cantidad de dominios sirviendo la nueva vulnerabilidad. Eso no significa que hasta ahora no se hubiera incluido en otros exploit kits menos conocidos y detectados, ya que parece que el exploit está activo al menos desde mediados de agosto, sino que simplemente no estaba tan difundido como lo está en estos momentos. Lo más importante de todo es que esta vulnerabilidad no tiene parche oficial por parte de Oracle y tampoco se han pronunciado al respecto, por lo que la situación es bastante peligrosa y se espera un alto número de infecciones. De hecho, ya se ha visto el uso de este exploit para la descarga y ejecución de Citadel.
El exploit se ejecuta a través de las clases contenidas en un applet. En el ataque mencionado por FireEye para llegar a este applet se tenían que pasar por diferentes etapas de Javascript ofuscado con la versión 0.44 del ofuscador Dadong's JSXX (“Encrypted by Dadong's JSXX 0.44 VIP” aparece en el código). Tanto en la llamada al applet como en las propias clases de Java (Gondvv.class y Gondzz.class) hay referencias a palabras en chino, que podría ser la nacionalidad de los atacantes (o un simple engaño):
xiaomaolv = Little donkey
woyouyizhixiaomaolv = I have a small donkey
conglaiyebuqi = Never ride
En un principio parecía que se trataba de una única vulnerabilidad, pero Esteban Guillardoy de Immunity comenta que no es una sino dos vulnerabilidades las que se encuentran en el exploit, concretamente en las funciones MethodFinder.findMethod y com.sun.beans.finder.ClassFinder.findClass. Como se indica en su artículo esta sería la explicación de lo que ocurre al ejecutarlo:
- Creación de una instancia Statement que llama al método System.setSecurityManager(null) usando reflexión.
- Creación de un AccessControlContext con permisos totales.
- Con uno de los bugs (ClassFinder) se obtiene una referencia a la clase sun.awt.SunToolkit, normalmente restringida en applets.
- Con el otro bug (MethodFinder) se llama al método estático y público getField de sun.awt.SunToolkit usando reflexión con un método de confianza, evitando las medidas de seguridad.
- Gracias al método getField se obtiene una referencia al campo privado Statement.acc y su valor se cambia con el de la instancia de AccessControlContext, anteriormente creada (con permisos totales).
- Finalmente se ejecuta el Statement que desactivará el Security Manager, evitará todas las medidas de seguridad y dará permisos totales para ejecutar cualquier cosa. En este caso descargar y ejecutar un binario.
Como ya se ha adelantado, las vulnerabilidades afectan a la versión 1.7.x de Java, pero no a versiones previas, de la rama 1.6.x, por ejemplo. No existe un parche oficial actualmente, pero, sin embargo, no se recomienda el downgrade a versiones anteriores, ya que puede provocar la exposición a antiguas vulnerabilidades. Los navegadores en los que esta vulnerabilidad se puede explotar con éxito son Internet Explorer, Firefox y Opera, aunque desde Rapid7 se está trabajando en un módulo para Metasploit que funcione correctamente en Chrome. Investigadores de seguridad han anunciado que poseen un parche no oficial y que puede ser aplicado sin miedo, aunque la recomendación principal pasaría por deshabilitar Java en los navegadores web hasta que Oracle libere un parche oficial. Se puede visitar esta página, creada por Rapid7, para comprobar si tienes habilitado Java en el navegador y si tu versión es vulnerable.
Como curiosidad, el paquete Java que engloba las dos clases que forman parte del exploit tiene como nombre "cve2012xxxx", que parece un poco raro y muy poco cuidadoso si quiere ocultarse. Si además tenemos en cuenta la ausencia de ofuscación del código, que se decompila perfectamente, más otros hechos similares parece que existía un deseo de que el exploit fuera ampliamente detectado. Son sólo suposiciones e hipótesis, pero dá qué pensar...
Actualización (31-08-2012): Finalmente Oracle publicó ayer un parche que soluciona esta vulnerabilidad y otras tres más. Se ha conocido también que la vulnerabilidad CVE-2012-4681 fue reportada por Security Explorations hace cuatro meses. Esta misma empresa ha asegurado que la actualización de Oracle publicada ayer no cubre otras vulnerabilidades que reportaron en abril de este año.
Nota: Publicado originalmente en el blog de S21sec
