25 Oct
2007
25 Oct
'07
12:49 p.m.
El Thursday 25 October 2007 11:34:15 Raúl Alexis Betancor Santana escribió:
No entiendo, yo mismo hice la prueba y la vulnerabilidad existe:
- Desde userA@domA llamo a userB@domB.
- Me fijo en el Contact que envía el userB (que ha sido corregido por OpenSer
con la IP pública y puerto por la que sale nateado).
Si yo más tarde llamo directamente a esa IP del contact (IP pública) mi
OpenSer la identifica como outbound ($rd != dominio local) y la ruta
directamente, es decir, la ruta a la IP pública nateada del userB, y como es
el OpenSer quien lo envía atraviesa el NAT y llega al userB.
Insito en que todo esto lo tengo exaustivamente comprobado. Me puedes llamar
paranoico (y acertarás) pero lo que describo insisto en que es real.
Si mi OpenSer reenvia las llamadas outbound a otro proxy2 entonces cuando
dicho proxy2 encamine la llamada a la IP del Contact de userB se pegará el
leñazo con el NAT ya que sl router NAT no conoce conoexiones salientes desde
userB a proxy2.
Saludos y gracias de nuevo.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
No entiendo
porqué hablas ahora de diálogos en curso, no entiendo qué
tiene que ver, yo hablo de un INVITE inicial pero que no va a @domB sino
a @IP_contact_B (por lo que se ruta como Outbound) y en definitiva llega
al usuario B ya que dicho usuario permite llamadas (nat pinging tras
REGISTER) desde el proxy.
Umm, error de concepto, tu OpenSer no tiene porqué usar los mismos datos de
contacto que tiene del register para hacer esta llamada Outbound, y sino
usa los mimos el Invite saliente hacia B se estampará contra el NAT de B De ahí que la
solución que veo es la de rutar las llamadas outbound a
otro proxy y así ya no se pueden "colar" aprovechando el natpinging.
Ahora mismo no tengo claro como .. pero estoy seguro de que no te hace
falta otro proxy para esto.