(In)Seguridad en Java: La biografía no autorizada

El otro día fui a una cafetería, de esas donde escriben tu nombre en el vaso y pedí mi tradicional café frappuccino Java Chip. Me dijeron que ya no se llama Java Chip, sino solamente Chip, así que me resigné a tomarlo así, sin Java, y me fui de ahí pensando en una nueva metáfora: muchos se están deshaciendo de Java, la popular plataforma de desarrollo, no saben por qué, pero lo están desinstalando.

Algo ha estado pasando últimamente con Java (la plataforma de cómputo diseñada pensando en la seguridad) que ha sido el blanco perfecto para explotar una serie de vulnerabilidades encontradas hace apenas unos meses. Siendo precisos, Java no sólo es un lenguaje de programación sino una de las tecnologías con mayor presencia en el mundo, lo que le ha valido ser uno de los objetivos más codiciados por los creadores de malware en los últimos años.

Después de darle un sorbo a mi café frappé, pienso ¿Qué tan malo puede ser Java?

Un poco de historia

La plataforma Java fue creada por Sun Microsystems a mediados de los 90, no sólo pensando en que tuviera la capacidad de ejecutarse en cualquier plataforma sino también en que fuera segura. Se incorporaron características de seguridad que no tenía ningún otro lenguaje o plataforma de su época, como el verificador de clases (Class Verifier), que se asegura de usar versiones de los programas sin alterar, o el administrador de seguridad (Security Manager) que ayuda a controlar quiénes tienen acceso a ciertos métodos o recursos de la aplicación. Incluso la interfaz para programación de aplicaciones (API) de Criptografía de Java incluyó las implementaciones de los algoritmos criptográficos más importantes en su momento. Es más, el famoso criptógrafo Whitfield Diffie fue CSO de Sun Microsystems en ese tiempo, lo que refuerza la idea de que Java fue diseñado con la seguridad en mente. Fui un instructor certificado por Sun Microsystems casi desde los inicios de Java y puedo dar fe de que existía un curso llamado Implementing Java Security, donde enseñábamos cómo aprovechar las características de seguridad del lenguaje. Todo indicaba que tendríamos una plataforma segura para rato[1], hasta que un día Oracle compró Sun Microsystems y algo cambió.

Mientras leo mi nombre escrito en el vaso, que ya muestra evidencias de la condensación por el calor intenso, llego a la conclusión de que se trata del precio de la fama.

El precio de la fama

En realidad las vulnerabilidades en Java no son tema nuevo. Han estado presentes desde el principio, pero con dos diferencias importantes con respecto a las actuales: la plataforma recién comenzaba a popularizarse y Sun Microsystems tenía una capacidad de respuesta muy buena para corregir las vulnerabilidades reportadas. Sin embargo, es de esperarse que cuando algo (o alguien) adquiere fama, se vuelva blanco inherente de ataques, entonces la motivación por encontrar nuevas vulnerabilidades en la plataforma aumenta.

Cada año se descubren nuevas vulnerabilidades pero, coincidentemente desde el año de la compra, el número de vulnerabilidades en Java ha incrementado su búsqueda, no sólo por parte de los investigadores, también por aquellos que buscan una oportunidad para lucrar aprovechando una combinación paradójicamente peligrosa: Internet y la capacidad de Java de ejecutarse en un navegador.

Por tal motivo, hay quienes se han dado a la tarea de informarnos cuando ocurre alguna vulnerabilidad de día cero (zero-day) [1] o de los detalles de tales vulnerabilidades encontradas [2]. Sin embargo, la pregunta hasta este momento sigue siendo ¿Qué es vulnerable en Java?

Imagen 1. La gráfica representa la cantidad de vulnerabilidades que se han encontrado en la plataforma Java desde los primeros años hasta ahora. Es evidente el aumento tan pronunciado en los últimos años.

El regreso de los applets

¿Alguna vez escuchó hablar de los applets de Java? Los applets fueron una buena idea al principio, la manera ideal de distribuir programas Java a prácticamente cualquier usuario con una conexión a Internet, pero pronto fueron reemplazados por otras tecnologías más ligeras y con mejor desempeño, por lo que fueron relegados poco a poco, condenados al destierro y al olvido, hasta que alguien les encontró un nuevo uso. Un applet no es otra cosa más que un programa hecho en Java que se coloca en un servidor web y se asocia con una etiqueta <applet> en una página HTML.

Cuando un usuario entra a un sitio web que tiene una página con un applet asociado, el applet se descarga junto con la página HTML y, una vez descargado en el navegador de la computadora del usuario, se ejecuta siempre y cuando el navegador tenga la configuración suficiente para permitirlo. Es aquí donde el applet, si fue programado de manera que explote una vulnerabilidad, se ejecuta y arruina la diversión de navegar en Internet.

Es importante aclarar que en condiciones normales un applet sigue un estricto control de seguridad, pues no permite la ejecución de código nativo en la computadora del usuario, ni puede conectarse a un servidor diferente a aquél de donde fue descargado. El problema está cuando el programador del applet ha descubierto cómo burlar esos controles.

De esta manera, los applets han constituido un excelente vector de ataque, porque pueden ser descargados desde Internet y ejecutados en un navegador. Haciendo un poco de memoria, en los 90 algunos applets se hicieron famosos, por ejemplo “Jumping the Firewall”, que lograba evadir firewalls, o “Big attacks come in small packages” que, irónicamente, podía hacer mucho daño a través de pequeños paquetes de datos. Ya no he encontrado referencias válidas a estas vulnerabilidades antiguas; más bien estoy haciendo un esfuerzo por recordar aquellos primeros casos.

Por lo pronto veo con cierta ansiedad que mi frappé comienza a derretirse y me apresuro a terminarlo antes de que pierda su consistencia. Creo que así mismo pasa con las vulnerabilidades de Java, son aprovechadas tan pronto las descubren, antes de que alguien logre corregirlas.

El lado obscuro de los applets de Java

La explotación de las nuevas vulnerabilidades de Java no se hizo esperar. Evidentemente resulta atractivo poder distribuir un applet malicioso (malware) que se descarga automáticamente (siempre hay emprendedores que encuentran nichos de mercado). Una de esas oportunidades de negocio se encuentra, precisamente, en el mercado negro de applets.

¿Qué pensaría si alguien le ofrece la posibilidad de clonar un sitio, el que usted quiera, hospedado en un servidor de ellos (ni siquiera tiene que exponer el suyo), con un applet a la medida y, mejor aún, personalizable, polimórfico y que le brinde estadísticas de descargas para cuantificar el éxito de una "campaña de infección" por malware? [3] Suena ridículamente atractivo, ¿no es así? Sin embargo, así es como se está haciendo, a la manera de “hágalo usted mismo”. Lo único que hay que hacer después de cerrar el trato es lograr convencer, directa o indirectamente, a todos los incautos posibles para que entren al sitio malicioso y esperar a que se descargue el applet maligno en sus navegadores. Eso es todo, ni siquiera es necesario pedirles sus credenciales (a menos que se desee una ganancia adicional) pues el applet que ejecuta el código Java vulnerado podría leer la información por sí mismo, sin restricciones, incluso transmitirla sigilosamente a donde se quiera, mientras el ingenuo espera a que algo aparezca en la pantalla.

El problema específico

Hablando de las últimas vulnerabilidades descubiertas, éstas se presentan en Java Standard Edition 7 (Java SE 7), específicamente en una interfaz de programación (API) llamada Reflection, que es el mecanismo a través del cual un programa puede examinar o hasta modificar el comportamiento de una aplicación en tiempo real. El problema radica en que ciertas vulnerabilidades permiten que se explore y modifique la aplicación durante la ejecución, sin pasar por las restricciones del administrador de seguridad (Security Manager).

Ya sin restricciones, se pueden transferir, cargar y ejecutar clases modificadas sin validar y, por lo tanto, hacer prácticamente lo que se quiera. No obstante, aunque el problema parece estar limitado únicamente a los applets, la realidad es que, al estar presente la vulnerabilidad en la API de Java, todos los productos que usen dicha API son vulnerables también. Por ejemplo, pensemos en que más de 1,000 millones de computadoras usan Java, junto con más de 3,000 millones de dispositivos móviles y todos los reproductores Blu-ray del mundo, entre muchas otras cosas, como receptores de televisión satelital, sistemas de navegación de automóviles, máquinas de lotería o dispositivos médicos, por mencionar sólo algunos. [4]

Ejemplo de código vulnerable

He sido programador desde los 80 en el siglo pasado y sé de seguridad, así que, para salir de dudas, decidí comprobar por mí mismo qué tan fácil era explotar las vulnerabilidades de Java 7. Ahora hay una gran cantidad de documentación sobre cómo hacerlo. Incluso sin tener mucha experiencia, programar los applets no fue tarea difícil. Una de las vulnerabilidades en la que me enfoqué consistía en deshabilitar el Security Manager de la Máquina Virtual de Java[2] (JVM), y una vez deshabilitado, ejecutar una aplicación nativa en el sistema operativo, es decir, fuera de Java (algo que los applets tienen prohibido hacer, a menos que cuenten con un certificado válido y firmado). Para hacer la historia corta, terminé ejecutando una aplicación nativa de Windows: la calculadora (es curioso ver cómo en muchas pruebas de concepto de análisis de vulnerabilidades, muchos investigadores coinciden en ejecutar siempre la calculadora, tanto que hasta parece formar parte de las herramientas de hackeo).

En un escenario seguro, cualquier intento de hacer eso haría que el validador de applets lo descargara de la memoria, para que no se ejecutara.

Mientras pienso en esto, un poco de café se derrama en mi camisa. ¡Qué ironía! Acabo de ser víctima de mi propio café.

Imagen 2. Código de ejemplo que ejecuta la calculadora de Windows después de deshabilitar el Security Manager gracias a una vulnerabilidad de Java 7

Imagen 3. Código HTML para enviar el applet malicioso al navegador del usuario

Imagen 4. La calculadora de Windows se ejecuta al entrar al sitio que aloja al applet malicioso

Recomendaciones

Casi termino mi café (antes de tiempo, gracias a lo que derramé), pero no puedo hacerlo sin dejar algunas recomendaciones:

• Si eres un programador, debes esforzarte por aprender y aplicar técnicas de programación segura en tus desarrollos. Es cierto; es importante que el programa haga lo que tiene que hacer, pero también es importante que lo haga con seguridad, no dando oportunidad a algún malintencionado de encontrar y aprovechar un error dejado por descuido o por ignorar las consecuencias.
• Si eres administrador de sistemas y tus usuarios necesitan usar el plugin de Java en sus navegadores para sus tareas cotidianas en la empresa, es crucial que distribuyas las actualizaciones más recientes del plugin de Java.
• En todos los casos, usa siempre la versión más actualizada de tu navegador de Internet y de los plugins que uses (hay otros plugins con historial de vulnerabilidades, no sólo Java). Si no usas algún plugin, deshabilítalo o desinstálalo. El único inconveniente ocurre cuando un applet de Java requiere ejecutarse en una versión específica de Java, pues en ese caso se requiere tener instalada dicha versión. Si eso ocurriera, conviene activar el plugin únicamente cuando se use la aplicación y desactivarlo nuevamente al salir.

Aunque Oracle ha estado trabajando en solucionar las vulnerabilidades, y ha logrado mantener la situación bajo control en los últimos meses, hay que tomar medidas inmediatas, como desinstalar o deshabilitar Java ¡Pero sólo en los navegadores! No quiero imaginarme a un administrador de sistemas desinstalando un servidor de aplicaciones Java sólo por desconocer dónde está la vulnerabilidad. Es mejor informarse.

Finalmente miro el vaso de café, ahora vacío. No estuvo mal, pero siento que le faltó algo. Tal vez debería llamarse nuevamente Java Chip o de lo contrario, la próxima vez pediré solo café, café amargo.

Referencias