Siempre que se piensa en el concepto de la seguridad, se parte del concepto: Mínima superficie de exposición, mínimo privilegio posible. Concepto que si bien es importante, no implica que un servicio sea inexpugnable, pues si bien siempre se intenta que un servicio no sea accesible desde lugares indeseados, hay ciertos servicios tales como páginas web o centralitas de Asterisk, que tienen que tener cierta flexibilidad. Esa flexibilidad nos ofrece ciertas ventajas, pero al mismo tiempo pueden ser posibles objetivos de ataques no deseados... Ataques que siempre conviene tener en cuenta.
Es por ello que hay algunas herramientas que nos pueden ayudar a realizar auditorías sobre nuestras centralitas de Asterisk, y que pueden servirnos para "poner a prueba" nuestro sistema; ya que nos ayuda a prevenirnos de ataques reales que pueden ser muy dañinos. Supongamos que alguien se hace con el control de una extensión telefónica capaz de hacer llamadas internacionales; en muy poco tiempo el coste económico de la medida sería brutal. Es por ello que mediante estas herramientas podemos hacernos una idea de las fortalezas y debilidades de nuestra PBX. Hay múltiples herramientas, pero la más popular sería SIPVicious.
SIP Vicious es una herramienta de software libre muy extendida que incluso está incluida hoy en día dentro de la archi-conocida distribución Kali. Para poder utilizarla, esta utilidad usa por defecto el puerto 5060 para escuchar los mensajes de respuesta, a menos que esté en uso por nuestro propio Asterisk u otro servicio, en cuyo caso usaría el siguiente puerto que esté libre (5061,5062...); con lo que es importante tener esos puertos abiertos en el equipo atacante si queremos poder recibir los mensajes de respuesta.
La utilización es muy sencilla, y solamente requiere tener python instalado (el cual ya viene pre-instalado la gran mayoría de las veces) y si caso la herramienta git, si bien no es necesario al 100%, nunca viene mal tenerla instalada. En caso de no utilizar git, sí que sería necesario descargarnos la herramienta zip.
Para descargar la aplicación, siempre y cuando no se use Kali que ya la incluye por defecto, la cual se encuentra Github, se puede hacer desde la consola de dos formas; o bajando el fichero comprimido o vía git:
Vía git:
Vía directa:
Cualquiera de estos procedimientos dará como resultado una carpeta que puede llamarse sipvicious en caso de usar git, o sipvicious-master, pero independientemente del nombre ambos tienen el mismo contenido, dentro del cual el que nos interesa es el que se encuentra dentro de la subcarpeta sipvicous. Dicha carpeta tiene diferentes programas escritos en python, dentro de los cuales, 3 serían los que principalmente nos interesarían: svmap.py svwar.py y svcrack.py.
La primera herramienta, svmap.py, sería la que usaríamos para escanear un rango de IPs a nuestra elección, junto con sus respectivos puertos con el fin de ver si se encuentra alguna que dé como respuesta alguna PBX, como por ejemplo Asterisk. Dicho escaneo usaría la sintaxis:
El puerto sería opcional, y se podría poner un puerto únicamente si se desea; en caso de no usar ninguno, se usaría el puerto standard SIP, 5060. Con respecto a la IP que se desea escanear, se puede poner una sola o un rango de IPs, dependiendo de nuestras necesidades. En caso de querer testear solamente nuestro equipo, solamente con una IP sería suficiente...
En el apartado opciones, es opcional usarlo, pero una opción muy común sería la de INVITE, ya que es mensaje que se envía a una PBX cuando un usuario se desea registrar. Un comando de ejemplo podría ser:
Esto nos puede dar como resultado o bien un resultado nulo, que sería lo deseable, o bien que nos dé información de la PBX, incluyendo la versión que usa el equipo contrario. Por ejemplo, usando dicho comando contra mi Asterisk, me ha dado como resultado:
En caso de que se muestre este mensaje en nuestra centralita, lo ideal sería intentar ocultarlo lo antes posible, pues esto nos brinda dos datos a nuestro atacante. El primero es que el puerto 5060 tiene un Asterisk asociado, lo cual es susceptible a ataques, pero no solo eso, sino que además nos brinda la versión de éste, que puede ser más peligroso aún, ya que si uno conoce la versión de software que uno usa, puede buscar vulnerabilidades asociadas a dicha versión, que puede hacer innecesario el utilizar ataques de fuerza bruta contra la centralita.
Supongamos que hemos recibido el mensaje anterior, lo que pasaríamos a hacer ahora sería a intentar ver qué extensiones están "disponibles" en nuestro objetivo. Esto lo lograríamos mediante la segunda utilidad: svwar.py
La utilidad svwar, es una utilidad muy simple que se dedica a mandar peticiones de registro contra la centralita objetivo. Si la PBX devuelve un mensaje "No matching peer found" o no respondiese, consideraría que no hay una extensión asociada, pero en caso de que considerase que la contraseña introducida para el registro, no es correcta, interpretaría que SÍ que hay una extensión, extensión contra la que se podría intentar hacer un ataque de fuerza bruta. La sintaxis es extremadamente simple en este caso:
Teniendo en cuenta que las extensiones, generalmente son de entre 3 y 4 dígitos, un ejemplo contra la PBX que tengo de pruebas podría ser:
Hay que tener en cuenta que a mayor el rango de extensiones, mayor el tiempo invertido. A modo de curiosidad, si tenemos una sesión de consola de Asterisk abierta en la máquina objetivo (el clásico asterisk -rvvvv), veremos un sin fin de mensajes parecidos a este; un mensaje por cada extensión no existente:
Al acabar el barrido, en caso de que alguna extensión le haya respondido a la herramienta, tendremos un resultado parecido al siguiente:
Ya sabemos todo lo que necesitábamos saber; sabemos que la IP 192.168.1.102, tiene un Asterisk montado en el puerto 5060 y además sabemos que hay una extensión 1001, configurada en dicha centralita. Solo queda usar la tercera herramienta mencionada antes, svcrack.py para intentar obtener, si se puede, la contraseña.
Los ataques aquí se pueden hacer de dos formas, o bien a fuerza bruta mediante dígitos, o bien vía diccionario. En caso de hacerlo mediante fuerza bruta, lo que se haría sería probar diferentes combinaciones numéricas hasta acertar con el número. En caso de que en cambio se optasen por un ataque de diccionario, se tendría que tener el diccionario, en formato txt y se recurriría a él para hacer el ataque; por ejemplo, para el ataque por fuerza bruta haríamos:
Donde después del -u se especificaría la extensión que se desea "atacar" y después del -r especificaríamos el rango de números a utilizar como contraseña. En este caso se ha usado una contraseña débil, y desgraciadamente bastante común; la cual ha tardado apenas unos segundos en descifrar la herramienta:
Para el ataque de diccionario en cambio, en vez de usar el parámetro -r, usaríamos el parámetro -d, seguido del diccionario que querríamos usar.
Mediante dicho método, el tiempo que tardaría en descifrar la contraseña variaría, pero en caso de usar contraseñas alfanuméricas, sería el único método posible.
COMO EVITARLO
Como siempre digo, la seguridad absoluta no existe, pero es cierto que al menos hay que intentar ponérselo difícil al atacante; es por ello que las dos primeras que hemos utilizado, para encontrar centralitas Asterisk, y para rastrear extensiones en la susodicha, se pueden evitar añadiendo una sola línea en el fichero /etc/asterisk/sip.conf:
Dicho parámetro en Asterisk 16 ya está habilitado por defecto (sin tener que siquiera añadir nada al fichero de configuración), pero en la gran mayoría de versiones no es así, con lo que es ideal ponerlo a mano en el fichero con el fin de estar seguros.
Al establecer un valor yes a dicho parámetro, lo que haríamos sería denegar la la respuesta a las autenticaciones de usuarios incorrectos o inexistentes, cosa que se hace mediante las herramientas svmap y svwar... Puede parecer un detalle sin importancia pero mediante la combinación de dicha media, junto con el uso de un puerto SIP no estandard (a poder ser un número de puerto muy alto), nos quitaríamos de un barrido el 90% de los scripts automatizados que se dedican a hacer barridos y ataques automáticos a los puertos 5060.
Eso no implica que mediante esto hagamos inmune a nuestra centralita, pero sí que evitaremos dar información al atacante, lo que hará que éste no empiece a hacer ataques de fuerza bruta contra una extensión nuestra centralita SIP, a menos que haya obtenido la información por otros medios.
Para los ataques de fuerza bruta que se hagan contra la extensión, solamente se pueden dar dos recomendaciones; la primera muy sencilla de implementar, la segunda ya depende de los medios que uno disponga.
La primera medida sería la obvia, usar contraseñas seguras para nuestras extensiones. A poder ser largas y alfanuméricas; es más al usar contraseñas alfanuméricas.
La segunda medida sería, no compleja, pero sí requeriría un cierto esfuerzo por parte de uno, y sería el uso de utilidades tales como Fail2ban, que entre otras cosas pueden bloquear los intentos repetidos de conexión/autenticación contra un destino. Hay que tener en cuenta que los ataques de fuerza bruta o de diccionario realizan un número ingente de autenticaciones, con lo que si lo podemos evitar mediante dicha herramienta podremos, dificultarle en gran medida el ataque a nuestro agresor.
Espero que os haya resultado útil, y que podáis sacarle partido a esta utilidad que puede ayudarnos a ver en si nuestra centralita esta debidamente protegida o no.
Saludos.
SIP Vicious es una herramienta de software libre muy extendida que incluso está incluida hoy en día dentro de la archi-conocida distribución Kali. Para poder utilizarla, esta utilidad usa por defecto el puerto 5060 para escuchar los mensajes de respuesta, a menos que esté en uso por nuestro propio Asterisk u otro servicio, en cuyo caso usaría el siguiente puerto que esté libre (5061,5062...); con lo que es importante tener esos puertos abiertos en el equipo atacante si queremos poder recibir los mensajes de respuesta.
La utilización es muy sencilla, y solamente requiere tener python instalado (el cual ya viene pre-instalado la gran mayoría de las veces) y si caso la herramienta git, si bien no es necesario al 100%, nunca viene mal tenerla instalada. En caso de no utilizar git, sí que sería necesario descargarnos la herramienta zip.
Para descargar la aplicación, siempre y cuando no se use Kali que ya la incluye por defecto, la cual se encuentra Github, se puede hacer desde la consola de dos formas; o bajando el fichero comprimido o vía git:
Vía git:
git clone https://github.com/EnableSecurity/sipvicious.git
Vía directa:
wget https://github.com/EnableSecurity/sipvicious/archive/master.zip
unzip master.zip
Cualquiera de estos procedimientos dará como resultado una carpeta que puede llamarse sipvicious en caso de usar git, o sipvicious-master, pero independientemente del nombre ambos tienen el mismo contenido, dentro del cual el que nos interesa es el que se encuentra dentro de la subcarpeta sipvicous. Dicha carpeta tiene diferentes programas escritos en python, dentro de los cuales, 3 serían los que principalmente nos interesarían: svmap.py svwar.py y svcrack.py.
La primera herramienta, svmap.py, sería la que usaríamos para escanear un rango de IPs a nuestra elección, junto con sus respectivos puertos con el fin de ver si se encuentra alguna que dé como respuesta alguna PBX, como por ejemplo Asterisk. Dicho escaneo usaría la sintaxis:
svmap.py -p puerto_inicio-puerto_fin IP_inicio-IP_fin -m opciones
El puerto sería opcional, y se podría poner un puerto únicamente si se desea; en caso de no usar ninguno, se usaría el puerto standard SIP, 5060. Con respecto a la IP que se desea escanear, se puede poner una sola o un rango de IPs, dependiendo de nuestras necesidades. En caso de querer testear solamente nuestro equipo, solamente con una IP sería suficiente...
En el apartado opciones, es opcional usarlo, pero una opción muy común sería la de INVITE, ya que es mensaje que se envía a una PBX cuando un usuario se desea registrar. Un comando de ejemplo podría ser:
./svmap.py -p 5060 192.168.1.102 -m INVITE
Esto nos puede dar como resultado o bien un resultado nulo, que sería lo deseable, o bien que nos dé información de la PBX, incluyendo la versión que usa el equipo contrario. Por ejemplo, usando dicho comando contra mi Asterisk, me ha dado como resultado:
En caso de que se muestre este mensaje en nuestra centralita, lo ideal sería intentar ocultarlo lo antes posible, pues esto nos brinda dos datos a nuestro atacante. El primero es que el puerto 5060 tiene un Asterisk asociado, lo cual es susceptible a ataques, pero no solo eso, sino que además nos brinda la versión de éste, que puede ser más peligroso aún, ya que si uno conoce la versión de software que uno usa, puede buscar vulnerabilidades asociadas a dicha versión, que puede hacer innecesario el utilizar ataques de fuerza bruta contra la centralita.
Supongamos que hemos recibido el mensaje anterior, lo que pasaríamos a hacer ahora sería a intentar ver qué extensiones están "disponibles" en nuestro objetivo. Esto lo lograríamos mediante la segunda utilidad: svwar.py
La utilidad svwar, es una utilidad muy simple que se dedica a mandar peticiones de registro contra la centralita objetivo. Si la PBX devuelve un mensaje "No matching peer found" o no respondiese, consideraría que no hay una extensión asociada, pero en caso de que considerase que la contraseña introducida para el registro, no es correcta, interpretaría que SÍ que hay una extensión, extensión contra la que se podría intentar hacer un ataque de fuerza bruta. La sintaxis es extremadamente simple en este caso:
svwar.py -e extension_inicio-extension_fin IP
Teniendo en cuenta que las extensiones, generalmente son de entre 3 y 4 dígitos, un ejemplo contra la PBX que tengo de pruebas podría ser:
./svwar.py -e000-9999 192.168.1.102
Hay que tener en cuenta que a mayor el rango de extensiones, mayor el tiempo invertido. A modo de curiosidad, si tenemos una sesión de consola de Asterisk abierta en la máquina objetivo (el clásico asterisk -rvvvv), veremos un sin fin de mensajes parecidos a este; un mensaje por cada extensión no existente:
Al acabar el barrido, en caso de que alguna extensión le haya respondido a la herramienta, tendremos un resultado parecido al siguiente:
Ya sabemos todo lo que necesitábamos saber; sabemos que la IP 192.168.1.102, tiene un Asterisk montado en el puerto 5060 y además sabemos que hay una extensión 1001, configurada en dicha centralita. Solo queda usar la tercera herramienta mencionada antes, svcrack.py para intentar obtener, si se puede, la contraseña.
Los ataques aquí se pueden hacer de dos formas, o bien a fuerza bruta mediante dígitos, o bien vía diccionario. En caso de hacerlo mediante fuerza bruta, lo que se haría sería probar diferentes combinaciones numéricas hasta acertar con el número. En caso de que en cambio se optasen por un ataque de diccionario, se tendría que tener el diccionario, en formato txt y se recurriría a él para hacer el ataque; por ejemplo, para el ataque por fuerza bruta haríamos:
./svcrack.py -u 1001 -r 0000-9999 192.168.1.102
Donde después del -u se especificaría la extensión que se desea "atacar" y después del -r especificaríamos el rango de números a utilizar como contraseña. En este caso se ha usado una contraseña débil, y desgraciadamente bastante común; la cual ha tardado apenas unos segundos en descifrar la herramienta:
Para el ataque de diccionario en cambio, en vez de usar el parámetro -r, usaríamos el parámetro -d, seguido del diccionario que querríamos usar.
svcrack.py -u 1001 -d diccionario.txt 192.168.1.102
Mediante dicho método, el tiempo que tardaría en descifrar la contraseña variaría, pero en caso de usar contraseñas alfanuméricas, sería el único método posible.
COMO EVITARLO
Como siempre digo, la seguridad absoluta no existe, pero es cierto que al menos hay que intentar ponérselo difícil al atacante; es por ello que las dos primeras que hemos utilizado, para encontrar centralitas Asterisk, y para rastrear extensiones en la susodicha, se pueden evitar añadiendo una sola línea en el fichero /etc/asterisk/sip.conf:
alwaysauthreject=yes
Al establecer un valor yes a dicho parámetro, lo que haríamos sería denegar la la respuesta a las autenticaciones de usuarios incorrectos o inexistentes, cosa que se hace mediante las herramientas svmap y svwar... Puede parecer un detalle sin importancia pero mediante la combinación de dicha media, junto con el uso de un puerto SIP no estandard (a poder ser un número de puerto muy alto), nos quitaríamos de un barrido el 90% de los scripts automatizados que se dedican a hacer barridos y ataques automáticos a los puertos 5060.
Eso no implica que mediante esto hagamos inmune a nuestra centralita, pero sí que evitaremos dar información al atacante, lo que hará que éste no empiece a hacer ataques de fuerza bruta contra una extensión nuestra centralita SIP, a menos que haya obtenido la información por otros medios.
Para los ataques de fuerza bruta que se hagan contra la extensión, solamente se pueden dar dos recomendaciones; la primera muy sencilla de implementar, la segunda ya depende de los medios que uno disponga.
La primera medida sería la obvia, usar contraseñas seguras para nuestras extensiones. A poder ser largas y alfanuméricas; es más al usar contraseñas alfanuméricas.
La segunda medida sería, no compleja, pero sí requeriría un cierto esfuerzo por parte de uno, y sería el uso de utilidades tales como Fail2ban, que entre otras cosas pueden bloquear los intentos repetidos de conexión/autenticación contra un destino. Hay que tener en cuenta que los ataques de fuerza bruta o de diccionario realizan un número ingente de autenticaciones, con lo que si lo podemos evitar mediante dicha herramienta podremos, dificultarle en gran medida el ataque a nuestro agresor.
Espero que os haya resultado útil, y que podáis sacarle partido a esta utilidad que puede ayudarnos a ver en si nuestra centralita esta debidamente protegida o no.
Saludos.
Los servicios de centralitas virtuales cada vez son mas demandados por las empresas. Ya que son una poderosa herramienta que le permite mejorar y aumentar el control de las comunicaciones de su empresa sin necesidad de instalaciones físicas.
ResponderEliminarTienes absolutamente toda la razón. De ahí que sea necesario tener las centralitas correctamente securizadas. Saludos.
Eliminar