Hace unas semanas fue presentada (el autor también fue invitado al VUC) la utilidad svrash.py, de la suite de seguridad SIPVicious. Con esta utilidad es posible hacer que las utilidades svwar.py y svcrack.py se dentengan, ya que les provoca una excepción. ¿WTF?
Así es, svcrash es capaz de detener los ataques causados desde SIPVicious. Su autor no programó las utilidades para que la gente lanzara ataques contra otros, sino para que cualquiera pudiera comprobar el nivel de seguridad de sus propios sistemas, pero como hay malos sueltos por ahí que utilizan las herramientas de un modo bastante dudoso, programó svcrack.
Svcrash aprovecha un bug (tal vez dejado intencionadamente) para convertirlo en una feature: todas las versiones de SIPVicious tienen un bug que provoca la parada del programa debido a una excepción no controlada si se le envía un To tag con determinada forma. El funcionamiento de svcrash es sencillo: responde a los requests enviados por svcrack o svwar con un 200 OK con el To tag adecuado para provocar una excepción. El autor incluso ha añadido un modo automático, en el cual svcrash funciona en modo demonio leyendo los logs de Asterisk, y responde con éstos 200 OK (con el To tag adecuado) en caso de que Asterisk indique un fallo de autenticación en los logs.
Podéis ver un vídeo de su funcionamiento aquí.
Además de ser una manera elegante de terminar un ataque, el concepto de svcrash me hizo pensar un rato… ¿y si en lugar de bloquear o evitar un ataque simplemente contraatacamos, llegado el momento?
Supongamos el siguiente escenario: estamos sufriendo un ataque con el objetivo de adivinar el password de alguno de nuestros usuarios SIP. Lo habitual al detectar el tráfico generado por éste tipo de ataques suele ser bloquear el acceso de la IP en cuestión. Pero eso no quiere decir que el atacante haya dejado de enviar paquetes. El atacante podría enviarnos tráfico desde distintas IPs de manera dinámica, lo que haría más complicado bloquearlo, aunque tampoco imposible.
Si «la mejor defensa es un buen ataque» aquí va una idea: extender el concepto de svcrash y crear una suite de anti-hacking para SIP. Las herramientas de ataque para SIP no suelen implementar un completo cliente SIP, básicamente se quieren enviar paquetes SIP por un socket rápido o con ciertas credenciales. Por lo tanto, podríamos suponer que la herramienta que nos ataque haya dejado algún caso sin contemplar en su parser y podríamos provocar una excepción en la aplicación con una respuesta especialmente preparada (tal y como hace svcrash). Aquí van unas cuantas ideas que se me ocurren a botepronto:
- Que la respuesta empiece con «SIP/1.0 200 OK».
- Utilizar unicode en las cabeceras From y To. (el soporte unicode es algo en lo que casi nunca se piensa desde el principio…)
- Eliminar cabeceras de manera arbitraria: responder sin Contact, sin From ni To, …
- …
Es solo una idea, pero sería interesante ver alguna herramienta que empiece a responder con alguna de las respuestas malvadas cuando detecte X intentos de autenticación fallidos, ¿no creéis?
Happy anti-hacking! 🙂