17 noviembre 2014

Bluebox-ng HowTo (I)

Más de un año después de publicar aquí la versión alpha de Bluebox-ng, por fin liberamos la primera estable esta semana en el Arsenal de la Black Hat Europa. Así que más o menos vamos a contaros lo mismo que explicábamos allí, ya que nos interesan mucho las opiniones de esta, nuestra comunidad.

Finalmente decidimos definir el proyecto como un escáner de vulnerabilidades VoIP/UC (Unified Communications).

Pero la idea es la misma, necesitábamos algo para automatizar todos los pasos manuales que seguíamos durante los test de intrusión específico en este tipo de entornos. Como sabemos, en otros como la web sí disponemos de multitud de opciones libres y de pago para este cometido. Pero no era así en nuestro caso, las escasas opciones no eran suficientes para nuestro fin (además de prohibitivas).

Antes de meternos en materia, comentar que está reescrito desde 0 en JavaScript, ya que el proyecto comenzó como un conjunto de scripts (en CoffeeScript), que "no escalaban". Ahora, a parte de el cliente de consola, se puede utilizar como una librería más de Node.js y es sencillo añadir nuevos módulos. Además ahora somos dos, estamos centrados en probarlo en entornos reales y, al mismo tiempo, empezando a añadir nuevas funcionalidades (ie: vectores para el protocolo DNS).

Para instalarla simplemente hay que tener Node (una versión actual por favor ;) y luego la forma más sencilla es utilizar el gestor de paquetes Npm como para cualquier otra librería/herramienta de este ecosistema:

npm i -g bluebox-ng

En Kali el script oficial para instalar node desde el repositorio de paquetes (y tenerlo actualizado de una forma cómoda) no funciona, así que dejo uno colgado para ahorraros trabajo, podéis usar el siguiente comando y listo:
curl -sL https://raw.githubusercontent.com/jesusprubio/bluebox-ng/master/artifacts/installScripts/kali.sh | sudo bash -

Como en todas las utilidades de este tipo disponemos de la opción de realizar un test de intrusión automático (del que hablaremos más adelante) o manual, lanzando los módulos y jugando con los distintos parámetros. Debemos aclarar que actualmente tenemos implementado un conjunto de vectores de ataque que consideramos "suficiente por ahora", pero nos queda mucho trabajo. Sabemos que la VoIP incluye a muchos más protocolos que SIP, y hay vectores muy interesantes que involucran a otros, como RTP. E incluso a distintos tipos de señalización como IAX, H323 o Skinny se siguen utilizando y también habría que contemplarlos. Aunque esto último nos preocupa menos, ya que SIP está "ganando la batalla" en estos últimos años.

En el artículo de la versión alpha hay algunos ejemplos cuya ejecución es muy similar, así que no los voy a repetir. Para ver uno actualizado, el siguiente muestra un escaneo SIP típico (lo mismo que el "svmap" del SIPVicious, para entendernos).

Podéis consultar todos los comandos podéis usar el tabulador o el comando "help". Con este mismo acompañando al nombre de un módulo nos ofrece la descripción del mismo. Entre ellos nos encontramos de distintos tipos:

  • Típicas herramientas de red: TCP ping, Whois, DNS resolve/reverse, Traceroute, Geolocation, Nmap ...
  • Vectores de ataque al protocolo SIP: Escáner, fuerza bruta de extensiones y contraseñas, llamadas sin autenticar, tests de stress, DoS, etc.
  • Fuerza bruta y explotación de la AMI (Asterisk Manager Interface) de Asterisk.
  • Seguridad: SHODAN, Exploitsearch, etc.
  • Fuerza bruta de protocolos comunes en estas infraestructuras: TFTP, SSH, MYSQL, SNMP, FTP, LDAP, etc.
  • Pijadas varias: Google Dorks y contraseñas por defecto de paneles de gestión web, un "dumb fuzzer" ...

shoot4.png

shoot5.png
Ayuda general

helpScan.png
Ayuda módulo "sipScan"

sipScan.png

sipScan2.png
Uso módulo "sipScan"

Como comentamos, la principal novedad es el modulo "auto", que hace el trabajo por nosotros. Los parámetros que recibe son los siguientes:

  • "targets": Pues eso, se le puede pasar una dirección IP o un rango en formato CIDR. Actualmente estamos añadiendo soporte para dominios SIP y DNS.
  • "srcHost": En la capa de aplicación el protocolo SIP incluye la dirección IP de origen, por lo cual debemos de indicarla de alguna forma. Por defecto se pasa el nombre de la interfaz de red y la herramienta será capaz de obtenerla de ahí. Si se decide "spoofearla" (útil en algunos casos) debemos de ser conscientes de que algunos servidores (según la configuración) van a enviar las respuestas a esta dirección en vez de a la nuestra. Si haces una auditoría fuera de tu red, a parte de redirigir los puertos, deberías utilizar "external" en este parámetro para que obtenga tu dirección IP utilizando icanhazip.com y la incluya en las peticiones.
  • "srcPort": Lo mismo pero para el puerto, en este caso por defecto usa el "real" (el mismo que a nivel de transporte).
  • "sipDomain": Si no se le especifica usará la dirección IP del objetivo, una configuración ampliamente usada. Pero existen casos en los que hace falta pasarlo, así que permitimos la opción.
  • "timeout"
  • "nmapLocation": En algún paso, que comentaremos más adelante, se utiliza el Nmap  por lo que necesitamos pasarle la ruta.
  • "profile": Típico perfil en una herramienta de este tipo, podemos elegir uno de los disponibles o utilizar el nuestro. Para una auditoría real deberíamos utilizar el "aggressive" evitando de esta forma dejarnos casos posibles sin probar.
  • "reportPath": Ruta para guardar el fichero ".html" generado con el informe.

Uso módulo "auto" (perfil "demo")

¿Qué hace todo esto? A parte de no disponer de herramientas adecuadas tampoco existe una metodología de facto, estilo OWASP, simplementes algunos apuntes incluidos entre otras más genéricas. Nuestra solución para esto fue revisar las vulnerabilidades conocidas y las secciones de seguridad de la documentación de los principales servidores libres y alguno propietario. De esa forma conseguimos especificar un conjunto de pasos para cubrir los casos más comunes, pero de momento no se le puede llamar metodología (estamos en ello ;). En el siguiente post lo explicaremos con calma y veremos cómo usar Bluebox-ng como una librería para implementar, por ejemplo, un sistema de "pentesting" continuo para nuestros servidores de voz.

Informe

Artículo cortesía de Jesús Pérez y Sergio García

18 comments :

Dat dijo...

Estimado, lejos lejos una de las mejores charlas que he escuchado (8.8) fue increíblemente entretenida y educativa, muchas gracias.

Felipe dijo...

Yo estuve en al charla del BSIDE!..muy entretenida y la mejor a mi gusto de ese evento...éxito en todo y que siga la evangelización!

Lorenzo Martínez dijo...

Muchas gracias por vuestros comentarios! Celebro que os hayan gustado ambas charlas :) Así da gusto ir a la conch... de la lora! jeje Un abrazo,

wat dijo...

Jesse.Rollwagen@ic.fbi.gov - $$$$$$$$$$$$$
best password ever.

random dijo...

Descargado e instalado. Sería fabuloso tener algún sistema vulnerable virtualizado para un lab de seguridad VoIP.
¿Publicaréis alguno?

Ronny Vasquez dijo...

Los de Eset hacen muy buenas palomitas, loncheras, vasos, linternas, sombrillas, etc.... jajajaja

Jesús Pérez dijo...

Buenas :). Pues no tenía pensado, pero sería una buena idea. Por si quieres ir probando hay alguna por ahí:
http://www.rebootuser.com/?page_id=1739
http://busy-tone.org/2012/11/busy-tone-vulnerable-pbx/

Lo que sea nos comentas ;)

Akiles bailoyo dijo...

Amigo a quien le funciono correctamente npm en kali a mi me tira un error cuando ejecuto npm start. A quien le pasa lo mismo???

random dijo...

Tienes la solución aquí mismo: http://www.securitybydefault.com/2014/11/bluebox-ng-howto-i.html

random dijo...

Estuve dándole bastantes vueltas trasteando a ciegas para ver qué información nos proporciona, aunque no tenga ni idea de por dónde tirar, y el escáner de extensiones por fuerza bruta me pareció un poco excesivo. ¿Cómo de relevante puede ser encontrar las extensiones activas? ¿Es conveniente hacer un escáner profundo para descubrir todas las posibles?
¿Ese método de fuerza bruta hace sonar los teléfonos correspondientes a las extensiones?
Gracias de antemano. Gran trabajo, es espectacular.

Jesús Pérez dijo...

Buenas, te cuento:
- Gracias por el feedback antes de nada :)
- En breve tendremos el nuevo post explicando todo con calma, normal que te lies de momento.
- Pues me parece interesante lo de valorar el sacar de la parte automática esa enumeración. El tema es que si sacamos todo lo que es fuerza bruta nos quedamos sin módulo "auto".
- Es muy relevante por dos razones. Por un lado te ahorras en la fuerza bruta de las contraseñas tener que adivinar extensiones válidas, lo cual es mucho trabajo. Además es una vulnerabilidad conocida en estos sistemas que, como pentesters, hemos de comprobar. Lo de la profundidad ya depende del tipo de auditoría, ámbito, etc.
- Interesante pregunta también, pues la respuesta es que si usas paquetes INVITE puede que suenen. Depende de la configuración de los teléfonos, la implementación del protocolo SIP que hagan, etc. Con los otros tipos de petición no deberían sonar.

random dijo...

No digo de sacar la fuera bruta, sino de moderarla. ¿Necesitamos encontrar 30 extensiones? Encontrada la primera ya sabemos que es vulnerable a esa fuga de información.
También tengo que añadir que cuando probé el brutalizador lo puse lo más bruto que pude durante unas 16 horas hasta que lo interrumpí. Aunque aún así, sigo sin entender por qué necesitaríamos TODAS las extensiones. Digo yo que con unos cuantos o con el privilegiado el trabajo ya está hecho, ¿no?
Perdona que esté pesado, pero es que me hago un lío.

Jesús Pérez dijo...

Buenas otra vez, no te preocupes, para eso estamos :). Te cuento, esto es una herramienta que trae alguna lista de extensiones incluida. Pero como para todas, es cosa del auditor utilizar una u otra (o añadir las suyas) según lo que necesite en casa ocasión. Para el caso del módulo "auto", como mentamos, hay distintos perfiles (https://github.com/jesusprubio/bluebox-ng/tree/master/artifacts/profiles) que puedes modificar, o añadir el tuyo y pasarle la ruta del fichero como parámetro. De todas formas, como decimos en el post de hoy, estamos pensando en empezar un nuevo proyecto. Así que te animo (y a todos los presentes) a participar desde un principio. :) https://gist.github.com/jesusprubio/8f092af4ca252e252eab

random dijo...

Oh, vale. No sé programar en node pero tampoco parece hacer falta para configurar los perfiles, están muy bien masticaditos.
Con lo del auto... Uf, ¿qué decir? ¿Alguna vez resultó de algo el autopwn de metasploit (Ahora suprimido)?
Como framework es brutal, y cambiando un par de líneas puedes tener perfiles para casi cualquier situación, pero sigo pensando que con descubrir si es vulnerable a la fuga de información ya tendríamos una enorme alerta en el report por la que seguir tirando.
Por eso el framework en node partiendo de lo que escribisteis en bluebox-ng es algo brillante en lo que pienso involucrarme lo que pueda.

Jesús Pérez dijo...

La idea no está clara todavía, se le dará forma en el IRC y el Gist ese, estás invitado :).

spotify codes dijo...

free spotify codes for you my friends.

free spotify premium code generator

Bhokali Kali dijo...

You may ask yourself why people hack facebook accounts ? The answer is simple.

Bhokali Kali dijo...

Our success price is the highest as well as we always supply the original password to their account.
hack facebook account