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. Re: Phone hack (Mark R Lindsey)
2. Re: Phone hack (Sandro Gauci)
----------------------------------------------------------------------
Message: 1
Date: Fri, 27 Sep 2013 17:01:53 -0400
From: Mark R Lindsey <[email protected]>
To: "J. Oquendo" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [VoiceOps] Phone hack
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
On Fri, 27 Sep 2013, PE wrote:
> ...so it seems that there is an outside
> party sending SIP directly to the (Polycom) handsets.
On Sep 27, 2013, at 15:00 , "J. Oquendo" <[email protected]> wrote:
> If someone is hitting a device
> that is behind say NAT/FW/etc. (non-public IP addr) then
> you may have bigger problems.
If your customers Internet-facing routers have Full-Cone NAT, then it's likely
they're exposed.
I.e., any device on the Internet can send SIP back to the device if that
Internet device can figure out the port number from which the SIP was sent.
And in many cases, the NAT router will try to reuse the same port number that
was used by the internal device; i.e., in many cases, it'll be port 5060 facing
the Internet.
Want to test your customers? Send a SIP OPTIONS to their UDP/5060 of their
Internet-facing NAT device from some place other than your registrar/SBC.
>>> [email protected] +1-229-316-0013 http://ecg.co/lindsey
------------------------------
Message: 2
Date: Sat, 28 Sep 2013 10:00:38 +0100
From: Sandro Gauci <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [VoiceOps] Phone hack
Message-ID:
<CAOHmTTqBmDkqGguhbGc-Fj+rjF-auYRZkYXLmh=c=11wu6g...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
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: [email protected]
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 <[email protected]> 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
> [email protected]
> 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-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
VoiceOps mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/voiceops
------------------------------
End of VoiceOps Digest, Vol 51, Issue 9
***************************************
