Java: 4 años de actualizaciones inseguras

Hace tiempo que usar Java en una empresa da la impresión de que es para valientes. Desde que se levantó la libre de que los kits de explotación estaban haciendo más uso de vulnerabilidades en Java que de productos Adobe para distribuir malware, todo el mundo comenzó a preocuparse un poco más por esta plataforma tan popular y extendida de desarrollo de aplicaciones.

Entre los movimientos relativos a Java más llamativos estuvo el cambio de política de Apple que hasta la versión Mac OS X Snow Leopard había llevado Java como bandera y que con el lanzamiento de Mac OS X Lion este verano decidió convertirlo en un Opt-in, al mismo tiempo que discontinuó el soporte para Mac OS X Leopard - SO que se vendió hasta hace 2 años -, dejándolo también sin soporte para parches de seguridad Java. 

El uso de Java en una plataforma Mac OS X o Linux es usado también como base para el lanzamiento de exploits con metasploit contra estas tecnologías, ya que este trae un meterpreter escrito en Java que ayuda a unificar el proceso de explotación, que aunque no es igual que la versión de Windows, sí que trae un buen número de comandos.

Sin embargo, en el uso de esta plataforma dentro de la empresa, y dejando de lado que haya vuelto a quedar mal en un estudio centrado en análisis de vulnerabilidades en programas, la plataforma Java tiene un problema con las actualizaciones que conoce desde el año 2007 y que no ha solucionado: Es vulnerable a Evilgrade.

Las técnicas de evilgrade fueron publicadas por Francisco Amato en la Ekoparty del año 2007 en una charla a la que tuve el gusto de asistir. A grandes rasgos, la vulnerabilidad radica en que el actualizador del software de un programa que se tiene instalado en la máquina no comprueba correctamente el software a instalar, y un atacante puede ejecutar un troyano, o un meterpreter. Aquí, tenéis un ejemplo con MacPorts, que también es vulnerable a evilgrade.  Son muchos los programas vulnerables a evilgrade, y es por ello que unimos la técnica de DNS Cache Snooping a FOCA para mirar qué software era vulnerable a evilgrade en una empresa de forma remota.

Y a esto es vulnerable Java.

Supongamos una máquina con el actualizador de Java comprobando periodicamente si existe alguna nueva versión de Java. Para ello, este programa se conecta a un servidor web que le dice si existe o no, y qué fichero contiene la nueva versión. Así, cuando aparezca una nueva versión, el actualizador de Java se conecta a la URL indicada, se descarga el programa y lo ejecuta en la máquina cliente.

Ahora supongamos un entorno atacado con evilgrade en el que el atacante, mediante un esquema de man in the middle intercepta las peticiones del actualizador y le contesta indicándole que sí que existe una nueva versión, redirigiendo a la víctima hacia un servidor controlado desde el que se le va a entregar no una actualización sino un software malicioso que le permita tomar control de la máquina de la víctima (un ejecutable con una reverse shell, un meterpreter o un troyano).

Esto sucedía con Java allá por el año 2007 y Francisco Amato lo reportó a la entonces Sun Microsystems, que lo "intentó parchear" en Diciembre de 2008.

El intento de parche fue en comprobar que el programa que iba a ejecutar el actualizador viniese firmado por Sun, algo que Francisco Amato se saltó de la forma más sencilla posible: Utilizando el propio Java para ejecutar los programas maliciosos. De esta forma solo hay que ejecutar cualquier programa en Java en la actualización maliciosa, ya que la maquina virtual de Java siempre está firmada por Sun. Aquí el vídeo de la demostración.

Así se quedó la cosa. Sin embargo, tras la publicación de que FinFisher, el troyano que usaban algunos gobiernos, utilizaba como esquema de infección una vulnerabilidad de evilgrade en iTunes que el propio Francisco Amato reportó a Apple hace 3 años y que solo había sido parcheada en la última versión 10.5.1., decidó comprobar si Java todavía era vulnerable a lo que él reportó en el año 2007, para descubrir que sí.

Así que, mucho cuidado con las actualizaciones de Java de tus equipos. Deshabilita el Java Updater y hazlo manualmente en tu casa desde una red de confianza y en tu empresa utilizando algún software de distribución de paquetes, como System Center Configuration Manager, por ejemplo. Por supuesto, ten cuidado con los equipos "perdidos" en tu red, y evita que un usuario fuera del control de tu System Center actualice Java y se metan en tus sistemas de red.

Saludos Malignos!