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).
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
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:
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" ...
Ayuda general
Ayuda módulo "sipScan"
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.
