<div dir="ltr"><div>Hi all,<br></div><div><br></div><div>I'm the original author of SIPVicious and released the tools to help other</div><div>security professionals and netops etc to test their own systems. Needless to</div>
<div>say, the tools are abused.</div><div><br></div><div>The reason why you're getting these calls is that someone is probably using</div><div>svwar.py (part of the toolset) on your phones. Another contributing factor is</div>
<div>that the Polycom is probably ringing when any INVITE message it sent to it</div><div>rather than validating the IP address and/or the target SIP address. Yet</div><div>another potential factor is that the phones are using STUN or something like</div>
<div>that if they are behind NAT, to keep the port open and I'd guess that the</div><div>router just opens the port (UDP/5060) to any outside IP.</div><div><br></div><div>The persons causing your phone to ring are a misguided bunch and get nothing</div>
<div>out of getting your phone to ring (as far as I know). They are typically</div><div>looking for PBX servers and SIP gateways (especially ones with an FX0) that will either relay their calls or</div><div>(in the case of a PBX / SIP registrar) allow them to enumerate extensions via</div>
<div>an INVITE brute force.</div><div><br></div><div>Normally no spoofing of the SBC IP address is required in this case.</div><div><br></div><div>The solutions that Keith Croxford (for the Polycom config) gave should help</div>
<div>address this issue. The point is that the source of the call should be</div><div>validated and matched to a whitelist. </div><div><br></div><div>Other mitigations may involve changing the source port on the phones (which</div>
<div>doesn't really solve the issue) and switching to SIP TCP instead of UDP (since</div><div>this wouldn't require the port to be forwarded). Both solutions might not</div><div>really address the issue but rather try to fix the symptoms.</div>
<div><br></div><div>I had put a blog post on this topic:</div><div><br></div><div><a href="http://blog.sipvicious.org/2012/12/if-sipvicious-gives-you-ring.html">http://blog.sipvicious.org/2012/12/if-sipvicious-gives-you-ring.html</a></div>
<div><br></div><div>Feel free to contact me off-list to discuss further,</div><div><br></div></div><div class="gmail_extra"><br clear="all"><div>Sandro Gauci<br>Penetration tester and security researcher<br>Email: <a href="mailto:sandro@enablesecurity.com" target="_blank">sandro@enablesecurity.com</a><br>
Web: <a href="http://enablesecurity.com/" target="_blank">http://enablesecurity.com/</a><br>PGP: 8028 D017 2207 1786 6403 CD45 2B02 CBFE 9549 3C0C</div>
<br><br><div class="gmail_quote">On Wed, Nov 13, 2013 at 4:43 AM, Jay Hennigan <span dir="ltr"><<a href="mailto:jay@west.net" target="_blank">jay@west.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 11/12/13 6:40 PM, Jimmy Hess wrote:<br>
<br>
> I would suggest capturing packets towards the devices experiencing it,<br>
> behind the NAT device, using Wireshark ----- I would wonder first if<br>
> either the NAT/ACL isn't working as designed; or traffic is coming<br>
> from a SIP ALG / inside the NAT; spoofing the SBC's source IP seems<br>
> terribly unlikely.<br>
><br>
> I think it's more likely, there's an unexpected way the Polycom is being<br>
> contacted, such as a proxy service on a router.<br>
<br>
</div>Good idea, but these are typically remote customer sites and any<br>
individual phone maybe gets one of these ghost calls per day or two, so<br>
implementation is kind of tough.<br>
<div class="im"><br>
> Then there is that matter of; "Does your NAT device verify the<br>
> foreign IP address of reverse traffic like a full stateful firewall<br>
> would, or does it just check the destination port number on an<br>
> incoming packet, and immediately translate to internal IP based on<br>
> the destination port number and forward to the internal device?"<br>
><br>
> In the latter case, the internal device might be contacted on port 5060<br>
> from other internet hosts scanning the ephemeral port range; if<br>
> that 5060 from the internal device has recently been used as a source<br>
> port from the Polycom contacting the SBC.<br>
<br>
</div>That's kind of what I was thinking but we're also seeing it from behind<br>
an Adtran IAD with a SIP ACL that permits only our SBCs.<br>
<div class="im"><br>
> So a full packet capture from the network with the handsets, could give<br>
> you a better idea, of what you are seeing.<br>
<br>
</div>Absolutely agreed. The Polycom XML code mentioned earlier looks<br>
promising as well.<br>
<br>
The curious thing is that this is suddenly happening within the past two<br>
days on installations that have been trouble-free for months.<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Jay Hennigan - CCIE #7880 - Network Engineering - <a href="mailto:jay@impulse.net">jay@impulse.net</a><br>
Impulse Internet Service - <a href="http://www.impulse.net/" target="_blank">http://www.impulse.net/</a><br>
Your local telephone and internet company - 805 884-6323 - WB6RDV<br>
_______________________________________________<br>
VoiceOps mailing list<br>
<a href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a><br>
<a href="https://puck.nether.net/mailman/listinfo/voiceops" target="_blank">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
</div></div></blockquote></div><br></div>