[VoiceOps] Phone hack

[Sandro Gauci]

Hi there,

It is likely that it is someone trying to find a SIP gateway / proxy that
is misconfigured and would relay SIP INVITEs without requiring
authentication (to commit toll fraud).

In this case, I think that the security hole that the attackers likely are
trying to exploit does not affect your customer's home workers.

As for solutions or mitigations (assuming you really cannot do anything
with the customer's router/firewall/nat device):


   - some phones can be restricted to only respond to INVITE messages
   coming from specific IP addresses (such as the SIP proxy address)
   - some phones can be restricted to only respond to INVITE messages where
   the SIP address is the one configured on the phone
   - you could change the SIP port to some high port - it will stop your
   customer's midnight callers at least for a while
   - switching to TCP might have the same effect, with the added benefit of
   not requiring NAT mapping (I think)

Had covered something like this on my blog:
http://blog.sipvicious.org/2012/12/if-sipvicious-gives-you-ring.html

As someone else mentioned, you can detect this sort of issue with your
customer equipment by sending an OPTIONS request. This is easily done using
SIPVicious svmap.py.



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 Fri, Sep 27, 2013 at 6:46 PM, PE <peeip989 at gmail.com> wrote:

> Greetings!
>
> We have a customer whose users work from home over the local broadband
> carrier. They have 3 users who have complained of similar circumstances,
> where they are receiving multiple calls from caller ID such as "100(100)",
> "101(101)",  and "1001(1001)". We show no record of these calls, either
> from CDR's, logs, or SIP captures, so it seems that there is an outside
> party sending SIP directly to the (Polycom) handsets.
>
> Anyone seen this? Any idea if there is a particular security hole being
> attempted? Assuming the users cannot control their broadband router, any
> suggestions on how to better lock this down?
>
> Thanks
>
> _______________________________________________
> 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/20130928/b0ec1819/attachment.html>