Auditando routers domésticos

En primer lugar, presentarnos. Somos el grupo de investigadores de la Universidad Europea de Madrid (Jose Antonio Rodríguez García, Álvaro Folgado Rueda e Iván Sanz de Castro), que recientemente ha revelado 62 vulnerabilidades que afectan a 22 routers diferentes, la mayoría de ellos ampliamente extendidos en España. 

El tutor del proyecto es uno de los editores de este blog: Alejandro Ramos.

Desde el Máster en Seguridad de las TICs impartido en la Universidad Europea de Madrid, nos hemos embarcado en este proyecto, a nuestro juicio muy interesante: auditar uno de los dispositivos de red típicos en todos los hogares, el router.

El objetivo de la investigación que hemos realizado, es evaluar el estado actual de la seguridad en routers domésticos, desarrollar una metodología de auditoría que facilite la tarea a investigadores futuros, y reportar las vulnerabilidades a los fabricantes y entidades competentes, para que los problemas de seguridad encontrados se solucionen en el menor tiempo posible.

En esta breve entrada, vamos a definir los problemas de seguridad encontrados, plantear PoCs de dos de las vulnerabilidades, y exponer los resultados obtenidos.

Deficiencias de seguridad

A continuación, vamos a exponer brevemente las deficiencias de seguridad más comunes que hemos hallado a lo largo del proceso de auditoría. Esto nos permitirá entender el impacto y vector de explotación de cada una de las vulnerabilidades, aplicado a los routers domésticos:

• Persistent Cross Site Scripting. Permite a un atacante inyectar código malicioso en la interfaz web de configuración del dispositivo. El código malicioso puede tener como objetivo secuestrar la sesión del usuario o infectar el navegador de la víctima, entre otras muchas cosas. El ataque se puede realizar en remoto, mediante el envío de un enlace malicioso a la víctima, o en local, si el usuario no ha cambiado las credenciales por defecto.

• Unauthenticated Cross Site Scripting. En este caso, la inyección de código se realiza en local, pero sin necesidad de autenticación, mediante el envío de una trama DHCP Request, en la cual el parámetro hostname contiene el script malicioso a inyectar. Para facilitar el ataque, hemos desarrollado un script en Perl que manda una trama personalizada, pero es posible hacerlo mediante la modificación del fichero /etc/hostname en el equipo atacante conectado a la red.

• Cross Site Request Forgery. Mediante el envío de un enlace específico o si la víctima accede a una página web maliciosa, un atacante puede modificar cualquier parámetro de configuración del router.

  

  Enlaces maliciosos destinados a modificar el DNS en Observa Telecom AW4062

• Privilege Escalation. Un usuario sin privilegios de administración puede escalar a superusuario y realizar cualquier cambio en la configuración del dispositivo.

• Information Disclosure. Un atacante, sin necesidad de un proceso de autenticación previo, puede obtener información crítica del dispositivo, como por ejemplo: la contraseña de la red inalámbrica, un listado de clientes conectados, y otros parámetros de configuración clave. Para descubrir este tipo de vulnerabilidades, es fundamental tener acceso al sistema de ficheros del router, siendo lo más efectivo montar su firmware.

• Backdoor. Existen usuarios ocultos con privilegios de administrador, de los cuales el usuario final no tiene constancia, y que podrían permitir a un atacante acceder y modificar la configuración del dispositivo con facilidad.

• Bypass Authentication. Un atacante puede configurar parámetros críticos del dispositivo, sin necesidad de autenticarse, como por ejemplo: modificar los servidores DNS, devolver el dispositivo a ajustes de fábrica, reiniciar el router en bucle generando una denegación de servicio persistente, e incluso tener acceso a todos los parámetros de configuración. 

• Bypass Authentication using SMB Symlinks. Un atacante sin autenticar puede acceder al sistema de ficheros completo del router a través de un enlace simbólico en el servidor de SMB integrado, obtener las credenciales de todos los usuarios, y realizar cualquier cambio en la configuración.

• USB Device Bypass Authentication. En caso de que exista un dispositivo de almacenamiento USB conectado al router, un atacante sin autenticar puede acceder, añadir, modificar y eliminar, todos los ficheros del mismo.

• Universal Plug and Play. Un atacante puede aprovechar debilidades inherentes a este protocolo y realizar diversos ataques, tanto local como remotamente, sin necesidad de un proceso de autenticación previo. Por ejemplo, cambiar las reglas del firewall para facilitar la explotación de otras vulnerabilidades en remoto, o realizar una denegación de servicio persistente. La figura inferior muestra la explotación de esta vulnerabilidad de manera remota.

  

  Esquema de explotación remota de una vulnerabilidad UPnP

Resultados

Tras varios meses de investigación, se descubrieron más de 60 vulnerabilidades, que afectan a 22 modelos diferentes. En la figura inferior se observa el número de dispositivos y vulnerabilidades que afectan a cada fabricante.

Vulnerabilidades por fabricante 

En la siguiente tabla, se puede apreciar un completo listado de los dispositivos analizados, así como de las vulnerabilidades que afectan a los mismos.

Tabla de vulnerabilidades

Cabe resaltar, que si un router no aparece en el listado anterior, no significa que no sea vulnerable, si no que no ha sido auditado.

Proof of Concepts

Durante la investigación, se han desarrollado pruebas de concepto para cada una de las vulnerabilidades encontradas. Seguidamente, se detallan dos de ellas.

Information Disclosure en Observa BHS-RTA

Un atacante sin autenticar, puede obtener información crítica del dispositivo accediendo a determinadas URLs.

Por ejemplo, para obtener información sobre los parámetros de conexión inalámbrica del dispositivo, incluida la clave de la red inalámbrica, solo es necesario acceder a la siguiente URL:

http://<Router IP>/cgi-bin/webproc?getpage=html/gui/APIS/returnWifiJSON.txt&var:page=returnWifiJSON.txt&_=1430086147101

{ "RETURN":{ "success": true }, "WIFI": { "status":"1", "ssidName":"Amelia", "ssidVisibility":"1", "channelMode":"MANUAL", "channel":"4", "SECURITY":{ "cipherAlgorithm": "WPA" , "algVersion": "WPA1" , "passwordWEP":"12345", "passwordWPA":"GUSS1986", "passwordWPA2":"GUSS1986", "passwordAUTO":"GUSS1986" } }, "DHCP": { "status":"1", "poolStart":"192.168.1.33", "poolEnd":"192.168.1.254" }, "LAN": { "ip": "192.168.1.1" , "mask": "255.255.255.0", "ipLeafPath":"InternetGatewayDevice.LANDevice.1.LANHostConfigManagement.IPInterface.1.IPInterfaceIPAddress" }, "DNS": { "dns":"80.58.61.250,80.58.61.254" }, "IPV6": { "ipv6": "fe80::e6c1:46ff:fee6:3818", "globalipv6": "", "prefixLen": "64", "interface": "", "mode": "1", "minID": "33", "maxID": "254" }, "PREFIX": [ { "prefix": "/", "name": "PVC:8/36" } , { "prefix": "", "name": "PVC:8/32" } , { "prefix": "", "name": "pppo3g" } ] }

Para obtener información acerca de los clientes conectados, incluyendo sus direcciones MAC e IP, solo es necesario acceder a la siguiente URL:

http://Router IP/cgi-bin/webproc?getpage=html/gui/APIS/returnDevicesJSON.txt&var:page=returnDevicesJSON.txt&_=1430086147101

{ "RETURN":{ "success":true }, "DEVICES":[ { "idDevice": "1", "nameDevice": "192.168.1.33", "idIcon": "DesktopComputer_1", "interfaceType": "Ethernet", "type": "Unknown", "ipAddress": "192.168.1.33", "macAddress": "MAC eliminada por razones de seguridad", "connected": true, "unknown": false, "blacklisted": false } , { "idDevice": "2", "nameDevice": "192.168.1.39", "idIcon": "DesktopComputer_1", "interfaceType": "WiFi", "type": "Unknown", "ipAddress": "192.168.1.39", "macAddress": "MAC eliminada por razones de seguridad", "connected": false, "unknown": false, "blacklisted": false } , { "idDevice": "3", "nameDevice": "192.168.1.35", "idIcon": "DesktopComputer_1", "interfaceType": "802.11", "type": "Unknown", "ipAddress": "192.168.1.35", "macAddress": "MAC eliminada por razones de seguridad", "connected": false, "unknown": false, "blacklisted": false } , { "idDevice": "4", "nameDevice": "192.168.1.36", "idIcon": "DesktopComputer_1", "interfaceType": "802.11", "type": "Unknown", "ipAddress": "192.168.1.36", "macAddress": "MAC eliminada por razones de seguridad", "connected": false, "unknown": false, "blacklisted": false } , { "idDevice": "5", "nameDevice": "192.168.1.37", "idIcon": "DesktopComputer_1", "interfaceType": "WiFi", "type": "Unknown", "ipAddress": "192.168.1.37", "macAddress": "MAC eliminada por razones de seguridad", "connected": false, "unknown": false, "blacklisted": false } , { "idDevice": "6", "nameDevice": "192.168.1.38", "idIcon": "DesktopComputer_1", "interfaceType": "802.11", "type": "Unknown", "ipAddress": "192.168.1.38", "macAddress": "MAC eliminada por razones de seguridad", "connected": false, "unknown": false, "blacklisted": false } , { "idDevice": "7", "nameDevice": "192.168.1.34", "idIcon": "DesktopComputer_1", "interfaceType": "802.11", "type": "Unknown", "ipAddress": "192.168.1.34", "macAddress": "MAC eliminada por razones de seguridad", "connected": false, "unknown": false, "blacklisted": false } , { "idDevice": "8", "nameDevice": "192.168.1.40", "idIcon": "DesktopComputer_1", "interfaceType": "WiFi", "type": "Unknown", "ipAddress": "192.168.1.40", "macAddress": "MAC eliminada por razones de seguridad", "connected": false, "unknown": false, "blacklisted": false } , { "idDevice": "9", "nameDevice": "192.168.1.34", "idIcon": "DesktopComputer_1", "interfaceType": "WiFi", "type": "Unknown", "ipAddress": "192.168.1.34", "macAddress": "MAC eliminada por razones de seguridad", "connected": false, "unknown": false, "blacklisted": false } , { "idDevice": "10", "nameDevice": "192.168.1.33", "idIcon": "DesktopComputer_1", "interfaceType": "802.11", "type": "Unknown", "ipAddress": "192.168.1.33", "macAddress": "MAC eliminada por razones de seguridad", "connected": false, "unknown": false, "blacklisted": false } ] }

Para obtener información sobre los parámetros de conexión a Internet del dispositivo, puede accederse a:

http://Router IP;/cgi-bin/webproc?getpage=html/gui/APIS/returnInternetJSON.txt&var:page=returnInternetJSON.txt&_=1430086980134

{ "RETURN":{ "success":true }, "INTERNET": { "physicalStatus": "down", "rateDown": "6,3Mb", "rateUp": "309Kb", "maxRateDown": 0, "maxRateUp": 0, "wanType": "DSL", "PPP": { "type": "PPPoE", "name": "PVC:8/32", "username": "adslppp@telefonicanetpa", "password": "adslppp", "ip" : "", "gw" : "", "mask" : "", "pppPath": "InternetGatewayDevice.WANDevice.1.WANConnectionDevice.2.WANPPPConnection.1." } } }

Para saber si la contraseña del router es la que viene por defecto o ha sido cambiada, tan solo hay que acceder a:

http://Router IP/cgi-bin/webproc?getpage=html/gui/APIS/returnPasswordJSON.txt&var:page=returnPasswordJSON.txt&_=1430086980134

{ "RETURN":{ "success": true }, "PASSWORD":{ "isDefault": true } }

Bypass Authentication mediante Symlinks de SMB en Observa Telecom VH4032N

Un atacante sin autenticar puede obtener todo el sistema de ficheros del router tras conectarse al servidor SMB del mismo.

En primer lugar, se listan los servicios disponibles en el servidor de Samba hospedado por el router, observándose que el servicio storage está compartido y disponible.

Listado de servicios disponibles en SMB

Posteriormente, se realiza la conexión al servicio storage. Una vez establecida la misma, pueden listarse los ficheros disponibles.

Acceso al servicio storage

Debido a una mala configuración del servidor de SMB, es posible realizar enlaces simbólicos al sistema de ficheros del router, acceder a ellos y descargar su contenido.

Realización del enlace simbólico al directorio /

Se puede navegar libremente por el mismo, teniendo acceso a todos los archivos de configuración del router y las credenciales de los usuarios.

Navegación libre por el sistema de ficheros

Conclusiones

La auditoría realizada a los routers domésticos evidencia graves problemas de seguridad. Estas deficiencias pueden ser fácilmente explotables por ciberdelincuentes o a menor escala, por algún graciosete. Por ello, tanto fabricantes como compañías de comunicaciones han de trabajar conjuntamente para corregir los problemas de seguridad actuales y diseñar dispositivos más seguros.

Además, la mayoría de los routers afectados son muy utilizados en España, puesto que son regalados por los ISPs a sus consumidores. Esto ha llevado a varios medios españoles a hacerse eco de los problemas de seguridad encontrados.

Si queréis obtener más información acerca de las vulnerabilidades, en los reportes a Full Disclosure y PacketStorm, podéis encontrar más información.

Enlaces de interés:

• Reporte a Full Disclosure 
• Reporte a PacketStormSecurity
• Listado de vulnerabilidades reportadas a OSVDB: [1] [2] [3]

Contribución escrita por los autores:
Jose Antonio Rodríguez García
Álvaro Folgado Rueda 
Iván Sanz de Castro

Leer más...

R2dr2: Analysis and exploitation of UDP amplification vulnerabilities

Versión en español del post también disponible => http://www.securitybydefault.com/2014/06/r2dr2-analisis-y-explotacion-de.html

------------------------

Since we began our studies in the Master's degree on ICT security at the European University, drew our attention the possibility of doing a project under the guidance of Alejandro Ramos (@aramosf), a professional of the scene that we admire. After several ideas and proposals by both parties, we decided to make a project about finding new attack vectors on distributed reflection denial of service attacks (DRDOS). Recently this blog talked about it in a article focused on SNMP vulnerability, publishing also a tool for exploitation.

We set ourselves the objective of finding some new amplification in various protocols. To do this, first we made a research about already known vulnerabilities which were published by CERTs and some communities related to computer security. Swiftly we realized the technical complexities with the conditions that had to have the vulnerabilities: based on UDP, not having authentication, with an amplification of at least 2 times the bytes sent, implemented on a large number of sites... and they have to been undiscovered.

We classified our search into three frames where to look: 

• Common UDP-based protocols (such as DNS or NTP) 
• Media streaming and game platforms. 
• Private Applications that use UDP

Most undocumented protocols are just strings of bytes in and out. Each of them mean something, but, if the protocol is private, only the developer knows the meaning. After months of analysis and, some frustrations, we have managed to take advantage of several implementations based on UDP that can be used to make large-scale attacks:

SIP protocol: Options method 

SIP is a signaling protocol for VoIP whose implementation is identical to HTTP-based messages. The main difference, apart from its utility, is that SIP can operate on UDP port 5060. After a Shodan search we saw that there are over 40 million devices connected. Doing some deep research through the RFC we conclude that it was possible to reduce the "OPTIONS" request to some bytes and obtain an amplified response. Those servers that implement a response to "OPTIONS" with SDP information can have a big amplification.

RESPONSE TO "OPTIONS" REQUEST WITH SDP PROTOCOL IMPLEMENTED.

The returned messages had an average multiplier factor of 5 times for every byte sent, slightly above some of the protocols published by the US-CERT. Nowadays, there are over 2 million computers with this multiplier factor, so a highly distributed attack could make a dent on a big company.

Amplification in mobile games

The growth of multiplayer games is something that excited us, a very cool place to research. However, many of these games do not use UDP as transport layer, preferring to use APIs under TCP. Fortunately, most interactive games tend to use UDP, here we found serious vulnerabilities with quite high multiplication factors, some of them 500 to 700 times per byte sent The problem is that those services are not usually large enough to be considered hazardous. Additionally, some mobile gaming platforms like exitgames.com implements triple handshake implemented over UDP, which completely prevents such attacks..

BIG AMPLIFICATION ON “DEADZONE” GAME FOR IOS

Citrix ICA protocol amplification

In an almost obsessive quest to find large amplification factors, we detect that there was a property on a private protocol which had not been taken into account as a possible vector amplification UDP. The affected protocol is the Citrix ICA protocol, designed for shared application servers.

One of the features in certain versions of the protocol, is to communicate the client what shared applications exists, and also the available servers. This message is transmitted by UDP on port 1604 and it does not implement authentication. When the list of applications and servers is large enough, this information disclosure becomes an attack vector for DRDoS attacks.

AMPLIFICATION ON CITRIX ICA BROWSER.

With a simple payload of 84 bytes, a response with an amplification factor of 25 to 40 times for every byte sent is received. The interesting thing about this vulnerability is that in our discovery phase we detected over 12,000 Citrix servers and corroborated that at least 2,000 were vulnerable.

Operating Tool: r2dr2 DRDoS attack tool

To make our proof of concept, we have developed a full-featured UDP amplification attacks program, called "r2dr2". The main difference from other tools, is that it receives a JSON file with the configurations. There you can especify the payload of the running service in hexadecimal format, which makes it highly customizable. Our aim is that the tool will be able to exploit vulnerabilities found not only for us but also any other researcher; we have found that works very well with many protocols.

The following video demonstrates, on a real environment, a distributed amplification attack using UDP with only 10 Citrix ICA servers, that can deny service to a real server on the Internet.

 

Configuring payloads on r2dr2 This video only exploit Citrix ICA protocol information disclosure vulnerability, with almost 25 to 45 bandwidth amplification factor, but in the JSON file that r2dr2 receives you can configure much more payloads from different services and set the amount of times you want to use each IP. This example shown the payload required for amplification in the Citrix ICA UDP, SIP, CHARgen, and NTP protocols.

Dowload JSON configuration file for r2dr2
Download application: r2dr2 DRDoS UDP Amplification

Conclusions
This project has taught us much more than we expected; this is the final conclusion. Find vulnerable protocols it is not a trivial task, but as we demonstrated in the video, effectiveness is large. There will be ways to do DRDOS attacks for a long time, mitigation depends on the talent and budget of each organization.

Daniel Ferreira (@daniel0x00)
Pablo Alobera (@IllegalPointer)

Leer más...

R2dr2: Análisis y explotación de vulnerabilidades de amplificación UDP

English version of this post also available => http://www.securitybydefault.com/2014/06/r2dr2-analysis-and-exploitation-of-udp-amplification-vulns.html

------------------------

Desde que comenzamos nuestros estudios en el Máster Universitario de Seguridad de las TIC en la Universidad Europea, nos llamó la atención la posibilidad de realizar un proyecto bajo la tutela de Alejandro Ramos (@aramosf), profesional del mundillo que admiramos. Después de varias ideas y propuestas por ambas partes, decidimos realizar un proyecto centrado en la búsqueda de nuevos vectores de ataque de denegación de servicio distribuidos reflejados (DRDoS). Recientemente en este blog se ha hablado de ello en un artículo centrado en el protocolo SNMP, llegándose a publicar incluso una herramienta de explotación.

Nos marcamos como objetivo encontrar algún vector de amplificación nuevo en algún protocolo. Para ello, primero hicimos un research de cuales eran las vulnerabilidades conocidas, publicadas por CERTs y algunas comunidades relacionadas a la seguridad informática. Nos percatamos de la complejidad técnica al evaluar las condiciones que tenía que tener la vulnerabilidad: basarse en UDP, no tener autenticación, tener amplificación de al menos 2 veces los bytes enviados, encontrarse implantado en un gran número de sitios y no haber sido explotado anteriormente.

Clasificamos nuestra búsqueda en tres grandes “sitios” donde mirar, para organizarnos entre tanto protocolo: 

• Protocolos comunes basados en UDP (como DNS o NTP) 
• Plataformas de streaming o juegos. 
• Aplicaciones privadas que usen UDP por alguna razón

La mayoría de los protocolos sin documentación no son más que ristras de bytes y más bytes entrando y saliendo. Cada uno de los bytes significa algo que, si el protocolo es privado, sólo la empresa desarrolladora conoce. Luego de meses de análisis y de, por qué no decirlo, frustraciones, hemos logrado aprovecharnos de varias implementaciones basadas en UDP que pueden ser utilizadas para hacer ataques a gran escala:

El método OPTIONS en el protocolo SIP

SIP es un protocolo de señalización para VoIP cuya implementación es idéntica que HTTP: basada en mensajes. La principal diferencia, aparte de su utilidad final, es que SIP funciona bajo UDP en el puerto 5060. Después de unas búsquedas en Shodan y ver que existen más de 40 millones de dispositivos, rebuscamos por el RFC y concluimos que era posible reducir la petición OPTIONS a pocos bytes con el fin de obtener una respuesta amplificada. Aquellos servidores que implementan en la respuesta al OPTIONS el protocolo SDP, responden con un mensaje más grande.

RESPUESTA AL MÉTODO OPTIONS CON PROTOCOLO SDP ACTIVADO.

El mensaje de regreso tiene un factor multiplicador de 5 veces por cada byte enviado, en promedio. Un poco por encima de algunos de los protocolos publicados por el US-CERT. Hay más de 2 millones de equipos con este factor multiplicador, por lo que un ataque muy distribuido podría hacer mella.

Amplificación en juegos móviles

El crecimiento de juegos multijugador es algo que nos entusiasmó, un lugar muy fresco donde buscar. Sin embargo muchos de estos juegos no utilizan UDP como capa de transporte, decantándose por usar APIs bajo TCP. Afortunadamente, para los juegos de más interacción, que si suelen utilizar UDP, se encontraron vulnerabilidades importantes con factores de multiplicación bastante altos, algunos entre 500 y 700 veces por cada byte enviado. El problema es que no suelen ser servicios masificados lo suficiente como para considerarse peligrosos. Además, algunas plataformas de hosting de juegos móviles ampliamente distribuidas como exitgames.com implementan triple handshake sobre UDP, lo que impide completamente este tipo de ataques.

AMPLIFICACIÓN GRANDE EN JUEGO “DEADZONE” PARA IOS.

Amplificación en aplicaciones: protocolo Citrix ICA

En una búsqueda casi obsesiva por encontrar factores de amplificación grandes, logramos detectar que había una característica de un protocolo privado que no había sido tenida en cuenta como posible vector de amplificación UDP en el protocolo ICA de Citrix, que es un protocolo diseñado para servidores de aplicaciones compartidas.

Una de las características del protocolo, en determinadas versiones, es comunicar al cliente qué aplicaciones compartidas existen en el servidor, así como los servidores disponibles. Este mensaje se transmite por UDP en el puerto 1604 y además no implementa autenticación. Cuando la lista de aplicaciones y servidores es considerablemente grande, este Information Disclosure se convierte en un vector de ataque de amplificación UDP distribuido.

AMPLIFICACIÓN EN CITRIX ICA BROWSER.

Con un sencillo payload de 84 bytes, se recibe una respuesta con un factor de amplificación de entre 25 y 40 veces por cada byte enviado. Lo interesante de esta vulnerabilidad es que en nuestra fase de descubrimiento detectamos más de 12.000 servidores Citrix de los cuales al menos 2.000 corroboramos vulnerables.

Herramienta de explotación: r2dr2 DRDoS attack tool

Para llevar a cabo la prueba de concepto, hemos desarrollado una completa herramienta de explotación de ataques de amplificación UDP, a la que hemos llamado “r2dr2”. La principal diferencia respecto a otras herramientas, es que ésta recibe de un archivo JSON varias configuraciones, entre las que destaca la recepción del payload de explotación del servicio en formato hexadecimal. Nuestro objetivo es que la herramienta fuese capaz de explotar no solo las vulnerabilidades encontradas por nosotros si no también cualquier otra del pasado y del futuro; hemos comprobado que funciona correctamente con varios protocolos.

En el siguiente vídeo se demuestra, en un entorno real, que un ataque distribuido de amplificación UDP utilizando apenas 10 servidores Citrix ICA es capaz de denegar el servicio a un servidor real en Internet. 

 
Configuración de payloads en r2dr2

El vídeo únicamente explota el protocolo ICA de Citrix, pero al archivo JSON que recibe r2dr2 se le puede configurar más payloads de distintos servicios y configurar las veces que se desea que se explote determinada IP. En este ejemplo se muestra el payload necesario para conseguir amplificación UDP en los protocolos Citrix ICA, SIP, NTP y CharGEN:

Descarga un archivo de configuración JSON de r2dr2
Descarga la aplicación r2dr2 DRDoS UDP Amplification

Conclusiones

Este proyecto nos ha enseñado mucho más de lo que esperábamos; esta es la verdadera conclusión. Encontrar protocolos vulnerables no es tarea trivial, pero como se demuestra en el vídeo la efectividad es muy grande. Existen y existirán formas de realizar ataques DRDoS, la mitigación depende del talento y del presupuesto de cada organización.

Daniel Ferreira (@daniel0x00)
Pablo Alobera (@IllegalPointer)

Leer más...

Centro de Servicio de Vulnerabilidades - VulnerabilityChaser

Somos Ibrahim Peraza y María Ángeles Caballero,  dos alumnos del Máster Universitario de las Tecnologías de la Información y la Comunicación de la UEM trabajando en el Proyecto de Fin de Máster “Centro de Servicio de Vulnerabilidades - VulnerabilityChaser”. Los profesores del Máster ofertan proyectos relacionados con el mundo de la seguridad y éstos, se desarrollan por varios alumnos. Los proyectos requieren un trabajo previo de investigación, abordando un análisis en profundidad de la problemática concreta y un desarrollo posterior, siempre tutelado por el director del proyecto, en nuestro caso Alejandro Ramos.

En concreto, nuestro proyecto va enfocado a la gestión de vulnerabilidades de los activos de una compañía. Al realizar un estudio previo pudimos observar varias deficiencias en la información que proporcionan los escáneres de vulnerabilidades como pueden ser Nessus o GFI LANguard. Son herramientas muy potentes en cuanto al análisis de vulnerabilidades, pero la información que se muestra acerca de la severidad de las vulnerabilidades no es del todo realista, ya que la puntuación se basa en valores estándar como el CVSS Base sin tener en cuenta factores concretos del sistema afectado como puede ser si es un equipo en producción o simplemente se utiliza para pruebas de desarrollo. Otra deficiencia observada, es que no es posible ver la evolución del estado de las vulnerabilidades a lo largo del tiempo (abierta, cerrada, asumida o planificada), ya que los escáneres de vulnerabilidades nos entregan un informe sobre el estado de nuestros activos en un instante de tiempo concreto, no guardan los datos para ser comparados frente a futuros escaneos.

Nessus usa el CVSS base score para clasificar la severidad de una vulnerabilidad pudiendo ser info, medium, high o critical. El CVSS base score no es suficiente para determinar la severidad de una vulnerabilidad ya que entran en juego otros factores, como por ejemplo, la existencia o no de un exploit para dicha vulnerabilidad, el tipo de información que almacena el sistema, tipo de entorno (integración, preproducción o producción) , etc.

Lo ideal sería calcular para cada vulnerabilidad el CVSS final. El CVSS se calcula en función de 3 vectores: base, temporal y environmental:

-    Base: representa las características intrínsecas y fundamentales de una vulnerabilidad que son constantes en el tiempo y en los entornos de usuario.
Las métricas de éste vector comprenden:

• Access Vector (AV): refleja como la vulnerabilidad es explotada.
• Local (L); Adjacent Network (A); Network Access (N).
• Access Complexity (AC): mide la complejidad del ataque para explotar la vulnerabilidad.
• High (H); Medium (M); Low (L).
• Authentication (Au): mide el número de veces que un atacante debe de autenticarse para explotar la vulnerabilidad.
• Multiple (M); Single (S); None (N).
• Confidentiality Impact (C): este indicador mide el impacto sobre la confidencialidad de una vulnerabilidad al explotarla.
• None (N); Partial (P); Complete (C).
• Integrity Impact (I): este indicador mide el impacto a la integridad de una vulnerabilidad.
• None (N); Partial (P); Complete (C).
• Availability Impact (A): este indicador mide el impacto a la disponibilidad de una vulnerabilidad.
• None (N); Partial (P); Complete (C).

-    Temporal: representa las características de una vulnerabilidad que cambian con el tiempo pero no entre los entornos de usuario.
Las métricas de éste vector comprenden:

• Exploitability (E): esta métrica mide el estado actual de las técnicas de exploit o disponibilidad de código.
• Unproven (U); Proof-of-Concept (POC); Functional (F); High (H); Not Defined (ND).
• Remediation Level (RL): mide el nivel de corrección de la vulnerabilidad, si existe parche, soluciones provisionales, etc.
• Official Fix (OF); Temporary Fix (TF); Workaround (W); Unavailable (U); Not Defined (ND).
• Report Confidence (RC): esta métrica mide el grado de existencia de confianza en la vulnerabilidad.
• Unconfirmed (UC); Uncorroborated (UR); Confirmed (C); Not Defined (ND)

-    Environmental: representa las características de una vulnerabilidad que son relevantes y únicas para el entorno de cada usuario concreto.
Las métricas de éste vector comprenden:

• Collateral Damage Potential (CDP): éste indicador mida la potencia de pérdida de vidas o bienes físicos a través del daño de equipos o robo de éstos.
• None (N); Low (L); Low-Medium (LM); Medium-High (MH); High (H); Not Defined (ND)
• Target Distribution (TD): éste indicador mide la proporción de los sistemas vulnerables, número de sistemas que podrían verse afectados por la vulnerabilidad.
• None (N); Low (L); Medium (LM); High (H); Not Defined (ND)
• Security Requirements (CR, IR, AR): éstas medidas permiten personalizar la puntuación del CVSS dependiendo de la importancia de los activos afectados medido en términos de Confidencilidad, Integradidad y Disponibilidad.   
• None (N); Low (L); Medium (LM); High (H); Not Defined (ND)

Finalmente, cada métrica tendrá un valor asociado, lo que formará los 3 vectores:
   
Base    AV:[L,A,N]/AC:[H,M,L]/Au:[M,S,N]/C:[N,P,C]/I:[N,P,C]/A:[N,P,C]
Temporal    E:[U,POC,F,H,ND]/RL:[OF,TF,W,U,ND]/RC:[UC,UR,C,ND]
Environmental
    CDP:[N,L,LM,MH,H,ND]/TD:[N,L,M,H,ND]/CR:[L,M,H,ND]/ IR:[L,M,H,ND]/AR:[L,M,H,ND]

Podemos consultar en FIRST el cálculo del score de cada uno de los vectores y el CVSS final.

VulnerabilityChaser, la herramienta que hemos desarrollado, gestiona el ciclo completo de vida de la vulnerabilidad. La aplicación permite la introducción del resultado de un microanálisis de riesgos por cada activo del sistema utilizándolo (el resultado) para calcular el valor del CVSS. Los valores base y temporal vienen dados en el escaneo de Nessus y el environmental es el resultado del microanálisis de modo que con estos tres parámetros se realiza el nuevo cálculo de la criticidad de la vulnerabilidad quedando ésta adaptada de forma real al entorno en que se encuentra.

VulnerabilityChaser, hace las funciones de centro de servicio de vulnerabilidades para una empresa, facilitando la vida al administrador de seguridad. Esta herramienta es gratuita y opensource pudiendo ser descargada de GitHub. A día de hoy la aplicación aún se encuentra en un estado alfa de desarrollo.

La aplicación recoge la información de las vulnerabilidades de los escaneos de Nessus y la muestra de manera ordenada; permite cambiar el estatus de una vulnerabilidad, por ejemplo, de abierta a planificarla en una fecha para solucionarla más adelante si se quisiera, gestionar toda la parte de activos previamente comentada, mostrar estadísticas de manera gráfica y otras muchas funcionalidades.

Artículo escrito por Ibrahim Peraza y María Ángeles Caballero.
Twitter: @vul_chaser

Leer más...