[VOIPSEC] Vonage To Make 911 An 'Opt-Out' Option

[Christopher A. Martin]

A properly deployed scenario should utilize sip digest authentication
with a fresh nonce provided by the SIP proxy.

Then the attacker would only receive a digest, which at this point would
only be open to a dictionary attack, which would not be trivial if a
robust password is used, and the window of opportunity would be short if
a fresh nonce is provided by the SIP proxy.

Just a thought.

-----Original Message-----
From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On
Behalf Of David Elbel
Sent: Monday, May 16, 2005 12:14 PM
To: Voipsec at voipsa.org
Subject: Re: [VOIPSEC] Vonage To Make 911 An 'Opt-Out' Option

There are people reportedly unlocking the linksys PAP2 from Vonage via 
spoofing dhcp, then DNS and then spoofing a http request response / xml 
config file(?) to point the device to your own VOIP system.The purpose
is to 
use the device as a general purpose FXS port in a make shift VOIP setup.

Apparently this is trivial once you have a test network and sniffer. The

only problem is that it is not practical in a production environment. 
Nothing would stop an attacker from using the same method. However, a 
solution to this problem (my suggestion is using PKI) would probably
prevent 
reverse engineering for compatibility purposes and there are far easier 
attacks; for example social engineering. But then it could be argued
time 
and time again that the more exposure any product has on a market, the
more 
susceptible it becomes to any attack no matter how complicated it may 
appear.

On 5/16/05, Robert Moskowitz <rgm at icsalabs.com> wrote:
> 
> At 01:32 PM 5/13/2005, Kirill Bolshakov wrote:
> 
> >I would suggest considering a couple more ways of either getting into
the
> >signaling path (for attacks on digest auth or for providing fake
servers)
> >or obtaining the password:
> >
> >If DNS is used, the attack may be mounted against the DNS server the
> >client is using. All SIP traffic gets redirected to the adversary's
> >server. Then setup a fake server (including fake emergency service), 
> mount
> >an attack on digest auth, etc.
> 
> Good. I did forget the DNS redirect attack. thanks.
> 
> >Using the achievements of the previous attack, or by simply calling
the
> >user's UA, a PROTOS-like attack may be mounted against the UA
software
> >implementation. In case there are flaws in the implementation, this
will
> >lead to either DoS or remote control of the UA. In the latter case,
an
> >attempt to fetch user's login/password is a natural step.
> 
> Hmmm. I am trying to figure out if this is separate from any other
attack
> against a workstation that results in data stealing. It is a more
focused,
> and perhaps knows more about what needs to be stolen. I guess since we
> want awareness of VoIP risks, getting UA writers to be diligent
warrents
> this being its own catagory.
> 
> 
> Robert Moskowitz
> Senior Technical Director
> ICSA Labs, a division of Cybertrust, Inc.
> W: 248-968-9809
> F: 248-968-2824
> VoIP: 248-291-0713
> E: rgm at icsalabs.com
> 
> There's no limit to what can be accomplished if it doesn't matter who
gets
> the credit
> 
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>
_______________________________________________
Voipsec mailing list
Voipsec at voipsa.org
http://voipsa.org/mailman/listinfo/voipsec_voipsa.org


_______________________________________________
Voipsec mailing list
Voipsec at voipsa.org
http://voipsa.org/mailman/listinfo/voipsec_voipsa.org