Con la aparición de esta nueva versión de la herramienta, se amplía la lista de herramientas dedicadas exclusivamente a auditoría de redes de Voz sobre IP, como pueden ser SIPVicious, Voiper, sipdump/sipcrack, VoipPong, etc.

Puesto que cada día son más las empresas que llevan a cabo una unificación de sus comunicaciones, partiendo con la implantación de una red Voz usando su propia red local, y finalizando con la unificación total de sus comunicaciones (Voz sobre IP, mensajería unificada, servicio de presencia, etc.), la seguridad de la red se convierte en un aspecto crítico a tener muy en cuenta a la hora de realizar dicha integración, para garantizar, no solo la calidad del servicio, sino también la disponibilidad, confidencialidad e integridad de la informacion que atraviesa el sistema. Por lo tanto, en caso de disponer de sistemas VoIP en nuestra red, debe ser una buena práctica de seguridad llevar a cabo un plan de auditoría de vulnerabilidades específico contra los servicios que forman parte de dichos sistemas.

«Sgeún un etsduio de una uivenrsdiad ignlsea, no ipmotra el odren en el que las ltears etsan ersciats, la uicna csoa ipormtnate es que la pmrirea y la utlima ltera esten ecsritas en la psiocion cocrrtea. El rsteo peuden estar ttaolmntee mal y aun pordas lerelo sin pobrleams. Etso es pquore no lemeos cada ltera por si msima preo la paalbra es un tdoo. Pesornamelnte me preace icrneilbe…»

Lo han entendido, ¿verdad? En realidad, lo dicho no es del todo cierto (tiene que ver con como de desordenadas estén las palabras, cosas de la teoría de grupos) pero me viene de perlas para contarles que investigadores de la Universidad Johns Hopkins han realizado con éxito un ataque contra tráfico de VoIP cifrado, utilizando el tamaño de los paquetes cifrados para hacer suposiciones bastante acertadas sobre las palabras y frases utilizadas en las conversaciones.

Según los investigadores, “[...] esto ocurre porque la tasa de muestreo es alta para para sonidos largos y complejos como ‘ow’ (NT: fonemas ingleses), pero baja para consonantes simples como ‘c’. Este método variable ahorra ancho de banda, mientras mantiene la calidad del sonido.”.

Aunque los paquetes VoIP son cifrados para prevenir ‘escuchas a escondidas’, con esto han demostrado que simplemente midiendo el tamaño de los paquetes sin decodificarlos se pueden identificar palabras completas e incluso frases con una tasa de acierto bastante alta. Dicho de otra forma, el software de escucha desarrollado no puede decodificar una conversación completa, pero si que puede utilizarse para buscar palabras o frases concretas dentro de los paquetes de VoIP cifrados.

Dicho esto, lo primero que me viene a la mente es que el ingenio humano no tiene límites, y lo segundo, una sensación de asombro increíble; señores, ya no hace falta ni que descifren el mensaje, basta con que lo escuchen cifrado para hacerse una idea de lo que está usted hablando con su colega de San Francisco.

De todo esto pueden extraerse muchas conclusiones, pero yo prefiero quedarme con una que ya se ha comentado por aquí, y es que no se puede basar la seguridad de un programa/algoritmo/protocolo y/o servicio en el oscurantismo; todos los proyectos de software libre que versan sobre VoIP (ekiga, OpenWengo, KPhone, etc) han dicho ya que van a modificar sus fuentes para evitar este tipo de ataques; skype todavía no ha dicho nada (hasta donde yo sé), aunque ni siquiera si todo esto va con él o no; es posible que este tipo de ataques no le influyan para nada, pero no lo sabremos nunca, su protocolo nunca ha sido hecho público al igual que sus aplicaciones.

Yo, a título personal, y en cuestiones de cifrado, no pienso dejar en manos de una no pienso dejar en manos de una implementación cerrada y propietaria la responsabilidad de mi seguridad; por esas mismas razones uso ahora GPG, libre y gratuito, y dejé de utilizar PGP allá por la versión 6.5.8.

Cosas del Software Libre. :-)

Actualmente, muchas implantaciones de VoIP no están correctamente planificadas, y por tanto, comparten el mismo medio físico para transmitir voz y datos; no existe una red paralela independiente ni, en muchos casos, independencia lógica de redes basadas en Vlans, por lo que es habitual encontrar conectados a un mismo switch, tanto teléfonos IP, como equipos de usuarios.

Partiendo de esta premisa, y usando ARP spoofing o envenenamiento de la caché ARP como mecanismo para realizar un ataque man-in-the-middle, podemos capturar, analizar e incluso escuchar las conversaciones VoIP que se generan en nuestra red. En nuestro caso, para realizar el ataque de ARP spoofing, vamos a usar ettercap y Wireshark para realizar la captura de tráfico, el cual ya trae funcionalidad y filtros para redes VoIP.

Como se puede observar, el proceso es realtivamente sencillo; mientras tenemos en ejecución ettercap generando peticiones ARP falsas, lanzamos una instancia de wireshark, para realizar la captura. Una vez abierto, realizamos los siguientes pasos:

Seleccionamos los parámetros de captura de la aplicación; desde el menú “Capture” seleccionamos la interfaz a través de la cual vamos a capturar tráfico (podemos seleccionar filtros de captura). Una vez establecidos, pulsamos “Aceptar” para comenzar la captura.

Durante la captura, en pantalla observaremos una gráfica con estadísticas de los protocolos capturados:

Una vez tenemos capturados un número considerable de paquetes, paramos la captura, tras lo cual, podremos ver en la consola de wireshark, la lista de paquetes capturados. En nuestro caso:

Llegados a este punto, podemos realizar distintos tipos de análisis de nuestra red VoIP:

» Estadísticas del protocolo de señalización SIP; pulsando en el menú “Statistics -> SIP -> Create Stat“, donde podremos ver estadísticas de los distintos tipos de mensajes del protocolo:

» Estadísticas del protocolo de transporte RTP; seleccionamos uno de los paquetes RTP capturados y pulsamos en el menú “Statistics -> RTP -> RTP Streams“, donde podemos ver los flujos RTP capturados, jitter, códec usado…

No obstante, la opción más interesante la hemos dejamos para el final. Si pulsamos en el menú “Statistics -> VoIP Calls” podemos ver todas las llamadas capturadas:

Una vez tenemos la lista de capturas, podemos seleccionar una llamada cualquiera, y obtener datos más concretos, como puede ser el intercambio de mensajes de señalización SIP (Pulsando la opción Graph).

Y finalmente, reproducir la propia llamada capturada. Tras pulsar el botón “Player” en la pantalla anterior y ajustar el jitter, decodificamos el paquete, y podremos ver los distintos streams de audio, pudiendo reproducirlos de forma independiente o conjunta:

Entrando ya de lleno en el campo de la seguridad, el protocolo SIP proporciona un mecanismo desafío-respuesta para realizar la autenticación, el cual esta basado en la autenticación HTTP. El esquema, conocido como Digest Authentication, evita el envío de la contraseña de los usuarios en texto plano puesto que hace uso de una función hash MD5 y de un secreto compartido por ambas partes: la contraseña.

Su funcionamiento es el siguiente: cuando un cliente intenta establecer una llamada con el servidor, éste responde con un mensaje que incluye un valor aleatorio (nonce) junto al dominio contra el que se va a autenticar (realm). Entonces, el cliente debe enviar una respuesta cifrada al servidor en un mensaje de tipo response, indicando el nonce, el realm junto con el nombre de usuario, el uri y la contraseña. Una vez recibidos estos datos, el servidor compara el valor de la respuesta del cliente con el resultado de cifrar él por su cuenta los mismos datos, con la contraseña que tiene del cliente.

El funcionamiento se puede ver de forma más clara en la imagen a continuación:

Analizando parte de las cabeceras de autenticación SIP, podemos ver la estructura de la autenticación durante el registro del cliente:

El cliente solicita el registro

El servidor envía al cliente el desafío

El cliente envía la respuesta al desafío generado por el servidor

Debemos tener en cuenta que si un atacante captura los mensajes descritos anteriormente durante la fase de registro del cliente, podría ser capaz de obtener el hash MD5 de la contraseña y quedar expuesto a ataques de fuerza bruta y diccionario, como veremos a continuación.

Cracking de contraseñas SIP

Teniendo presente el modelo de autenticación usado por SIP, y mediante ARP Poisoning (o ARP Spoofing, basado en suplantación de identidad por falsificación de tabla ARP) podemos lanzar un ataque Man-in-the-Middle y capturar tráfico mediante la aplicación wireshark en busca de peticiones de registro SIP, y por lo tanto, hashes de usuarios.

Una vez lanzado el ataque y con los datos capturados, podríamos usar la aplicación sipdump para extraer las peticiones de registro de clientes en nuestro servidor (también lo podemos usar directamente para llevar a cabo la captura de datos), de la siguiente forma:

Como se puede ver, tenemos dos logins de usuarios (ambos de la extensión 21) capturados que almacenaremos en el fichero logins.sip.

En este punto, podemos usar sipcrack para lanzar un ataque de diccionario contra los hashes obtenidos, o usar un ataque de fuerza bruta como John the Ripper:

Tras lo que, como podemos ver en este caso, obtendríamos la contraseña del cliente. En la siguiente entrada, aplicaremos parte de lo visto para realizar una captura completa de una conversación VoIP, mediante Ettercap y Wireshark.

Hasta entonces, de momento, por mi parte, nada más. Pasen un buen fin de semana y sean buenos.

El protocolo SIP define principalmente seis tipos de solicitudes:

y seis clases de respuestas:

Tengamos el siguiente ejemplo de una llamada SIP, cuya evolución se puede ver (con algo de dificultad) en la imagen de la izquierda, obtenida de una captura de datos:

Llegados a este punto, cabe destacar que SIP define mecanismos para garantizar la fiabilidad de las comunicaciones y depende del protocolo SDP (Sesion Description Protocol), que describe el contenido multimedia de la sesión; por ejemplo, el puerto IP (los clientes SIP usan el puerto 5060 TCP y UDP para conectar con los servidores SIP) y el códec que se utilizarán durante la comunicación, etc.

En el siguiente post, veremos, ya entrando en el terreno de la seguridad, autenticación y cracking de contraseñas SIP, y posteriormente, el proceso seguido en la captura de una conversación VoIP.

Hasta entonces, por mi parte, nada más.

Los paquetes de VoIP se encuentran en el protocolo RTP, el cual va encapsulado en paquetes UDP; no usa TCP porque éste es demasiado pesado para las aplicaciones de tiempo real. Puesto que el datagrama UDP no tiene control sobre el orden en el cual los paquetes son recibidos, o de cuanto tiempo requiere su transmisión, RTP resuelve este problema permitiendo que el receptor ponga los paquetes en el orden correcto y que no “espere” a los paquetes que se hayan perdido el camino o tarden mucho en ser recibidos. En la línea de lo comentado, a continuación podemos ver un esquema de la pila TCP/IP, en la cual observamos los distintos tipos de protocolos de transporte y su posición dentro de la pila.

Vamos a describir muy brevemente los protocolos de transporte más empleados para la integración de voz y datos: RTP y su protocolo de control RTCP, RTSP para sistemas de vídeo bajo demanda, y RSVP.

RTP (Real-time Transport Protocol) es un protocolo de nivel de aplicación utilizado para la transmisión de información en tiempo real (audio o vídeo), extremo a extremo sobre una red de paquetes. Fue publicado por primera vez como estándar en 1996 como RFC 1889, y actualizado posteriormente. Éste ofrece entrega de datos multicast para aplicaciones de streaming, videoconferencia, etc., siempre que la red proporcione los servicios. Es importante destacar en este caso que RTP no ofrece garantías sobre la calidad del servicio ni sobre el retraso de la entrega de datos, por lo que necesita el apoyo de capas más bajas que controlen la reserva de recursos (como por ejemplo el uso de RSVP que comentaremos al final).

RTP va de la mano de su protocolo de control, RTCP: RTP envía los datos y RTCP proporciona servicios de control y otras funcionalidades. Existe una variante llamada SRTP (Secure RTP) usada para aportar características de cifrado al canal RTP, pero en la que no entraremos aquí.

RTCP (RTP Control Protocol) se encarga de monitorizar la calidad del servicio y de proporcionar información acerca de los participantes en una sesión de intercambio de datos. El protocolo, definido en el RFC 3550, no está diseñado para soportar todas las necesidades de comunicación de una aplicación, sólo las más básicas. La principal función de RTCP es proporcionar una retroalimentación útil para mantener una calidad de distribución adecuada: los receptores de una sesión emplean RTCP para informar al emisor sobre la calidad de su recepción, incluyendo el número de paquetes perdidos, jitter (la variación en la latencia) y RTT (Round Trip Time, tiempo empleado por un paquete en realizar todo el circuito: llegar al receptor y volver de nuevo al emisor).

Los paquetes RTCP se envían de modo que el tráfico en la red no aumente linealmente con el número de agentes participantes en la sesión, ajustando el intervalo de envío de acuerdo al tráfico. Para ello, RTCP se encarga de transmitir periódicamente paquetes de control a todos los participantes de una sesión.

RTSP (Real-Time Streaming Protocol) es un protocolo a nivel de aplicación que optimiza el flujo de datos multimedia. En sintaxis y funcionamiento, es similar al protocolo HTTP, donde tanto el cliente y el servidor pueden hacer peticiones. No obstante, a diferencia de HTTP, el protocolo RTSP necesita mantener información de estado. Entre sus principales ventajas, podemos destacar que debido a sus similitudes con el HTTP, hace que sea adaptable a proxys y firewalls, y es compatible con el modo de difusión multicast, siendo capaz de enviar la información a un grupo de clientes en un solo paso. Además, es independiente de la capa de transporte usada: puede utilizar tanto TCP como UDP.

Por el contrario, como desventajas podemos destacar que depende de la congestión de red, por lo que la pérdida de paquetes durante la transmisión es imprevisible, y si se trabaja en modo unicast, necesita un ancho de banda importante.

Finalmente, y como se ha comentado anteriomente, debemos mencionar el protocolo RSVP (Resource ReSerVation Protocol), usado para manejar la calidad de servicio de la comunicación, ya que hay que tener en cuenta que los paquetes IP son de longitud variable y el tráfico de datos suele ser a ráfagas. El propósito de RSVP es eliminar aquellas situaciones en las que la voz se pierde porque tenemos una ráfaga de datos en la red. Para ello, éste solicita ancho de banda, divide los paquetes de datos grandes y da prioridad a los paquetes de voz cuando hay una congestión en un router. Si bien este protocolo ayudará considerablemente al tráfico multimedia por la red, hay que tener en cuenta que RSVP no garantiza una calidad de servicio como sucede en redes avanzadas como ATM, que proporcionan servicios de QoS (Quality of Service, calidad de servicio) de forma estándar.

Y esto es todo en referencia a los protocolos de transporte. En la siguiente entrada, entraremos en detalle en el protocolo SIP, visto en el anterior post, para acabar con los detalles de la captura de una conversación VoIP.

En los últimos años, los protocolos de señalización para el servicio de transmisión de voz han experimentado una fuerte evolución, puesto que cada vez más, se están usando las redes de conmutación de paquetes para transportar tráfico de voz. Las necesidades de calidad de servicio hacen que sea necesaria una gestión de recursos que asegure la optimización de la capacidad de transporte de la voz extremo a extremo, para ello surgen los protocolos de la señalización.

Por señalización se entiende el conjunto de informaciones intercambiadas entre los dos extremos de la comunicación que permiten efectuar operaciones de:

• Supervisión (detección de condición o cambio de estado).
• Direccionamiento (negociación y establecimiento de llamada).
• Explotación (gestión y mantenimiento de la red).

Para cumplir los requerimientos de señalización existen principalmente tres protocolos: H.323, SIP y MGCP.

H.323 es una recomendación del ITU-T, que define los protocolos para proveer sesiones de comunicación audiovisual sobre paquetes de red donde no se garantiza la calidad de servicio. Éste se creó basándose en estándares existentes como H.320, RTP y Q.931, para proveer de un mecanismo para el transporte de aplicaciones multimedia en LANs (Redes de área local) pero ha evolucionado rápidamente para dirigir las crecientes necesidades de las redes de VoIP.

Aparte del modelo básico de llamada, el protocolo define servicios suplementarios, necesarios para dirigir las expectativas de comunicaciones comerciales. Los diseñadores de H.323 lo definieron de tal manera que las empresas pueden agregar sus propias especificaciones al protocolo que permiten a los dispositivos adquirir nuevas características o capacidades. Éste fue el primer estándar de VoIP en adoptar el estándar de IETF de RTP (Protocolo de Transporte en tiempo Real) para transportar audio y vídeo sobre redes IP.

SIP (Session Initiation Protocol) es un protocolo de control a nivel de aplicación desarrollado por el IETF con la intención de ser el estándar para la inicializacián, modificación y finalización de sesiones interactivas de usuario en las que intervienen elementos multimedia como el vídeo, voz, mensajería instantánea, juegos online y realidad virtual. Éste fue aceptado como protocolo de señalización en noviembre de 2000, y viene definido en el RFC 3261, desplazando así el estándar H.323 descrito anteriormente.

En relación con sus características, SIP es un protocolo cliente/servidor similar al HTTP, legible por humanos, comparte muchos códigos de estado y sigue una estructura de petición-respuesta, donde las peticiones son generadas por un cliente y enviadas a un servidor, el cual las procesa y devuelve la respuesta al cliente; el par petición-respuesta recibe el nombre de transacción. Al igual que el protocolo HTTP, SIP proporciona un conjunto de solicitudes y respuestas basadas en códigos.

Por último, MGCP (Media Gateway Control Protocol) tiene su origen en el SGCP (de Cisco y Bellcore), e IPDC. Es un protocolo de control de dispositivos, donde un gateway esclavo (MG, Media Gateway) es controlado por un maestro (MGC, Media Gateway Controller) o CAs (Call Agents).

MGCP soporta un control de señalización de llamada escalable, integrando el control de QoS (Quality of Service, Calidad de Servicio) en el gateway. Su compatibilidad con normas de IETF y con H.323 lo hace ideal para aplicaciones de multimedia sobre redes IP. Este protocolo presenta una arquitectura de control de llamada donde la inteligencia está fuera de las gateways y es manejada por elementos de control de llamada externos, conocidos como Agentes de Llamada. El protocolo MGCP presupone que estos elementos del control de llamada, o Agentes de Llamada, se sincronizan entre sí para enviar órdenes coherentes y respuesta a las gateways.

Aparte de los protocolos mencionados, podemos destacar también otros protocolos, como pueden ser el Megaco o H.248, Iax o Cisco SCCP (Skinny), pero son más específicos de algunos fabricantes.

Principalmente, las redes desarrolladas a lo largo de los años para transmitir voz se basan en el concepto de conmutación de circuitos, es decir, que la realización de una comunicación entre el emisor y el receptor requiere el establecimiento de un circuito físico durante el tiempo que dura ésta. Esto significa que los recursos que intervienen en la realización de una llamada no pueden ser utilizados en otra hasta que la primera no finalice, incluso durante los silencios que se suceden dentro de una conversación típica, por lo que las redes de conmutación de circuitos hacen un uso ineficiente de los recursos.

En el otro lado, las redes de datos se basan el concepto de conmutación de paquetes, es decir, una misma comunicación sigue diferentes caminos entre origen y destino durante el tiempo que dura. Esto significa que los recursos que intervienen en una conexión pueden ser utilizados por otras conexiones que se efectúen al mismo tiempo. Cuando un nodo quiere enviar información a otro lo divide en paquetes, cada uno de los cuales contiene la dirección del nodo origen y destino, e información acerca de cómo volver a unirse con el resto de paquetes. Este proceso permite que paquetes de distintas localizaciones se entremezclen en las mismas líneas y que sean clasificados y dirigidos a distintas rutas. Al llegar al nodo destino, se reensambla el mensaje y se entrega.

Es obvio que las redes basadas en conmutación de paquetes proporcionan a los operadores una relación ingreso/recursos mayor: con la misma cantidad de inversión en infraestructura de red, se obtienen mayores ingresos puesto que puede prestar más servicio a sus clientes; no obstante, este tipo de redes también tiene desventajas, ya que al transportar la información dividida normalmente en más de un paquete, estos paquetes pueden perderse, y además no hay una garantía sobre el tiempo que tardarán en llegar de un extremo al otro de la comunicación. Este problema trasladado a una conversación de voz podría provocar cortes o retrasos que harían que se perdiera el hilo de la conversación.

No obstante, estos problemas de calidad de servicio telefónico a través de redes de conmutación de paquetes van disminuyendo con la evolución de las tecnologías involucradas, y poco a poco se va acercando el momento de la integración de las redes de voz y datos, situación impulsada además por el hecho de que muchos operadores de redes de conmutación de paquetes se estén interesando en transportar voz a través de sus redes de datos. Esto es debido a que las redes de paquetes están dimensionadas para tráfico de datos, y el ancho de banda requerido para la voz es minúsculo, lo que genera beneficios como por ejemplo ahorro de costes, o ampliación de flexibilidad y movilidad con respecto a la Red Pública Telefónica Conmutada (PSTN).

En la actualidad, en todos los ámbitos y más concretamente en el ámbito empresarial, cada vez toma más importancia la convergencia en las láneas de comunicaciones. Concretamente, la integración de voz y datos a través de un único medio de transmisión está ganando adeptos con cada día que pasa. Actualmente, existen multitud de estudios sobre la implantación de soluciones VoIP y su expansión mediante VoIP móvil, en un futuro no muy lejano, a más de 200 millones de usuarios.

No debemos olvidar, para acabar esta breve introducción, los problemas de seguridad relacionados con las transmisiones VoIP. Éstas sufren todos los problemas de seguridad que afectan a las redes de datos tradicionales: denegaciones de servicio (DoS), spoofing o robo de identidad, la posibilidad de acceso a los datos transmitidos (información de la llamada o incluso de la propia conversación). Además, todos los dispositivos implicados, tales como teléfonos o centralitas, pueden ser vulnerables puesto que son elementos hardware que tienen un sistema operativo y un software concreto, y que por lo tanto, están expuestos a bugs o agujeros de seguridad que comprometan el sistema.

Sirva esta entrada como introducción. En posteriores artículos entraremos en más detalle en esta tecnología.