05 diciembre 2012

Pentesting VoIP en 2012

Buenas, tras mi último post aquí sobre riesgos en la tecnología VoIP me llegaron dudas de algún pentester por no estar demasiado familiarizados con esta tecnología. Lo cual veo lógico ya que no existe casi documentación actualizada y completa sobre el tema. Así que, por si le sirve a alguien más, voy a comenzar con una serie de posts en donde explicaré los pasos que sigo yo durante una auditoría.

Si usas el Wireshark para hacer “eavesdropping” (escuchar conversaciones) creo que esto te puede ayudar, ya que existen herramientas mucho más potentes. Mostraré también como retocando algunos módulos de Metasploit (y añadiendo otros) este framework supera a herramientas mucho más conocidas para este propósito como la suite SIPVicious. Incluso acercándose al nivel del módulo VoIPPack para el framework Inmunity Canvas, en mi opinión la mejor herramienta de seguridad para este tipo de entornos. El problema de este último es su licencia privativa y su elevado coste. Para que os hagáis una idea del su potencial podéis echarle un ojo a esta demo, donde se automatiza el proceso de pentesting. Como curiosidad, comentar que el desarrollador de ambas alternativas es Sandro Gaucci.



Video: sipautohack (VoIPPack)

El host objetivo que voy a utilizar es la máquina virtual vulnerable (orientada a la seguridad en VoIP) publicada por los miembros del Busy Tone Group con este fin. En este enlace podéis visitar las transparencias de su presentación. Como comenté, usaré Metasploit como herramienta principal apoyándome en otras a medida que vaya superando las distintas fases de la auditoría. Cuando desarrollo me gusta el cliente de consola por ser más ágil pero para hacer pentesting creo que es más cómodo utilizar la interfaz gráfica libre Armitage. Voy a dividir el contenido en las fases típicas de un test de intrusión, que creo que no es necesario explicar a los lectores de este blog.

Búsqueda de información

Seguro que muchos de vosotros comenzáis a menudo con Shodan o algún Google Dork, que nos conocemos ... xD. Además estos últimos son muy útiles para lo que nos ocupa, ya que muchos servidores SIP disponen de paneles web para una configuración más sencilla. Así que vamos a ver como hacerlo en Metasploit, abrimos Armitage y buscamos el módulo auxiliar para consultar Shodan. Al cargarlo veremos las opciones disponibles, en este caso solo necesitamos pasarle la cadena de búsqueda y una key que nos permita usar la API (se obtiene en el panel de usuario), igual que si lo hiciésemos en la web. Las siguientes imágenes muestran ejemplos típicos.



Configuración módulo shodan_search



Uso módulo shodan_search: “Asterisk”



Uso módulo shodan_search: “kamailio”



Para los dorks no conozco ningún módulo de Metasploit así que recurrimos a la manera tradicional. En Exploit-DB es sencillo encontrar servidores SIP comunes, el siguiente es un ejemplo para buscar centralitas Cisco Call Manager


Google Dork: “Cisco Call Manager” 

Ambas herramientas son útiles si no tenemos un objetivo definido de antemano pero, como sabemos, también lo son para este caso ya que podrías encontrarte que alguno de los buscadores tiene indexada información útil sobre alguna de las direcciones IP en estudio. 

En una auditoría de típica se comienza por obtener las direcciones IP de los hosts que nos interesan (footprinting). En el protocolo SIP existen dominios, de forma análoga a la web, así que lo primero será obtener las mismas a partir de un dominio. El módulo enum_dns desarrollado por Darkoperator para Metasploit realiza esta tarea a la perfección (además de transferencias de zona, fuerza bruta, etc). Solo necesitamos pasarle un dominio tal y como muestra la imagen. Al lanzarlo realizará una consulta al DNS contra el mismo obteniendo los distintos registros, entre ellos los SRV relacionados con el protocolo SIP. No tengo ningún servidor DNS a mano así que dejo la máquina virtual para más tarde y esta vez probaré con sinologic.net que es, para que nos entendamos, como el SbD de la VoIP. Aprovecho la ocasión para recomendaros que lo visitéis si os interesa el tema.




Configuración módulo enum_dns


Uso módulo enum_dns



Otras herramientas que me gustan para esta primera fase son Maltego y la FOCA, pero creo que ambas son bastante famosas por aquí, por lo que no vamos a profundizar más. Una vez conocidas las direcciones IP que nos interesan, el siguiente paso sería escanearlas para obtener su firma (fingerprinting). Podríamos utilizar la integración de Nmap con Metasploit o el propio escáner incluído en el framework. Pero a mi me gusta más empezar sin hacer ruido para evitar posibles bloqueos en caso de existir protecciones. Prefiero hacer un escaneo mediante el envío de un solo paquete SIP válido. Además este proceso es mucho más rápido que el soporte para UDP del Nmap, como explica Sandro Gaucci en el blog de SIPVicious. Para ello disponemos del módulo auxiliary/scanner/options y de su versión para el protocolo TCP (options_tcp). 

Ambos, al igual que el resto de módulos relacionados con el protocolo SIP del framework, presentan el problema de que la función que crea la petición no respeta para nada el protocolo. Por ésto muchos servidores como el proxy SIP Kamailio y algunos Session Border Controller (sorprendentemente una minoría) rechazan (error SIP 400 Bad Request) el paquete por considerarlo malicioso, o simplemente lo descartan. Evitando, de esta forma, la obtención de información alguna válida para la auditoría. Con la intención de solucionarlo escribí mi propia versión de los mismos que tengo alojadas en mi repositorio de GitHub. Básicamente completé esa función para soportar todos los paquetes SIP comunes respetando lo que dice el estándar. Para este paso necesitamos el módulo sipscan, por defecto utiliza peticiones OPTIONS y el puerto 5060, así que solo debemos pasarle la dirección IP de la máquina a auditar. Es conveniente especificar un rango de puertos por si a caso, pero normalmente con añadir el 5061 para el caso de TCP es suficiente, por ser el que se utiliza por defecto para las conexiones TLS. Por cierto, estos módulos también funcionan sobre el protocolo TLS por ser una característica intrínseca a las conexiones TCP del propio framework. Usando las opciones avanzadas del módulo podemos seleccionar entre las distintas versiones del protocolo y demás opciones de la conexión. Para una mayor comprensión de la utilización y creación de módulos auxiliares en Metasploit enlazo aquí un par de posts que escribí con Roi Mallo también en este blog. 

Casi siempre este tipo de paquetes (OPTIONS) consigue los mejores resultados, ya que el registro (REGISTER) suele estar más controlado y el INVITE (llamada) podría hacer sonar los teléfonos, lo cual supone un problema evidente. No obstante, en un entorno real a menudo es necesario probar distintos tipos de peticiones, ya que depende de la configuración más o menos segura del objetivo. Los OK, BYE y ACK no suelen ser una buena opción debido a que representan respuestas a algo, pero decidí incluirlos de todas formas porque las múltiples implementaciones del protocolo no dejan de sorprenderme. 

A lo que íbamos, las opciones del módulo para nuestra prueba de concepto quedarían como se muestran en la primera imagen, obteniendo el resultado de la segunda. Donde podemos apreciar que el user-agent servidor SIP incluído en la máquina virtual indica que es un FreePBX (FPBX-2.8.1), por lo tanto un Asterisk (versión 1.8.7.0).




Configuración módulo sipscan



Uso módulo sipscan



Durante todo el proceso siempre tengo abierto el Wireshark filtrando todo el tráfico SIP para evitar posibles perdidas de información en el parseo de las respuestas. Es decir, el módulo busca las cadenas "User-Agent", "Allow", "Server" o "Proxy-Require" en la respuesta, pero en alguna ocasión me encontré servidores SIP que no incluyen ninguna de éstas y sí una llamada "Organization" por ejemplo. Además nos permite obtener diagramas de secuencia (como el de la segunda imagen) muy cómodos para comprender lo que está sucediendo cuando se utilizan herramientas con un comportamiento más complejo, como veremos más adelante.




Captura Wireshark




Diagrama de secuencia Wireshark

Aunque esto sea una auditoría orientada a la VoIP, como sabemos, el objetivo final es “entrar hasta la cocina". De momento solo escaneamos los servidores SIP que se ejecutan sobre el protocolo UDP, así que antes de terminar esta fase es necesario un escaneo completo de puertos para evitar dejarnos nada útil. Podemos usar el escáner de Metasploit o el Nmap, personalmente pasa esta situación prefiero el segundo, así que es momento de realizar un escaneo rápido (para no liarla mucho) sobre TCP. Una vez en este punto creo que no aportaría nada interesante escanear el resto de servicios UDP, así que lo evitamos para no dejar demasiadas huellas. 


Uso Nmap en Metasploit (TCP)



Como podríamos suponer tenemos servicios para entretenernos un rato :). Pues nada más por hoy, en unos días sigo con las etapas de búsqueda de vulnerabilidades y explotación.

Artículo cortesía de Jesús Pérez
Leer más...

03 diciembre 2012

Hacker Épico: El prólogo

A estas alturas ya todo el mundo sabe que el libro de Alejandro y Rodrigo está ya en el 'horno', y la novedad que yo traigo es que YA se puede pre-reservar para tenerlo en casa un poco antes de Navidad.

Con motivo de esta noticia, quiero presentaros el prólogo que tuve el placer de escribir y que refleja una opinión bastante personal y emotiva de este libro.

Su parto fue difícil, había muchas formas de hacerlo y mi apuesta personal iba en consonancia a como ha quedado el libro: Algo distinto, diferente, que no fuese un manual con un 'TTL' corto.

El libro YA SE PUEDE PRE-RESERVAR desde la web de informática64 y como bonus: ¡ Las 100 primeras copias irán dedicadas !

Prólogo

Con independencia del nivel de estudios adquiridos y la disciplina escogida, llega un punto en el que somos capaces de evaluar a los distintos profesores con los que hemos compartido horas lectivas, posiblemente y dejando a un lado las simpatías o matices personales de los profesores, podemos dividirlos en dos grandes grupos: Aquellos que se esforzaron por desarrollar un pensamiento, un deseo por conocer la materia, mantenernos actualizados y que daban una prioridad secundaria a la información pura y dura, y aquellos otros grises que se limitaron a cumplir con un temario, a forzar para conseguir que sus alumnos retuvieran un mayor número de datos y poco más.
         
Tal vez en disciplinas como la física o las matemáticas, retener un montón de fórmulas garantice al menos que habremos adquirido un conocimiento inmutable al que, con suerte, le podremos sacar alguna utilidad. En el caso de la seguridad informática hacer una aproximación formativa orientada a aprender programas o técnicas concretas es, en el mejor de los casos, la mejor forma de garantizar la obsolescencia en unos pocos meses (con suerte unos pocos años).
         
Cualquiera que pueda revisar manuales o libros sobre seguridad informática de hace unos pocos años y los contraste con la situación actual, se quedará extrañado al comprobar que hace no mucho se mencionaban herramientas de las que hoy día quedan muy pocas referencias y que están absolutamente olvidadas.
         
El libro que vd tiene en sus manos no es el típico libro técnico del que se puede esperar un conocimiento de unas cuantas herramientas que con suerte seguirán vigentes dentro de 2 años, este libro es un manuscrito atemporal, un libro que hace hincapié en la narrativa, en contar una historia que trasciende y mucho la parte técnica. Es, probablemente, la primera novela sobre seguridad informática escrita en España, un libro que se puede leer cuando las tapas aun tengan el brillo y color original, y mucho tiempo después, cuando el amarillo asome por las esquinas.

En este libro no solo se plasma el uso de una serie de herramientas que, obviamente cualquier profesional o aficionado al pentest debe conocer, se plasma una filosofía, una inquietud, una forma de pensar. La capacidad para crear una estrategia y adaptar tu mente a la de un pentester.
        
El verdadero valor de este libro va más allá de los datos puros y duros que podrás encontrar, su valor real es que, una vez te hayas introducido en el, es probable que nazca en ti la inquietud de seguir profundizando, de mantenerte al día.
        
Y todo ello gracias al fuerte carisma de sus personajes. Todos en alguna ocasión nos hemos sentido como Ángel, el protagonista, persiguiendo a nuestra Yolanda particular
        
En definitiva, este es un libro que ha sido escrito para terminar en la estantería de los libros que seguro prestarás a tus amigos, alejado varios metros de las cajas donde duermen aquellos otros de corte purista en los que un ampuloso autor trató de enseñarte a usar unas herramientas, técnicas y sistemas operativos que, como la Coca Cola una vez abierta, pasado un tiempo han perdido su efervescencia.

Leer más...

¿De quién es la culpa ahora?



No hay día en el que no haya víctimas de ciberestafas y/o delitos informáticos de cualquier índole, en muchos casos debido a la mala configuración de los servicios, la falta de actualización del software de los equipos, de los antimalware, de los deficientes diseños en la arquitectura de sistemas, de la subcontratación de los servicios en la nube, etc,… Sin embargo, el otro 90% de las veces es por fallos humanos. El spam (por cualquiera de sus canales) y el phising, la ingeniería social, y en general, la superioridad de la "viveza" de unos cuantos sobre la ingenuidad de los demás, que hace que los sistemas de seguridad subyacentes no resulten efectivos. 

Cada vez son más los ciclos, seminarios, conferencias, congresos y cursos en los que explicamos a los asistentes lo importante que es estar concienciado de las amenazas de seguridad. Es decir, que nos centramos en emparanoiar a los usuarios contra los demonios que suponen las tecnologías y hacemos recaer sobre ellos toda la culpa por haber sido víctimas de un incidente de seguridad.

Por otra parte, nuestro compañero Yago, como ya evidenció años atrás en el segundo Security Blogger Summit, siempre ha mantenido una opinión diferente al respecto, en el que los fabricantes de las soluciones de software que tengan vulnerabilidades (y sobre todo aquellos que pasen olímpicamente de solucionarlas habiendo sido reportadas) deberían pagar por ello.

De momento, ninguna de las posturas, en las que el culpable es el usuario y la que el culpable es el fabricante, son penadas por la ley. Aunque según leo en The Inquirer, ha sido noticia la condena a un banco americano por un fallo de seguridad en sus sistemas. El incidente se produjo cuando al cliente del banco (una empresa constructora) le vaciaron la cuenta mediante la utilización de malware. Inicialmente le dieron la razón al banco, pero tras la apelación ante el fallo, el tribunal le ha dado la razón al cliente obligando a devolver la cantidad robada, además de intereses y costes legales.

En este caso es un banco, que obviamente es uno de los objetivos principales de los ciberataques, debido a que es donde se encuentra el dinero pero ¿Será este el detonante para que, por ejemplo empresas prestadoras de servicios que cometen negligencias en las configuraciones de seguridad en sus ofertas, se lo empiecen a tomar en serio y no recaiga la responsabilidad en los usuarios?

En mi caso personal, mi opinión se encuentra dividida. Por una parte, estoy de acuerdo con Einstein en que "El Universo y la estupidez humana son infinitos, aunque de lo del Universo no estoy tan seguro". Por otro lado, estoy de acuerdo con Yago, en que los fabricantes de software deberían asumir su responsabilidad cuando, por no parchear responsablemente a tiempo una vulnerabilidad reportada, ésta se explotara de una forma masiva. Me viene a la cabeza cuando tuvo un buen protagonismo en la red la botnet Flashback, por culpa de la negligencia de Apple al no publicar un parche para su implementación de Java, dejando a los usuarios con dos meses de exposición. En este caso, Apple debería haber recibido una sanción ejemplar, que habría salido en todos los medios de comunicación y que sentaría un precedente y levantaría un flag al resto de los fabricantes de software al ver lo que les puede llegar a suponer. 

Está claro que sólo aprendemos de dos formas: a palos y a multas.
Leer más...

02 diciembre 2012

Enlaces de la SECmana - 151


Leer más...

01 diciembre 2012

Detectando dominios Fast-Flux

Las redes Fast-Flux se llevan utilizando desde hace tiempo para distribuir malware y phishing. El uso de Fast-Flux por parte de los criminales dificulta el poder mitigar fácilmente la amenaza en concreto.
La idea básica sobre este tipo de redes es dado un nombre de dominio

flu-project.com

Tenga asignadas varias direcciones IP

Vamos a ver un ejemplo de un dominio que no utiliza sistemas Fast-Flux, realizamos una consulta DNS para que nos devuelva todas las IP a las que resuelve un dominio en concreto.

seifreed@darkmac:~:dig flu-project.com
; <<>> DiG 9.8.1-P1 <<>> flu-project.com;; global options: +cmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59428;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:;flu-project.com. IN A
;; ANSWER SECTION:flu-project.com. 890 IN A 134.0.11.133
;; Query time: 120 msec;; SERVER: 172.19.1.12#53(172.19.1.12);; WHEN: Mon Sep 17 16:15:19 2012;; MSG SIZE  rcvd: 49


Como veis no hay múltiple IP resolviendo a un dominio, además el TTL no es tan bajo como ocurre en las redes Fast-Flux.
Realizamos una comprobación ahora con un dominio que si que usa redes Fast-Flux


seifreed@darkmac:~:dig datesbooking.com

; &lt;&lt;&gt;&gt; DiG 9.8.1-P1 &lt;&lt;&gt;&gt; datesbooking.com
;; global options: +cmd
;; Got answer:
;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, status: NOERROR, id: 40922
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;datesbooking.com.  IN A

;; ANSWER SECTION:
datesbooking.com. 300 IN A 222.106.31.112
datesbooking.com. 300 IN A 71.196.187.168
datesbooking.com. 300 IN A 194.90.36.187
datesbooking.com. 300 IN A 67.175.74.110
datesbooking.com. 300 IN A 186.156.6.65

;; Query time: 153 msec
;; SERVER: 87.216.1.65#53(87.216.1.65)
;; WHEN: Thu Aug 23 00:32:11 2012
;; MSG SIZE  rcvd: 114

El dominio resuelve a varias direcciones IP.

Para verlo de manera más gráfica podemos consultar el gráfico de Robtex



En las redes Fast-Flux existen de dos tipos, las redes Single Fast-Flux y Dobe Fast-Flux.

Single Fast-Flux

Las redes single Fast-Flux, es la implementación más sencilla. Cuando una víctima intenta acceder a un determinado dominio, la respuesta del DNS se corresponde con una dirección IP de los equipos infectados, que varían continuamente, que capturarán la petición del cliente y serán ellos quien negocien con el servidor donde se aloja el contenido. A pesar de que en general esta técnica se aplica al tráfico HTTP, indistintamente podría utilizarse con cualquier conexión tipo TCP o UDP. 

Doble Fast-Flux

Por otro lado las redes Doble Fast-Flux mantienen el concepto de las Single Fast-Flux pero añadiendo una capa más de redundancia. En este tipo de implementaciones, además de variar los registros A del DNS para que un mismo dominio resuelva direcciones IP diferentes, también varían los registros NS correspondientes a los servidores DNS autorizados. Por tanto, en este caso, las peticiones DNS de las víctimas son respondidas directamente por la red Fast-Flux.

Detección de redes Fast-Flux

La detección de redes que usen Fast-Flux es algo que se lleva haciendo desde hace tiempo, existen ya implementaciones en IDS que ayudan a detectar este tipo de redes. Ya expusieron como en el blog del proyecto HoneyNet

Existen también proyectos como pffdetect que realizarán las comprobaciones necesarias para detectar dominios que usen redes Fast-Flux
La herramienta posee las siguientes características:

Posibilidad de procesar un único dominio o lista de ellos
Múltiples formas de comprobar el AS de una dirección IP, entre las que se encuentran los servicios de Team-Cymru y la base de datos de MaxMind
Posibilidad de usar múltiples cores
Posibilidad de ejecutarse como aplicación de consola o importarse como módulo

Realizamos una comprobación con la herramienta en un dominio que use Fast-Flux


seifreed@darkmac:~/tools/malware/pffdetect:python pffdetect.py -d datesbooking.com -s 8.8.8.8 -m DNS

        |----------------------------------------------------------|
        |                  Fast-Flux domain detector               |
        |               Alejandro Nolla (z0mbiehunt3r)             |
        |                                      Powered by Buguroo! |
        |----------------------------------------------------------|

[*] Checking if datesbooking.com is a fast-fluxed domain (could take a while depending on domain TTL)
   [!] Domain datesbooking.com is fast-fluxed
[-] Done

La herramienta ha sido capaz detectar si usa Fast-Flux o no. La herramienta funcionaría de la siguiente forma:

Se quiere comprobar si el dominio datesbooking.com usa técnicas Fast-Flux, la herramienta consulta y almacena que direcciones IP resuelven a dicho dominio. La herramienta se espera a que expire el TTL para que se tenga que volver a resolver dicho dominio. Realizando estas comprobaciones hay un alto grado de acierto en saber si un dominio usa técnica Fast-Flux.
Podéis encontrar la herramienta en Code Google

Artículo cortesía de Marc Rivero López

Leer más...