[VOIPSEC] Vonage To Make 911 An 'Opt-Out' Option
bob at bobsplanet.com
Thu May 19 03:15:06 BST 2005
The scenario below seems like a variant on the "unlocked cell phone" gambit, which reflects users wanting to gain full use of a
device that they have purchased. For example, having just cancelled my Vonage service, I discover that they offer (essentially) to
sell me the device (i.e. they charge a penalty if I don't return it). The scenario you describe is one option for making usable a
device the end user may have just bought, and in that case doesn't seem like a security risk at all.
Having executed the attack below, cannot the information gathered also be used to fraudulently get service from Vonage (or
equivalent)? I.e. is the spoofing risk the same to both the server side and the client side?
From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On Behalf Of David Elbel
Sent: Monday, May 16, 2005 10:14 AM
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
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),
> >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
Voipsec mailing list
Voipsec at voipsa.org
More information about the Voipsec