Java... o cuando la seguridad no determina lo que debemos proteger

Hablando de seguridad, el lenguaje de programación Java (y su correspondiente máquina virtual) ha estado por años en el ojo de la tormenta, con un incremento sustancial en el número de vulnerabilidades reportadas, así como aquellas consideradas de alto riesgo (que reportan un puntaje de 7.0 o mayor, según el sistema CVSS). Bajo este escenario, dos preguntas saltan a la mente de un investigador/especialista de seguridad: (1) es seguro utilizar este lenguaje de programación al desarrollar aplicaciones, especialmente para aquellas que son utilizadas a través de una red o el Internet? (2) es el incremento en vulnerabilidades el resultado del creciente interes de atacantes, debido a la popularidad de Java?

Veamos las estadísticas. Desde 2008, se han encontrado 384 vulnerabilidades al lenguaje Java. En comparación, sólo se reportaron 51 de 2001 a 2007. Aún más preocupante, el número de vulnerabilidades de alto riesgo pasó de 22 (2001 a 2007) a 213 (desde 2008). La situación se ha tornado tan preocupante que US CERT, la entidad de los EEUU encargada de diseminar información sobre problemas de seguridad entre organizaciones no militares, ha recomendado deshabilitar Java en los navegadores web, incluso después de haber instalado la versión más reciente del lenguaje. Y empresas como Apple incluso decidieron deshabilitar Java de forma remota entre todos sus usuarios.

Fuente: cvedetails.com (Octubre 2013)

Las respuestas a las dos preguntas del primer párrafo ciertamente están relacionadas. El incremento en vulnerabilidades reportadas puede atribuirse parcialmente a la creciente popularidad de Java. Y esta situación podría claramente alejar a muchas organizaciones a utilizar el lenguaje, al considerarlo peligroso ...pero la situación es otra.

La popularidad de Java parece estar tan fuerte como nunca. El sitio web langpop.com que estudia diversos sitios relacionados con lenguajes de programación (como portales de anuncios de trabajo para programadores y repositorios de programas/código fuente), coloca a Java como el segundo lenguaje de programación más popular, detras tan sólo del lenguaje C. Curiosamente este último lenguaje también es conocido por sus problemas de seguridad, particularmente por el tema de desbordamiento de pilas o búfers.

El índice TIOBE sobre popularidad de lenguajes de programación, que existe hace más de 30 años y se actualiza mensualmente, también colocó a Java en el segundo lugar en su evaluación de Octubre 2013. De acuerdo a TIOBE, Java sólo ha ocupado las primeras dos posiciones por los últimos 11 años, como se muestra en la figura de abajo.

Fuente: tiobe.com (Octubre, 2013)

En la era del web, redes sociales, miles de millones de usuarios y 'Big Data', Java se ha convertido en un fuerte candidato a la hora de seleccionar un lenguaje de programacion. Su capacidad para producir aplicaciones que cumplan con los requisitos de escalabilidad y rendimiento necesarios en esta era, es difícil de alcanzar con otros lenguajes. La flexibilidad que ofrece por medio de su máquina virtual (JVM) para ejecutar los programas Java en múltiples plataformas y el hecho de que existen versiones código libre de la plataforma Java, hace la decisión aún más sencilla para los programadores a la hora de seleccionar.

Grandes compañías como Google, Facebook, LinkedIn, Twitter y Square, utilizan Java como parte de su estrategia para producir aplicaciones y servicios que les permita crecer y ajustarse a las demandas del creciente mercado que encuentran en Internet. Un reciente artículo de la revista de tecnología Wired, incluso habla de la segunda llegada o advenimiento de Java en la era del web. Aunque esto nos parece un poco exagerado, Java nunca desapareció, si es cierto que el lenguaje está ayudando a que empresas puedan cumplir con los exigentes requisitos de esta era.

Entonces, volviendo al tema de seguridad, que hacer con un lenguaje extremadamente popular y ventajoso pero que se encuentra en el ojo de la tormenta, por sus inherentes problemas de seguridad? La situación con Java es un ejemplo más de las limitaciones con las que contamos los especialistas de seguridad. Es iluso pensar que sólo nosotros debemos definir los requisitos y restricciones sobre las cuales diseñar y construir aplicaciones y sistemas. Somos parte de un conjunto de actores que definen estos requisitos, lo que produce un escenario usualmente complicado y no siempre claro para nuestros objetivos de seguridad. Sin embargo, y es de esperarse, que debemos actuar y ser efectivos bajo este escenario. Porque si algo es claro, es que parte de nuestro trabajo es manejar y asegurar aplicaciones escritas en Java.

Cómo evaluar/medir las vulnerabilidades y a cuáles debo prestarles atención primero?

Ningún software está libre de fallas o vulnerabilidades de seguridad, es una realidad de la que nadie que administre computadoras se escapa. Recientemente se publicó el documento científico"Beyond Heuristics: Learning to Classify Vulnerabilities and Predict Exploits" en la conferencia KDD 2010 y cuyo autor principal es Mehran Bozorgi. El documento presenta el uso de una técnica de aprendizaje de máquinas llamada Linear SVM para determinar la posibilidad que una vulnerabilidad de seguridad sea implementada (lo que se conoce como crear un exploit). Esta técnica busca ayudar a los administradores de sistemas, quienes tienen que decidir a cuales vulnerabilidades prestarles atención primero debido a la gran cantidad de anuncios que aparecen a diario sobre fallas de seguridad. En los últimos 8 años se han publicado en promedio más de 140 vulnerabilidades por semana. Aun cuando no todas aplican a un sistema informático en particular, el número de publicaciones que debe revisar un administrador de sistema sigue siendo alto debido a la naturaleza heterogénea del sistema (está compuesto de distintos programas, cada uno con sus propias vulnerabilidades).

El documento apunta a una pregunta que ataca a todo profesional de seguridad informática: cuán importante es la experiencia para resolver problemas de seguridad, especialmente en esta área que carece de principios de diseño y modelos matemáticos robustos y que demuestra estar en sus primeras fases de desarrollo? El área de aprendizaje de máquinas por el contrario se basa principalmente en realizar análisis estadístico sobre conjuntos de datos (datasets) que permitan dar respuestas, sin necesidad de depender en la opinión de "expertos" (aunque también existen métodos estadísticos que aprovechan esta información). Los resultados presentados por Bozorgi y sus compañeros son promisorios, comparando su técnica con un método heurístico y popular en la comunidad de seguridad: el métrico CVSS.

En el año 2004, como miembro del equipo de seguridad informática de la Autoridad del Canal de Panama (ACP), nos enfrentamos al tema de como manejar la creciente ola de reportes de vulnerabilidades que recibíamos semanalmente. Nuestra solución fue completamente heurística, basándose en un sistema de puntaje similar al CVSS (antes de que ellos hicieran lo mismo :). Aunque no tan elegante como CVSS, nuestra solución era de fácil implementación y uso.

La parte medular del sistema de ACP era el cuestionario utilizado para evaluar cada nueva vulnerabilidad. Por cada respuesta afirmativa, se asignaba un puntaje a la vulnerabilidad. El puntaje oscilaba entre 0 y 10 puntos y dependiendo del puntaje total se clasificaba la vulnerabilidad como critica (7 a 10 puntos), alta (5 a 6), moderada (3 a 4) y baja (0 a 2). Dependiendo de esta clasificación, se determinaba si debíamos informar a los administradores de sistemas o no. He aquí el cuestionario y puntaje por pregunta afirmativa:

1. Afecta a recursos de alto valor? 1 punto
2. Afecta la infraestructura de red (ej. conmutadores, murallas de fuego, DNS)? 1 punto
3. Afecta a un producto ampliamente usado o instalado en la ACP? 1 punto
4. Afecta instalaciones por defecto de un producto? 1 punto
5. Existe código disponible públicamente que aproveche la vulnerabilidad o está siendo ejecutada ampliamente en el Internet? (ej. virus) 1 punto
6. La vulnerabilidad se puede acceder remotamente? 1 punto
7. La vulnerabilidad se puede acceder sin credenciales? 1 punto
8. Se han publicado detalles técnicos de la vulnerabilidad? 0.5 punto
9. El resultado permite acceso administrativo o con privilegios? 1 punto
10. Se requiere de ingeniería social (ej. visitar un sitio, hacer clic sobre un enlace web) para aprovechar la vulnerabilidad? 0.5 punto
11. Existen registros de auditoria en la ACP que demuestran intentos o ataques utilizando la vulnerabilidad? 1 punto

Los resultados fueron alentadores. En el 2004, sólo enviamos 5 alertas de 54 vulnerabilidades reportadas en productos Microsoft y utilizados en la ACP. Sin embargo, los valores seleccionados para cada pregunta carecían de base científica y se basan exclusivamente en la opinión consensuada del grupo que desarrolló el documento. Además, el documento de Bozorgi sugiere que se pueden obtener mejores resultados si se utiliza técnicas de análisis estadístico.

El área de aprendizaje de máquinas sugiere implícitamente que una persona nunca puede vencer al mundo, en términos del conocimiento que cada uno puede aportar. En otras palabras, no importa cuan inteligente sea un ser humano para resolver un problema, el mundo real puede darnos una mejor solución. En el caso de las vulnerabilidades, las soluciones humanas son la de la ACP y CVSS, mientras que la solución basada en Linear SVM es la del mundo real. La razón por la que esta última es la del mundo real es que utiliza el registro de las características de cada vulnerabilidad reportada desde el anyo 2001 (un largo periodo) y realiza un análisis estadístico sobre este registro. O sea, toma una postura imparcial sobre los datos que se le presentan, a diferencia de la tabla de la ACP en donde a priori se le da mayor peso a cierto tipo de información (por ejemplo, la pregunta 1 tiene mayor valor que la pregunta 8).

Abajo aparece una tabla con algunos de los resultados presentados en el documento:

Fuente: Bozorgi, et al.

La primera columna indica el número de días (t) utilizados para determinar la factibilidad de que una vulnerabilidad sea explotada/implementada luego de t días. La segunda y tercera columna indican el número de casos positivos (|P|) y casos negativos (|P|) utilizados para entrenar el modelo. La cuarta y quinta columna indican los resultados de utilizar el método heurístico CVSS y de Linear SVM respectivamente, para determinar la factibilidad de implementación de la vulnerabilidad. Como puede observarse en cada renglón, los valores de la quinta columna son superiores a los de la cuarta.

Les recomiendo leer el documento de Bozorgi ya que es un excelente documento para aprender más de la técnica propuesta y también un buen ejemplo sobre como presentar resultados en una publicación científica. Al leerlo, uno puede determinar que la técnica propuesta posee limitaciones. Para comenzar, la técnica sólo busca determinar cuan rápido será implementada una vulnerabilidad. Mientras tanto, los métodos de ACP y CVSS buscan determinar cuan peligrosa es una vulnerabilidad (lo que no solo depende de si la vulnerabilidad ha sido implementada o no). Adicionalmente, en el sitio web del proyecto no está disponible (al momento de escribir este artículo) el dataset utilizado para calcular los valores presentados en el documento. Esto impide que uno mismo puede validar los resultados. Al final, los autores del documento sugieren que se utilicen técnicas estadísticas como complemento a las técnicas heurísticas. Esto será más viable a medida que continua nuestra uso y dependencia en sistemas informáticos, lo que generará más y mejores grupos de datos para ser analizados con técnicas como Linear SVM.