domingo, diciembre 11, 2011

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!

11 comentarios:

Chen dijo...

Muy interesante, Chema. Un saludo!

Adama dijo...

Joé! Mira que le llevo diciendo durante mucho tiempo a mi familia que pueden confiar en el jusched.exe y que instalen siempre las actualizaciones. Ahora me has puesto en un dilema. :)

Te voy a tener que dejar de leer, me estás volviendo en un paranoico. xD

¿No les sería más sencillo comprobar que se descarga de la web de oracle y que se hiciera con conexión segura para evitar el mitm?

Anónimo dijo...

Esto no pasa en Java para Linux Debian/Ubuntu. No existe el java update, todas las actualuzaciones pasan por repositorio. Parte de la culpa la tiene Windows.

Maligno dijo...

@anónimo, parte de la culpa, y toda, la tienen los responsables de Java, no Windows. No es tan difícil firmar y comprobar correctamente las actualizaciones, sea Linux, Windows o SuPadreOS

Saludos!

Tadeo dijo...

Es una lástima que no reparen este problema. Trabajo principalmente con Java. Se lo pasé a mis colegas que también lo usan.
Muchas gracias por la nota.

Anónimo dijo...

"... usar Java en una empresa da la impresión de que es para valientes."

"El uso de Java en una plataforma Mac OS X o Linux es usado también como base para el lanzamiento de exploits"

También podrías haber dicho: "el uso del API 32 de Windows es usado también como base para el lanzamiento de exploits para Windows y distribuir malware para todas las plataformas existentes en el mundo"

Siendo verdad todo lo que dices, esto es un panfleto, pero bueno, como esto es "el lado del mal" es cierto que no hace falta tener rigor, perdón. Sigue así, los fanboys te lo agradecerán.

Maligno dijo...

@anónimo que mal se te da sacar frase de contexto:

"El uso de Java en una plataforma Mac OS X o Linux es usado también como base para el lanzamiento de exploits"

--> Cierto, como se pone en los links.

"... usar Java en una empresa da la impresión de que es para valientes."

--> Cierto, por el estudio de vulnerabilidades en aplicaciones Java descubierta, y el bug no parcheado desde hace 4 años, además de haber sido abandonado el soporte de Java en Mac OS X Leopard, de hace solo 2 años de antigüedad (el último se vendió en Agosto de 2009).

Y si 4 años sin actualizar el bug de Evilgrade te parece que no es una cagada de cojones en seguridad... es que de esto sabes bien poco amigo.

Saludos!

Anónimo dijo...

A mi no me importa lo que piense tu audiencia, aunque ya veo que tú sí estás muy preocupado al darme una respuesta donde hablas de lo que te da la gana y no de lo que yo escribí, eres como un político.

No hay ninguna frase sacada de contexto, hice copy/paste de frases con contexto propio.

Leyendo mi comentario verás que hay un "Siendo verdad todo lo que dices, esto es un panfleto".

Sí me parece una caga lo de Java, en ningún sitio digo lo contrario.

Ahora sigo diciendo, es un panfleto por cómo está redactado y sus enlaces.

Dios, Mac ha pasado de Java. También de Flash, seguro que por sus continuas cagadas en seguridad y no por otros motivos, como comerciales etc, porque ya sabemos que en Mac lo que más les preocupa es la seguridad, tienen unas políticas muy agresivas en ese campor (era irónico).

Dios, desde Java se lanzan exploits, hasta dónde vamos a parar, que lo cierren: "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". Este comentario concreto es impresionante. Java ejecuta programas, no me lo esperaba.

Ya te puse antes que Windows se usa para ver distribuir malware, y pornografía infantil también (tendencioso a propósito).

El enlace "haya vuelto a quedar mal en un estudio centrado en análisis de vulnerabilidades en programas" es otro enlace impresionante, el título acojona:
"Mala codificación afecta las aplicaciones de negocios, especialmente en Java". Mezclando programación e infraestructura. Es decir, que como los programadores la cagan, la plataforma es una mierda, genial. En ese mismo artículo que tú citas dice:

"Java no fue el peor en términos de seguridad, ya que .NET resultó con el peor puntaje de seguridad y Cobol con el mejor."

Vamos, que .NET es una porquería en seguridad. Chicos, no useis .NET que es una mierda, abajo Windows y .NET.(WTF?)

Mira, paso de seguir discutiendo gilipolleces, has escrito un panfleto, y es una cagada por tu parte. Deberías corregirlo y punto, todo el mundo tiene derecho a equivocarse y tú con más de un post diarios también, pero está mal eso de no "mantenella y no enmendalla"

Maligno dijo...

@Anónimo, como veo que no te has leído bien el post te lo vuelvo a explicar.

Se ha demostrado que los kits de exploits, como BlackHole o Eleonore, y los DIY usan principalmente exploits para Java por tres motivos:

- Hay highly crítcial fácilmente explotables.
- Funcionan en todos los navegadores y plataformas adaptando el payload.
- No suele actualizarse Java en todos los sitios.

Te hubiera puesto los links, pero creo que eres mayorcito para verlo tú.

Si no lo entiendes, lo siento. Y no me hables de político, yo doy la cara y tú eres el que escribe en anónimo, como un "cobardica". };))

Saludos Malignos!

Anónimo dijo...

Gracias por el aviso. Ahora ando preocupado por la última actualización de java que instalé en "mi" red doméstica.
(Espero que el vecino no controle este tipo de técnicas ;) )

lost-perdidos dijo...

¡Muy buen artículo! Felicitaciones.

Entradas populares