On 05-03 11:33, Hadriel Kaplan wrote: > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On Behalf Of > > Raphael Coeffic > > Sent: Thursday, March 05, 2009 4:48 AM > > > > The second difference is that it works > > right now with any publicly reachable SIP provider. > > I think I know what you mean by this statement, but maybe I don't. I think > you mean it "works" right now only on a publicly reachable SIP provider that > accepts INVITE requests from non-Registered Contacts. No? Or do you mean > you've done testing of all publicly reachable SIP providers and found this to > be an issue for all of them, right now?
I am not sure I understand how accepting/not-accepting INVITEs from non-registered contacts makes it different, could you elaborate? Roughly, as long as the attacker can establish a call with the victim and make him/her respond to 407 within the session (for example by forcing the UA to generate a re-INVITE), the attacker can get access to the victims credentials. In some cases (if the victim UA is only reachable through a proxy and the proxy removes its own credentials), the attacker would not be able to get the credentials for that proxy, but might be able to get credentials for another domain if the victim's UA is configured with multiple sets of credentials. I don't want to put words in Raphael's mouth, but he probably mentioned publicly reachable SIP providers because they typically place no restrictions on incoming calls for their users and thus this kind of attack can be easily tried with them. > And this is not to say the attack isn't interesting, or that publicly > reachable SIP providers actually *use* such security policies. I've been > surprised before about how some of them don't actually employ the security > mechanisms they have at their disposal. But not using available mechanisms > is very different from not having a way to do them. Yes, I agree, in this case it would be interesting to know how many of them actually remove used digest credentials before they forward SIP requests. Jan. _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [email protected] for questions on current sip Use [email protected] for new developments on the application of sip
