Hola, Saúl me ha comentado un fallo de seguridad en SIP bastante terrible y lo comento aquí junto con alguna posible solución que se me ha ocurrido:
El problema es éste: http://voipsa.org/pipermail/voipsec_voipsa.org/2007-November/002475.html
La clave está en que el atacante envía un INVITE a la víctima con un "Contact: num_PSNT@proxy_victima" y luego solicita auth a la víctima cuando ésta le envía un re-INVITE. Entonces finalmente el atacante dispone de un digest válido para hacer la llamada a ese número.
Vale, y en dicha lista de correo están bastante alarmados con esto por lo que supongo que en las soluciones que se me han ocurrido falla algo estrepitosamente:
1) Meter un "consume_credentials()" dentro de "loose_route()" para borrar la autenticación justo antes de enviar el paquete al destino. Es decir, entiendo que si un usuario@proxy.org es usuario de dicho proxy.org sólo tiene sentido que se autentique en ese proxy (a pesar de los divertidos esquemas del país de la piruleta que se ven en tech-invite.com con autenticaciones secuenciales y demás fricadas que luego sencillamente no existen).
2) Mirar el Contact y denegar el paquete si la URI en dicho Contact está prohibida (se corresponde con el proxy). El módulo "permissiones" permite esto para REGISTER pero no lo encuentro para otros mensajes, ¿no se puede hacer así? sería elegante.
En fin, ¿es grave doctor?
Saludos.
El 5/11/07, Iñaki Baz Castillo ibc@aliax.net escribió:
- Meter un "consume_credentials()" dentro de "loose_route()" para borrar la
autenticación justo antes de enviar el paquete al destino. Es decir, entiendo que si un usuario@proxy.org es usuario de dicho proxy.org sólo tiene sentido que se autentique en ese proxy (a pesar de los divertidos esquemas del país de la piruleta que se ven en tech-invite.com con autenticaciones secuenciales y demás fricadas que luego sencillamente no existen).
- Mirar el Contact y denegar el paquete si la URI en dicho Contact está
prohibida (se corresponde con el proxy). El módulo "permissiones" permite esto para REGISTER pero no lo encuentro para otros mensajes, ¿no se puede hacer así? sería elegante.
Como bien me han recalcado en la susodicha lista la vulnerabilidad se produce en un ataque directo, es decir llamado directa del atacante a la víctima sin pasar por el proxy de la víctima.
Ya he añadido allí que entonces la solución es bloquear el tráfico SIP a los clientes si no viene desde la IP del proxy. Esto puede ser vía el propio UAS (los Linksys tienen la opción de hacerlo) o vía firewall de la LAN de los clientes.
A todo esto, entonces ya no soy tan paranoico con lo de permitir llamadas directas a usuarios si el atacante conoce el "Contact" de uno de ellos, ¿no? XDDDDD
Hola Iñaki,
El 5/11/07, Iñaki Baz Castillo ibc@aliax.net escribió:
- Meter un "consume_credentials()" dentro de "loose_route()" para
borrar la autenticación justo antes de enviar el paquete al destino. Es decir, entiendo que si un usuario@proxy.org es usuario de dicho proxy.org sólo tiene sentido que se autentique en ese proxy (a pesar de los divertidos esquemas del país de la piruleta que se ven en tech-invite.com con autenticaciones secuenciales y demás fricadas que luego sencillamente no existen).
- Mirar el Contact y denegar el paquete si la URI en dicho
Contact está prohibida (se corresponde con el proxy). El módulo "permissiones" permite esto para REGISTER pero no lo encuentro para otros mensajes, ¿no se puede hacer así? sería elegante.
Como bien me han recalcado en la susodicha lista la vulnerabilidad se produce en un ataque directo, es decir llamado directa del atacante a la víctima sin pasar por el proxy de la víctima.
Ya he añadido allí que entonces la solución es bloquear el tráfico SIP a los clientes si no viene desde la IP del proxy. Esto puede ser vía el propio UAS (los Linksys tienen la opción de hacerlo) o vía firewall de la LAN de los clientes.
Y también, teniendo en cuenta que la gran mayoría de equipos están detrás de NAT, y NAT simétrico especialmente, la cosa no es tan grave.
A todo esto, entonces ya no soy tan paranoico con lo de permitir llamadas directas a usuarios si el atacante conoce el "Contact" de uno de ellos, ¿no? XDDDDD
Esto aún no lo he acabado de entender... me lo cuentas en Madrid con un mapa :)
Saludos JesusR.
------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
El Monday 05 November 2007 19:21:52 Jesus Rodriguez escribió:
A todo esto, entonces ya no soy tan paranoico con lo de permitir llamadas directas a usuarios si el atacante conoce el "Contact" de uno de ellos, ¿no? XDDDDD
Esto aún no lo he acabado de entender... me lo cuentas en Madrid con un mapa :)
Te tomo la palabra ;)
El Monday 05 November 2007 19:21:52 Jesus Rodriguez escribió:
A todo esto, entonces ya no soy tan paranoico con lo de permitir llamadas directas a usuarios si el atacante conoce el "Contact" de uno de ellos, ¿no? XDDDDD
Esto aún no lo he acabado de entender... me lo cuentas en Madrid con un mapa :)
Jesús, ya he implementado el mecanismo para evitar ese "gran" problema del que te hablaba (y que te dibujé con un mapa en el SIMO).
Finalmente queda: - He añadido una IP virtual. - OpenSer escucha en ella (por necesidad para poder rutar por ella). - Bloqueo mensajes entrantes por esa IP (miro $Ri). - Las outbound las saco por allí con: force_send_socket(IP_alias:5060);
Funciona perfectamente y la vulnerabilidad se acabó ;)
Gracias por toda la ayuda.
Hola Iñaki,
El Monday 05 November 2007 19:21:52 Jesus Rodriguez escribió:
A todo esto, entonces ya no soy tan paranoico con lo de permitir llamadas directas a usuarios si el atacante conoce el "Contact" de uno de ellos, ¿no? XDDDDD
Esto aún no lo he acabado de entender... me lo cuentas en Madrid con un mapa :)
Jesús, ya he implementado el mecanismo para evitar ese "gran" problema del que te hablaba (y que te dibujé con un mapa en el SIMO).
Finalmente queda:
- He añadido una IP virtual.
- OpenSer escucha en ella (por necesidad para poder rutar por ella).
- Bloqueo mensajes entrantes por esa IP (miro $Ri).
- Las outbound las saco por allí con: force_send_socket(IP_alias:5060);
Funciona perfectamente y la vulnerabilidad se acabó ;)
Genial! :)
Gracias por toda la ayuda.
De nada!.
Saludos JesusR.
------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
sr-users-es@lists.kamailio.org
-
Iñaki Baz Castillo -
Iñaki Baz Castillo -
Jesus Rodriguez