Por supuesto, el software que se utiliza en los entornos de Big Data es susceptible de contener fallos de seguridad que van siendo descubiertos a lo largo del tiempo. La gestión de las actualizaciones es un proceso fundamental que debe tomarse en serio. A veces esta gestión no es trivial, y la ventana de oportunidad para explotar un bug conocido (Known-Bug) puede ser grande, por lo que hay que prestar especial cuidado a las listas de seguridad, y tener los procesos de gestión de parches bien engrasados.

En la conferencia de Big Problems with Big Data que os dejé hace unos artículos, el ponente ponía el ejemplo de cuál es el proceso de aplicación de un parche de, por ejemplo, una librería como JQuery en un entorno de Big Data. 

El bug es descubierto y publicado en JQuery que después se aplica a la siguiente distribución de Django. Este framework se utiliza para construir Apache HUE, por lo que en la siguiente compilación en la que se compruebe que la nueva versión de Django no rompe nada se aplicará, con la consiguiente corrección del bug que había en JQuery. Apache HUE saca su nueva versión, y esta debe ser empaquetada en la nueva compilación de Apache Hadoop, por lo que para que el known-bug de JQuery esté parcheado en la versión de Apache HUE que acompaña tu distribución de Apache Hadoop hay que esperar un paso más.

Esto, por supuesto, se alarga si has utilizado una distribución como Cloudera o HortonWorks que deberán hacer su nueva release en la que haya probado que la nueva distribución de Apache Hadoop que lleva la nueva versión de Apache HUE compilada y probada con la nueva versión del framework de DJango que incorpora la nueva versión de JQuery parcheada no rompe nada. Y después deberá instalarlo el cliente si ha decidido ir a un entorno de Big Data basado en una instalación OnPremise, o en Cloud pero gestionada por él mismo.

Esto por supuesto no es siempre un proceso tan lento, y cuando un bug de seguridad es crítico se acortan los plazos al máximo, pero aún así hay una ventana temporal de explotación de known-bugs muy grande. Por eso es especialmente importante estar al día de los posibles bugs que puedan ser descubiertos en los programas que usas en tu instalación de Big Data. 

En el caso de WSO2 Carbon Server, recientemente se publicaron en las listas de seguridad una serie de ellos que deben tenerse en cuenta. Lo curioso es que al ir a mirar el histórico de los Security Advisories de todos los productos de la familia, solo pude localizar Security Advisories en 2016 y solo los que había leído en la lista de contactos.

Sin embargo, si entramos en la lista de parches disponibles sí que podemos ver todo el histórico de parches de seguridad para todos los productos, y ahí podemos revisar si en una determinada instalación existen o no vulnerabilidades.

Además, en los productos de WSO2 es extremadamente sencillo descubrir la versión de un determinado producto ya que sin necesidad de tener iniciada una sesión se puede acceder al botón de "About" y conocer qué versión exacta es la que está instalada. 

Una vez conocida la versión, revisar la lista de parches da exactamente la lista de known-bugs que se tiene en esta instalación concreta. Para nuestro sistema de pentesting persistente Faast esto es perfecto ya que nos permite avisar a nuestros clientes rápidamente cuando una versión desactualizada es detectada.

Gracias a ello es sencillo localizar versiones inseguras, pero también para la propia organización detrás del software, por lo que sería sencillo localizar clientes a los que hacer un aviso de seguridad personalizado con el objeto de ayudarles a estar más seguros.

Una de las versiones inseguras de WSO2 Data Services Server permite la ejecución de código en Java desde la consola de Tools, a la que se puede acceder sin necesidad de haberse autenticado en la plataforma. Desde esa misma consola es posible ver cómo cuando se intenta hacer una conexión, la página web pone el código que esta ejecutando.

Tener este panel, expone en primer lugar los servidores de la DMZ para hacer un ataque de XSPA, pero también es vulnerable el interfaz con un bug de HTML Injection que permite hacer cosas como este Ataque de David Hasselhoff.

Figura 7: Un HTML Injection con un homenaje de Ricardo Martín al David Hasselhoff Attack

Y si además hay una gestión de credenciales insegura en alguna de las bases de datos de la DMZ y se llega a un servidor como este con un usuario sa de Microsoft SQL Server sin contraseña, sin necesidad de haberse conectado al servidor WSO2 Data Services Server es posible acceder a ficheros del servidor viendo el código en el mensaje de error.

Figura 8: Un LFI en el mensaje de error

Al final, la gestión de parches es algo fundamental, y es verdad que el número de aplicaciones y tecnologías que suele tener un entorno de Big Data en una empresa es grande, pero si no se hace esa gestión de forma robusta y planificada al igual que se hace con el resto de las tecnologías, explotar un "Known-Bug" va a ser muy sencillo para un atacante.

Saludos Malignos!