[OpenSER-Users-ES] Test Sipp: ¿Seguridad en "loose_route()" con " !has_totag()"?

Iñaki Baz Castillo ibc at aliax.net
Sat Sep 1 12:39:26 CEST 2007


Hola, se supone no hay que pedir Auth en un re-INVITE y que es suficiente con 
comprobar "!has_totag()" dentro de ""loose_route()".

Se me ha ocurrido probar el Sipp, crear un XML tratando de colarme al añadir 
un "Route" (para que pase por "loose_route()") y poniendo un tag aleatorio en 
el "To".

Entonces sólo con conocer la IP y puerto público donde escucha un cliente 
podemos llegar hasta él sin más que poner en el XML:

       INVITE sip:ibc at 86.35.221.20:22723 SIP/2.0
       Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
       Route: <sip:88.95.0.210;lr=on;ftag=[call_number]>
       From: sipp <sip:sipp at mydomain.org:[local_port]>;tag=[call_number]
       To: ibc <sip:[service]@[remote_ip]:[remote_port]>;tag=aaaaa
      ...

Y lanzando "sipp":

   sipp -sf mi-invite-trampa.xml ip_server -s ibc -r 100 -m 1 


Bueno, pues obviamente ese paquete es rechazado por MI cliente Twinkle (que es 
muy listo) y devuelve:

  481 Call Leg/Transaction Does Not Exist


Pero el caso es que llega. Es decir, existe una forma muy sencilla (la que he 
descrito) de echar algo de peste sobre una red interna por muy protegida que 
esté vía firewall (incluso aunque sólo permita paquetes SIP desde el proxy) y 
tan sólo conocer:
- Su proxy SIP.
- Un nombre de usuario.
- Su IP pública o bien la del NAT.
- Suponer que se mapea en el NAT el puerto también al 5060.


En fin, que lo que toca es entonces fiarse de los clientes SIP que sabrán 
rechazar estos mensajes por no pertenecer a ninguna transacción (al contener 
un "tag" en el "To" del que no se sabía nada).

Pero me vienen entonces a la cabeza todos esos ataques SIP que tumban algunos 
softphones como el X-Lite, OpenWengo y un montón más con sólo enviar algún 
parámetro con valor "malintencionado" (length = valor negativo y cosas así).


En fin, ¿qué opináis? ¿hay que dejar esto así sin más?

PD: Obviamente, aún en el caso de solicitar auth para el re-INVITE también 
podría repetir lo anterior enviando cualquier otro mensaje.

Saludos.



-- 
Iñaki Baz Castillo




More information about the Users-es mailing list