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
On Fri, 27 Sep 2013, PE 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
I, and I'm sure others, have seen this before. There are ways to fix it, things to look for. However, I (and I'm sure others will agree), it helps when we can identify whom we are talking to. Its commonly known that attackers also browse, and subscribe to many lists in search of who is watching them, and who is stopping them, and how. This is not to say you're running amok with sipvicious causing havoc... So to answer your question as broadly asked: 1) Yes I have seen these scans hit handsets 2) It would never make your CDR since it is sent directly to a SIP device (phone, ATA, etc) 3) You're likely capturing on the PBX/SBC side, which it never hits so your packet capture is a moot point 4) Don't want to name possibly affected vendors. 5) Your SIP devices (Phones, ATAs, etc) should not be exposed to the world. If someone is hitting a device that is behind say NAT/FW/etc. (non-public IP addr) then you may have bigger problems. -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM "Where ignorance is our master, there is no possibility of real peace" - Dalai Lama 42B0 5A53 6505 6638 44BB 3943 2BF7 D83F 210A 95AF http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2BF7D83F210A95AF
We have not specifically seen this however we have played around with several of our SIP devices by setting them as public and poking holes in firewalls for direct IP dialing. With what we use I think the worst we have seen is customers making them available and having them hacked and FWD to international numbers (another thing to block by default). My suggestion is always use a firewall (or private vlan/network if your an ISP, etc). Brian
Date: Fri, 27 Sep 2013 14:00:58 -0500 From: joquendo at e-fensive.net To: peeip989 at gmail.com CC: voiceops at voiceops.org Subject: Re: [VoiceOps] Phone hack
On Fri, 27 Sep 2013, PE 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
I, and I'm sure others, have seen this before. There are ways to fix it, things to look for. However, I (and I'm sure others will agree), it helps when we can identify whom we are talking to. Its commonly known that attackers also browse, and subscribe to many lists in search of who is watching them, and who is stopping them, and how. This is not to say you're running amok with sipvicious causing havoc...
So to answer your question as broadly asked:
1) Yes I have seen these scans hit handsets 2) It would never make your CDR since it is sent directly to a SIP device (phone, ATA, etc) 3) You're likely capturing on the PBX/SBC side, which it never hits so your packet capture is a moot point 4) Don't want to name possibly affected vendors. 5) Your SIP devices (Phones, ATAs, etc) should not be exposed to the world. If someone is hitting a device that is behind say NAT/FW/etc. (non-public IP addr) then you may have bigger problems.
-- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM
"Where ignorance is our master, there is no possibility of real peace" - Dalai Lama
42B0 5A53 6505 6638 44BB 3943 2BF7 D83F 210A 95AF http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2BF7D83F210A95AF _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
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" <joquendo at e-fensive.net> 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.
mark at ecg.co +1-229-316-0013 http://ecg.co/lindsey
I have seen this before yes. Very low risk on Polycoms to my knowledge what they are attempting to do is see if this is an open or exploitable SIP proxy to commit toll fraud. Disable SIP ALG on the router and reboot the Polycoms if possible they are most likely getting port scanned and someone is seeing a device answering on 5060. If the SIP ALG cannot be disabled consider replacing the router with something that supports this functionality. Here is something that?s super useful in checking to see if something is there and answering to SIP requests. http://blog.sipvicious.org/ David Thompson Network Services Support Technician (O) 858.357.8794 (F) 858-225-1882 (E) dthompson at esi-estech.com (W) www.esi-estech.com *From:* VoiceOps [mailto:voiceops-bounces at voiceops.org] *On Behalf Of *PE *Sent:* Friday, September 27, 2013 10:46 AM *To:* voiceops at voiceops.org *Subject:* [VoiceOps] Phone hack 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
Also make sure the phones dont have the default 456 password.? In some versions the sip credentials are not hashed out and in other versions even if it is hashed if you inspect the element you can see the pw. ________________________________ From: David Thompson <dthompson at esi-estech.com> To: PE <peeip989 at gmail.com>; voiceops at voiceops.org Sent: Friday, September 27, 2013 2:13 PM Subject: Re: [VoiceOps] Phone hack I have seen this before yes. Very low risk on Polycoms to my knowledge what they are attempting to do is see if this is an open or exploitable SIP proxy to commit toll fraud. Disable SIP ALG on the router and reboot the Polycoms if possible they are most likely getting port scanned and someone is seeing a device answering on 5060. If the SIP ALG cannot be disabled consider replacing the router with something that supports this functionality. Here is something that?s super useful in checking to see if something is there and answering to SIP requests. ? http://blog.sipvicious.org/ ? David Thompson Network Services Support Technician (O) 858.357.8794 (F) 858-225-1882 (E) dthompson at esi-estech.com (W)?www.esi-estech.com ? From:VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of PE Sent: Friday, September 27, 2013 10:46 AM To: voiceops at voiceops.org Subject: [VoiceOps] Phone hack ? 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
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
If you can add a Firewall/NAT device, You can deploy a SIP ALG/router like Adtran or Edgemarc in the users Home network and set it to only accept SIP traffic from known IPs (your Sip Servers the Polycom registers with) *From:* VoiceOps [mailto:voiceops-bounces at voiceops.org] *On Behalf Of *Sandro Gauci *Sent:* Saturday, September 28, 2013 3:01 AM *To:* voiceops at voiceops.org *Subject:* Re: [VoiceOps] Phone hack 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
participants (8)
-
avorlando＠yahoo.com -
briansupport＠hotmail.com -
dthompson＠esi-estech.com -
joquendo＠e-fensive.net -
lindsey＠e-c-group.com -
peeip989＠gmail.com -
sandro＠enablesecurity.com -
ujjval＠simplesignal.com