Las escuchas ilegales y demás vectores de ataque originados “desde dentro”, como el cracking de contraseñas, no van a ser objeto de estudio en esta ocasión por ser mucho menos comunes y tener fácil solución. Prácticamente la totalidad de ataques del exterior van a tratar de explotar el protocolo SIP, encargado de la señalización.
Podríamos establecer una clasificación sencilla de los mismos:
- Enumeración de extensiones/bruteforcing de contraseñas: En este apartado agrupamos ambos vectores de ataque ya que, en muchas ocasiones, el atacante no tiene claros los pasos para comprometer un servicio SIP. Su objetivo normalmente es obtener credenciales válidas para poder realizar llamadas (caras) a diferentes destinos. En ocasiones para vender los minutos y en otras para llamar a sus propios números de tarificación especial. En este post (y este otro) explico en detalle como realizar una auditoría mínima utilizando módulos de Metasploit, aunque también se podría hacer con la suite SIPVicious. En resumen, los pasos serían los siguientes:
- Se comienza por un escaneo SIP.
- A continuación se enumeran las extensiones por fuerza bruta.
- Finalmente se trata de hacer lo mismo para las contraseñas de las extensiones descubiertas en el paso anterior.
Como comentaba, los atacantes normalmente no realizan este proceso de forma correcta como veremos en los siguientes ejemplos de trazas reales:
- En este caso estamos la imagen muestra como el atacante trata de registrarse utilizando un usuario no válido en el sistema con distintas contraseñas, lo cual nunca va a generar resultados positivos. Se observa que la víctima responde con un reto a las peticiones, a partir de 5 intentos va a bloquear esa dirección IP. Esto se debe a la configuración que establecemos en las medidas de protección de nuestros servidores SIP. De esta forma se permite algún error en el registro de usuarios legítimos pero no un ataque de fuerza bruta o DoS.
- En el siguiente caso ahora no se responde a ninguna petición porque además implementamos una regla que bloquea todas las peticiones realizadas por el software SIPVicious (“User-Agent: friendly-scanner”). Aunque como podríamos imaginar en ocasiones los atacantes lo cambian para tratar de pasar desapercibidos.
-
INVITE attack: No son tan comunes, pero sí se ven alguna vez. En este caso el atacante trata de llamar (paquete INVITE) sin estar registrado previamente, el objetivo final es el mismo que para el caso anterior, realizar una llamada a un número de teléfono para obtener algún beneficio. Realmente no funcionan con la configuración por defecto de la mayoría de los sistemas SIP típicos ya que, aunque se permiten INVITES (llamadas) a usuarios no registrados, previamente se les solicita una autenticación por medio de un reto. Este proceso funciona de forma análoga al caso del registro. Mi amigo Pepelux publicó hace tiempo un ejemplo, así que no me voy a repetir.
-
DoS/DDoS flood: Debido a que la mayor parte de los ataques destacan por su escasa eficiencia, tal y como se expuso, a efectos prácticos pasan a convertirse en ataques típicos de DoS. Además, solo es cuestión de tiempo que grupos hacktivistas, organizaciones y gobiernos comiencen a explotarlo, al igual que hacen con los servicios web. Este último año aparecieron iniciativas relacionadas, como Occupy Phones, que tratan de inundar los números de teléfono públicos de los objetivos. Utilizan la VoIP como herramienta para abaratar costes, o para hacerlo de forma gratuita utilizando sistemas comprometidos. Como curiosidad comentar que ya existen empresas que incluso ofrecen el “servicio” de floodear por encargo a determinados objetivos.
En comparación con la web, en mi opinión, el impacto es mucho mayor en sistemas VoIP. Ya que una pequeña variación en el ancho de banda disponible, podría afectar produciendo micro-cortes en conversaciones y bloquear nuevos registros. Por todo esto mi proyecto de fin de carrera se centró en el estudio de las posibilidades de explotación del mismo en esta tecnología. En él se expone como durante la realización de test de rendimiento de las medidas de protección anti-DoS de distintos dispositivos SIP, nos encontramos que las herramientas disponibles en la actualidad compartían una problemática común:
- Falta de actualización y flexibilidad, por ejemplo SIPp es una herramienta muy potente pero solo permite manipular las cabeceras SIP. No ofrece la posibilidad de hacer lo mismo en cabeceras inferiores, lo cual es necesario para comprobar como se comportan las defensas ante un ataque DDoS.
- Heterogeneidad en lenguajes de programación y estructura, lo cual complica su utilización y sencillez a la hora de realizar modificaciones en las mismas.
- Ausencia de mecanismos de generación de informes.
La opción elegida para solventarlo fue desarrollar distintos módulos de Metasploit que nos permitiesen realizar estos tests de una forma completa. Realmente ya están publicados en mi PFC pero adjunto aquí las versiones definitivas mucho más fieles al protocolo y, por lo tanto, más eficientes. Las imágenes muestran el módulo en funcionamiento contra un FreeSWITCH y un Asterisk. Se envían paquetes INVITE, por ser los que más fácilmente saturan un servidor SIP, como se detalla también en el proyecto.
¿Como protegernos? Afortunadamente las contramedidas para los vectores descritos son las mismas, para no alargarme demasiado paso a resumir las más conocidas a día de hoy:
-
Medidas genéricas aplicables a cualquier servidor como mantenerlo actualizado, utilizar contraseñas seguras, uso de IPtables, etc.
-
Fail2ban: Es un software que trabaja de forma conjunta con Asterisk. Su funcionamiento es simple, cuando detecta un cierto número de peticiones de una misma dirección IP lanza una orden. Normalmente una regla de IPtables para bloquear dicha dirección. El problema principal es que trabaja sobre los logs, por lo que a veces cuando bloquea una dirección es demasiado tarde.
-
Modulo PIKE: Cumple la misma función que Fail2ban pero lo hace de una forma mucho más eficiente y es parte del proxy SIP Kamailio.
-
Monitorización de llamadas: Siempre es necesario un control de los picos de llamadas sospechosos para tomar medidas en caso de que sea necesario.
-
Session Border Controller (SBC): Son, en resumen, un “todo en uno” para que organizaciones con grandes infraestructuras puedan gestionar el acceso a todas sus UC (Unified Communitacions) desde un mismo dispositivo de una forma relativamente cómoda y controlada. Realmente no representan a ningún elemento de una infraestructura VoIP estándar, fue un término inventado por los fabricantes para, según ellos, satisfacer las necesidades del mercado. El precio depende principalmente de la marca y de su naturaleza hardware o software, pero en cualquier caso es muy elevado. El coste de una instalación típica (hardware) ronda las decenas de miles de euros. Normalmente, además de disponer de distintas funcionalidades que facilitan la integración de servicios VoIP, ofrecen protección específica contra DoS y DDoS (xD) tanto para el caso de inundación como ante paquetes malformados. De este tema podríamos hablar largo y tendido ya que hay detractores y fervientes defensores, así que queda para otra ocasión. De momento voy a decir que a mí, personalmente, no me gustan las soluciones propietarias y que ninguna tecnología es la panacea.
Por este motivo en breve presentaré un nuevo proyecto personal como una posible alternativa a los sistemas propietarios para la protección frente a los vectores de ataque aquí presentados. El producto final será una caja negra (no tan negra) orientada a la securización de infraestructuras de Comunicaciones Unificadas. Entre otras, utilizará tecnologías como Kamailio, Snort y Homer, pero de momento prefiero no contar más. 😉
Bueno, pues todo listo por esta vez, se trataron diferentes temas así que si alguien tiene interés en algo en especial agradeceré que deje algún comentario para la próxima.
Un saludo.
Artículo cortesía de Jesús Pérez
Fuente: Security By Default