[VoiceOps] Ghost calls - Sipvicious?

[Sandro Gauci]

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: sandro at enablesecurity.com
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 <jay at west.net> 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 - jay at impulse.net
> Impulse Internet Service  -  http://www.impulse.net/
> Your local telephone and internet company - 805 884-6323 - WB6RDV
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> 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-0001.html>