Send VoiceOps mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://puck.nether.net/mailman/listinfo/voiceops
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of VoiceOps digest..."
Today's Topics:
1. Ghost calls - Sipvicious? (Jay Hennigan)
2. Re: Ghost calls - Sipvicious? (Hiers, David)
3. Re: Ghost calls - Sipvicious? (Keith Croxford)
4. Re: Ghost calls - Sipvicious? (Jimmy Hess)
5. Re: Ghost calls - Sipvicious? (Jay Hennigan)
6. Re: Ghost calls - Sipvicious? (Jay Hennigan)
7. Re: Ghost calls - Sipvicious? (Sandro Gauci)
----------------------------------------------------------------------
Message: 1
Date: Tue, 12 Nov 2013 15:37:44 -0800
From: Jay Hennigan <[email protected]>
To: VoiceOps <[email protected]>
Subject: [VoiceOps] Ghost calls - Sipvicious?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
We operate a hosted VoIP platform using Broadworks and over 90% Polycom
phones. We have a number of customers at diverse locations recently
reporting dead-air calls. These typically come from a source ANI of 100
or 7070 and have no audio.
Most of the phones are behind Adtran TA900 series IADs with NAT and a
SIP access list allowing only our own SBCs.
The calls don't show up in our SBC logs, nor do they show in the MOS
graphs on the Adtran voice quality monitoring.
Any ideas or suggestions on what is causing this or how to stop it?
--
--
Jay Hennigan - CCIE #7880 - Network Engineering - [email protected]
Impulse Internet Service - http://www.impulse.net/
Your local telephone and internet company - 805 884-6323 - WB6RDV
------------------------------
Message: 2
Date: Wed, 13 Nov 2013 00:05:50 +0000
From: "Hiers, David" <[email protected]>
To: Jay Hennigan <[email protected]>, VoiceOps <[email protected]>
Subject: Re: [VoiceOps] Ghost calls - Sipvicious?
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Maybe someone is spoofing your SBC IP address?
If the phone/UAS starts ringing as soon as it receives an INVITE from the UAC,
then the user is presented with a ringing call that can never be answered.
This unanswerable call might look quite a bit like an answered call with no
audio.
I can't see what useful info would be gained from such spoofing, but enough of
these could DOS you pretty hard.
David
-----Original Message-----
From: VoiceOps [mailto:[email protected]] On Behalf Of Jay Hennigan
Sent: Tuesday, November 12, 2013 15:38
To: VoiceOps
Subject: [VoiceOps] Ghost calls - Sipvicious?
We operate a hosted VoIP platform using Broadworks and over 90% Polycom phones.
We have a number of customers at diverse locations recently reporting dead-air
calls. These typically come from a source ANI of 100 or 7070 and have no audio.
Most of the phones are behind Adtran TA900 series IADs with NAT and a SIP
access list allowing only our own SBCs.
The calls don't show up in our SBC logs, nor do they show in the MOS graphs on
the Adtran voice quality monitoring.
Any ideas or suggestions on what is causing this or how to stop it?
--
--
Jay Hennigan - CCIE #7880 - Network Engineering - [email protected] Impulse
Internet Service - http://www.impulse.net/ Your local telephone and internet
company - 805 884-6323 - WB6RDV _______________________________________________
VoiceOps mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/voiceops
This message and any attachments are intended only for the use of the addressee
and may contain information that is privileged and confidential. If the reader
of the message is not the intended recipient or an authorized representative of
the intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication
in error, please notify us immediately by e-mail and delete the message and any
attachments from your system.
------------------------------
Message: 3
Date: Tue, 12 Nov 2013 17:06:10 -0700
From: Keith Croxford <[email protected]>
To: Jay Hennigan <[email protected]>
Cc: VoiceOps <[email protected]>
Subject: Re: [VoiceOps] Ghost calls - Sipvicious?
Message-ID:
<cahwxyoagadeoepqu-vuf0cx62cmvghw+6olcdzkfh5vtmzz...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Try this -
*Polycom -*
Add this to your config file. This will cause the phone to respond with a
'400 bad request' unless the INVITE comes from the registrar.
voIpProt.SIP.requestValidation.1.request="INVITE" voIpProt.SIP.
requestValidation.1.method="source"
*Adtran (Only applies to the local SIP stack (voice users, trunks etc) ) *
Add an ACL, which only lists your proxy/SBC IPs
ip access-list standard my-proxy
remark MY IP SPACE
permit x.x.x.x y.y.y.y log
!Apply the ACL as a sip access-class
ip sip access-class my-proxy in
On Tue, Nov 12, 2013 at 4:37 PM, Jay Hennigan <[email protected]> wrote:
> We operate a hosted VoIP platform using Broadworks and over 90% Polycom
> phones. We have a number of customers at diverse locations recently
> reporting dead-air calls. These typically come from a source ANI of 100
> or 7070 and have no audio.
>
> Most of the phones are behind Adtran TA900 series IADs with NAT and a
> SIP access list allowing only our own SBCs.
>
> The calls don't show up in our SBC logs, nor do they show in the MOS
> graphs on the Adtran voice quality monitoring.
>
> Any ideas or suggestions on what is causing this or how to stop it?
>
> --
> --
> Jay Hennigan - CCIE #7880 - Network Engineering - [email protected]
> Impulse Internet Service - http://www.impulse.net/
> Your local telephone and internet company - 805 884-6323 - WB6RDV
> _______________________________________________
> VoiceOps mailing list
> [email protected]
> https://puck.nether.net/mailman/listinfo/voiceops
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/voiceops/attachments/20131112/bbeebce3/attachment-0001.html>
------------------------------
Message: 4
Date: Tue, 12 Nov 2013 20:40:00 -0600
From: Jimmy Hess <[email protected]>
To: "Hiers, David" <[email protected]>
Cc: VoiceOps <[email protected]>
Subject: Re: [VoiceOps] Ghost calls - Sipvicious?
Message-ID:
<caaawwbuq-td+ogziyuygo+b0liu+e-za_z7vku4ucs+ztmg...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
On Tue, Nov 12, 2013 at 6:05 PM, Hiers, David <[email protected]> wrote:
> Maybe someone is spoofing your SBC IP address?
>
> I can't see what useful info would be gained from such spoofing, but
> enough of these could DOS you pretty hard.
>
I would suggest capturing packets towards the devices experiencing it,
behind the NAT device, using Wireshark ----- I would wonder first if
either the NAT/ACL isn't working as designed; or traffic is coming from
a SIP ALG / inside the NAT; spoofing the SBC's source IP seems terribly
unlikely.
I think it's more likely, there's an unexpected way the Polycom is being
contacted, such as a proxy service on a router.
Then there is that matter of; "Does your NAT device verify the foreign
IP address of reverse traffic like a full stateful firewall would, or
does it just check the destination port number on an incoming packet,
and immediately translate to internal IP based on the destination port
number and forward to the internal device?"
In the latter case, the internal device might be contacted on port 5060
from other internet hosts scanning the ephemeral port range; if that
5060 from the internal device has recently been used as a source port from
the Polycom contacting the SBC.
So a full packet capture from the network with the handsets, could give you
a better idea, of what you are seeing.
> David
>
--
-JH
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/voiceops/attachments/20131112/c1bd8819/attachment-0001.html>
------------------------------
Message: 5
Date: Tue, 12 Nov 2013 20:37:57 -0800
From: Jay Hennigan <[email protected]>
To: VoiceOps <[email protected]>
Subject: Re: [VoiceOps] Ghost calls - Sipvicious?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 11/12/13 4:06 PM, Keith Croxford wrote:
> Try this -
> *
> Polycom -*
>
> Add this to your config file. This will cause the phone to respond with
> a '400 bad request' unless the INVITE comes from the registrar.
>
> voIpProt.SIP.requestValidation.1.request="INVITE"
> voIpProt.SIP.requestValidation.1.method="source"
We will test this in the lab. Also suggested by Mauricio Lizano with
the caveat that it could break things.
>
> *Adtran (Only applies to the local SIP stack (voice users, trunks etc) ) *
>
> Add an ACL, which only lists your proxy/SBC IPs
>
> ip access-list standard my-proxy
> remark MY IP SPACE
> permit x.x.x.x y.y.y.y log
>
> !Apply the ACL as a sip access-class
> ip sip access-class my-proxy in
This has already been done.
--
Jay Hennigan - CCIE #7880 - Network Engineering - [email protected]
Impulse Internet Service - http://www.impulse.net/
Your local telephone and internet company - 805 884-6323 - WB6RDV
------------------------------
Message: 6
Date: Tue, 12 Nov 2013 20:43:17 -0800
From: Jay Hennigan <[email protected]>
To: VoiceOps <[email protected]>
Subject: Re: [VoiceOps] Ghost calls - Sipvicious?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 11/12/13 6:40 PM, Jimmy Hess wrote:
> I would suggest capturing packets towards the devices experiencing it,
> behind the NAT device, using Wireshark ----- I would wonder first if
> either the NAT/ACL isn't working as designed; or traffic is coming
> from a SIP ALG / inside the NAT; spoofing the SBC's source IP seems
> terribly unlikely.
>
> I think it's more likely, there's an unexpected way the Polycom is being
> contacted, such as a proxy service on a router.
Good idea, but these are typically remote customer sites and any
individual phone maybe gets one of these ghost calls per day or two, so
implementation is kind of tough.
> Then there is that matter of; "Does your NAT device verify the
> foreign IP address of reverse traffic like a full stateful firewall
> would, or does it just check the destination port number on an
> incoming packet, and immediately translate to internal IP based on
> the destination port number and forward to the internal device?"
>
> In the latter case, the internal device might be contacted on port 5060
> from other internet hosts scanning the ephemeral port range; if
> that 5060 from the internal device has recently been used as a source
> port from the Polycom contacting the SBC.
That's kind of what I was thinking but we're also seeing it from behind
an Adtran IAD with a SIP ACL that permits only our SBCs.
> So a full packet capture from the network with the handsets, could give
> you a better idea, of what you are seeing.
Absolutely agreed. The Polycom XML code mentioned earlier looks
promising as well.
The curious thing is that this is suddenly happening within the past two
days on installations that have been trouble-free for months.
--
Jay Hennigan - CCIE #7880 - Network Engineering - [email protected]
Impulse Internet Service - http://www.impulse.net/
Your local telephone and internet company - 805 884-6323 - WB6RDV
------------------------------
Message: 7
Date: Wed, 13 Nov 2013 13:14:40 +0000
From: Sandro Gauci <[email protected]>
To: Jay Hennigan <[email protected]>
Cc: VoiceOps <[email protected]>
Subject: Re: [VoiceOps] Ghost calls - Sipvicious?
Message-ID:
<CAOHmTTq4xN+9Egdg1i0UVxLGhr=4sDNgavMKhr=8zck=vxz...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi all,
I'm the original author of SIPVicious and released the tools to help other
security professionals and netops etc to test their own systems. Needless to
say, the tools are abused.
The reason why you're getting these calls is that someone is probably using
svwar.py (part of the toolset) on your phones. Another contributing factor
is
that the Polycom is probably ringing when any INVITE message it sent to it
rather than validating the IP address and/or the target SIP address. Yet
another potential factor is that the phones are using STUN or something like
that if they are behind NAT, to keep the port open and I'd guess that the
router just opens the port (UDP/5060) to any outside IP.
The persons causing your phone to ring are a misguided bunch and get nothing
out of getting your phone to ring (as far as I know). They are typically
looking for PBX servers and SIP gateways (especially ones with an FX0) that
will either relay their calls or
(in the case of a PBX / SIP registrar) allow them to enumerate extensions
via
an INVITE brute force.
Normally no spoofing of the SBC IP address is required in this case.
The solutions that Keith Croxford (for the Polycom config) gave should help
address this issue. The point is that the source of the call should be
validated and matched to a whitelist.
Other mitigations may involve changing the source port on the phones (which
doesn't really solve the issue) and switching to SIP TCP instead of UDP
(since
this wouldn't require the port to be forwarded). Both solutions might not
really address the issue but rather try to fix the symptoms.
I had put a blog post on this topic:
http://blog.sipvicious.org/2012/12/if-sipvicious-gives-you-ring.html
Feel free to contact me off-list to discuss further,
Sandro Gauci
Penetration tester and security researcher
Email: [email protected]
Web: http://enablesecurity.com/
PGP: 8028 D017 2207 1786 6403 CD45 2B02 CBFE 9549 3C0C
On Wed, Nov 13, 2013 at 4:43 AM, Jay Hennigan <[email protected]> wrote:
> On 11/12/13 6:40 PM, Jimmy Hess wrote:
>
> > I would suggest capturing packets towards the devices experiencing it,
> > behind the NAT device, using Wireshark ----- I would wonder first if
> > either the NAT/ACL isn't working as designed; or traffic is coming
> > from a SIP ALG / inside the NAT; spoofing the SBC's source IP seems
> > terribly unlikely.
> >
> > I think it's more likely, there's an unexpected way the Polycom is being
> > contacted, such as a proxy service on a router.
>
> Good idea, but these are typically remote customer sites and any
> individual phone maybe gets one of these ghost calls per day or two, so
> implementation is kind of tough.
>
> > Then there is that matter of; "Does your NAT device verify the
> > foreign IP address of reverse traffic like a full stateful firewall
> > would, or does it just check the destination port number on an
> > incoming packet, and immediately translate to internal IP based on
> > the destination port number and forward to the internal device?"
> >
> > In the latter case, the internal device might be contacted on port 5060
> > from other internet hosts scanning the ephemeral port range; if
> > that 5060 from the internal device has recently been used as a source
> > port from the Polycom contacting the SBC.
>
> That's kind of what I was thinking but we're also seeing it from behind
> an Adtran IAD with a SIP ACL that permits only our SBCs.
>
> > So a full packet capture from the network with the handsets, could give
> > you a better idea, of what you are seeing.
>
> Absolutely agreed. The Polycom XML code mentioned earlier looks
> promising as well.
>
> The curious thing is that this is suddenly happening within the past two
> days on installations that have been trouble-free for months.
>
> --
> Jay Hennigan - CCIE #7880 - Network Engineering - [email protected]
> Impulse Internet Service - http://www.impulse.net/
> Your local telephone and internet company - 805 884-6323 - WB6RDV
> _______________________________________________
> VoiceOps mailing list
> [email protected]
> https://puck.nether.net/mailman/listinfo/voiceops
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/voiceops/attachments/20131113/ea98d620/attachment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
VoiceOps mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/voiceops
------------------------------
End of VoiceOps Digest, Vol 53, Issue 10
****************************************
