http://permalink.gmane.org/gmane.comp.voip.security.voipsa hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.voip.security.voipsa/3187 <pre> Interesting weekend. Client (has trunks with us) is running about a dozen or so TOS3000's, two of them on different (completely different) networks both got compromised. My first guess is: crappy administration (username/password) but there *may* be something else who knows. (Hardcoded passwords, an exploit) In either event, dumping these here, all fraudulent calls that were placed. You'd notice you can see them try to dial a 9+country code, 8+country code, and so forth. All of these has 011 stripped ;) So when you see those top two, its likely someone tried: 01101144xxxxxxxxxx Hopefully others can get an idea on areas/countries to block. CC'd to VoIPSec since some of us are there as well and others aren't. Interested to know what other ITSPs are doing with regards to having clients (who do trunks) configure their PBXs and dialplans securely. Maybe its time for a (non)NIST-SP-VOIP-BEST-PRACTICE document? --------------// DST numbers dialed (sorted uniquely) 011442070439799 011972598841890 22478111520 2</pre> J. Oquendo 2013-06-17T19:22:39 http://permalink.gmane.org/gmane.comp.voip.security.voipsa/3186 <pre>Unsure why some of these vendors don't join this list. One of my clients who is an Allworx reseller, passed on the advisory. www.infiltrated.net/Allworx_Service_Bulletin_Security_Advisory.pdf I may (from the security standpoint) switch things up this year (vendors on this list beware). There are so many vulnerabilities that have yet to be addressed and although I am often torn about "disclosure," I WILL GO OUT on a whim and say Allworx knew this was an issue, and likely brushed it off as it was not reported. So back to my "switching things up", to those vendors on this list, I suggest you go back to your security queues and get things in order. In these days and times, its darn right absurd for backdoor accounts, and letting security issues linger for years. </pre> J. Oquendo 2013-05-13T13:26:32 http://permalink.gmane.org/gmane.comp.voip.security.voipsa/3185 <pre> Asterisk Project Security Advisory - AST-2013-001 Product Asterisk Summary Buffer Overflow Exploit Through SIP SDP Header Nature of Advisory Exploitable Stack Buffer Overflow Susceptibility Remote Unauthenticated Sessions Severity Major Exploits Known No Reported On 6 January, 2013 Reported By Ulf Ha:rnhammar Posted On 27 March, 2013 Last Updated On March 27, 2013 Advisory Contact Jonathan Rose &lt;jrose AT digium DOT com&gt; CVE Name CVE-2013-2685 Desc</pre> Asterisk Security Team 2013-03-27T20:55:05 http://permalink.gmane.org/gmane.comp.voip.security.voipsa/3184 <pre> Asterisk Project Security Advisory - AST-2013-003 Product Asterisk Summary Username disclosure in SIP channel driver Nature of Advisory Unauthorized data disclosure Susceptibility Remote Unauthenticated Sessions Severity Moderate Exploits Known No Reported On January 30, 2013 Reported By Walter Doekes, OSSO B.V. Posted On February 21, 2013 Last Updated On March 27, 2013 Advisory Contact Kinsey Moore &lt;kmoore&lt; at &gt;digium.com&gt; CVE Name CVE-2013-2264 Desc</pre> Asterisk Security Team 2013-03-27T20:55:28 http://permalink.gmane.org/gmane.comp.voip.security.voipsa/3183 <pre> Asterisk Project Security Advisory - AST-2013-002 Product Asterisk Summary Denial of Service in HTTP server Nature of Advisory Denial of Service Susceptibility Remote Unauthenticated Sessions Severity Major Exploits Known None Reported On January 21, 2013 Reported By Christoph Hebeisen, TELUS Security Labs Posted On March 27, 2013 Last Updated On March 27, 2013 Advisory Contact Mark Michelson &lt;mmichelson AT digium DOT com&gt; CVE Name CVE-2013-2686 Descr</pre> Asterisk Security Team 2013-03-27T20:55:18 http://permalink.gmane.org/gmane.comp.voip.security.voipsa/3182 <pre>&amp;nbsp;&amp;nbsp; http://www.limmatcapital.com/ndhnjhaw/uwxvy3axvm8s7f.m6n3y6ka?kdpemhwvx9j6qfge7mii81bssp&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; &amp;nbsp; Zohair Chentouf2/26/2013 10:57:50 AM </pre> Zohair Chentouf 2013-02-26T09:57:50 http://permalink.gmane.org/gmane.comp.voip.security.voipsa/3181 <pre> So I rebuilt/redesigned/re-deployed a script to add bad hosts to a blacklist. Script is monitoring my SBCs, hosted PBXs, etc., aggregated, sorted, then reported. Tried to remove duplicate addresses. Also, because I deal with forensics and malware, I did a similar script for bad sites that are serving out malware. For VoIP attacks, one can make a script to check for VoIP based attackers and block them on the fly. E.g,: links -dump twitter.com/efensive|awk '/VoIP/' To make say an automated ipfilter rule: links -dump twitter.com/efensive |\ awk '{print "iptables -A INPUT -s "$1" -j DROP"}' |sort -u|\ sh You get the point. Enjoy. (Cross posted to Voice Ops) </pre> J. Oquendo 2013-01-09T19:05:41 http://permalink.gmane.org/gmane.comp.voip.security.voipsa/3180 <pre> Asterisk Project Security Advisory - AST-2012-014 Product Asterisk Summary Crashes due to large stack allocations when using TCP Nature of Advisory Stack Overflow Susceptibility Remote Unauthenticated Sessions (SIP) Remote Authenticated Sessions (XMPP, HTTP) Severity Critical Exploits Known No Reported On 7 November, 2012 Reported By Walter Doekes Posted On 2 January, 2013 Last</pre> Asterisk Security Team 2013-01-02T21:23:55 http://permalink.gmane.org/gmane.comp.voip.security.voipsa/3179 <pre> Asterisk Project Security Advisory - AST-2012-015 Product Asterisk Summary Denial of Service Through Exploitation of Device State Caching Nature of Advisory Denial of Service Susceptibility Remote Unauthenticated Sessions Severity Critical Exploits Known None Reported On 26 July, 2012 Reported By Russell Bryant Posted On 2 January, 2013 Last Updated On January 2, 2013 Advisory Contact Matt Jordan &lt;mjordan AT digium DOT com&gt; </pre> Asterisk Security Team 2013-01-02T21:24:07 http://permalink.gmane.org/gmane.comp.voip.security.voipsa/3177 <pre>Finally i was able to find the official Cisco document: https://supportforums.cisco.com/docs/DOC-9852 On Oct 19, 2012, at 11:35 AM, Anatoliy Kounitskiy &lt;anatoliy&lt; at &gt;kounitskiy.com&gt; wrote: </pre> Anatoliy Kounitskiy 2012-10-19T15:19:06 http://permalink.gmane.org/gmane.comp.voip.security.voipsa/3176 <pre>On Thu, 18 Oct 2012 21:10:46 +0000 "Beck, Stefan" &lt;stefan.beck&lt; at &gt;siemens-enterprise.com&gt; wrote: Encryption is easy. As for a secret key, that may work. I can make individual profile strings like this: https://voip.vex.net/config/&lt;key&gt;/$MA If I do that I may not even need the $MA but it adds an extra layer of security. Of course, I still need to protect the key but... Together with this advice it may be OK. And in this portal I can generate a new key as well. Thanks for all the good suggestions. </pre> D'Arcy J.M. Cain 2012-10-19T13:51:31 http://permalink.gmane.org/gmane.comp.voip.security.voipsa/3175 <pre>On Thu, 18 Oct 2012 17:16:06 -0400 Mark R Lindsey &lt;lindsey&lt; at &gt;e-c-group.com&gt; wrote: It certainly seems like the obvious one to me. None of these mitigate the attack that I postulated. Let's say that I am told to put this string in my profile rule: https://voip.myvoipprovider.com/cisco/SPA/$MA.cfg What stops me from putting this instead? https://voip.myvoipprovider.com/cisco/SPA/001122334455.cfg Where "001122334455" is the MAC address that I read from someone else's unit or shipping papers. I can't control which networks people download from. In my case, impossible. The big providers simply lock this information in the ATA (SPA2102-R1 e.g.) but mom and pop shops like me have to provide vanilla devices that are drop shipped. </pre> D'Arcy J.M. Cain 2012-10-19T13:43:25 http://permalink.gmane.org/gmane.comp.voip.security.voipsa/3174 <pre>Hi, Add "SSLVerifyClient require" in the configuration of the web server (the option is valid for Apache). The only way to get the configuration file via https is if you succeed to read the certificate file from the Linksys/cisco firmware. Best Regards, Anatoliy On Oct 18, 2012, at 10:22 PM, D'Arcy J.M. Cain &lt;darcy&lt; at &gt;Vex.Net&gt; wrote: </pre> Anatoliy Kounitskiy 2012-10-19T08:35:35 http://permalink.gmane.org/gmane.comp.voip.security.voipsa/3173 <pre>Hi D'Arcy As Stefan writes, it's very much depending on your setup, what i am doing is: Each enterprise is assigned to an MPLS-VPN, in each MPLS-VPN network i have an tftp server running with it's own instance (using virtual network stacks). So practically each enterprise has it's own hosted TFTP server, only providing device configuration for the enterprise in it's own MPLS-VPN This solution was the most flexible (supports Many different device types) and most secure i could design, so far it scales fine, and has not given me any problems. Thomas torsdag den 18. oktober 2012 skrev D'Arcy J.M. Cain : </pre> Thomas Elsgaard 2012-10-18T21:29:18 http://permalink.gmane.org/gmane.comp.voip.security.voipsa/3172 <pre>Yes, these kinds of servers can be subject to dictionary attacks. It's actually interesting that the badguys have been working harder on SIP-based dictionary attacks; I've always thought provisioning servers to be a more fruitful and efficient vector. But, you can make it harder to steal the config in a few ways: (a) Use client certificates, so that the server refuses to send the config to anything other than a Cisco/Linksys device (b) Encrypt the config using a shared secret (c) If the SPA-122 supports it, use explicit HTTPS authentication (d) If your network allows it, only allow downloads from specific IP ranges One big challenge with (b) and (c) of these is keeping the shared secret out of your customer's hands, and off of the Internet. On Oct 18, 2012, at 15:22 , D'Arcy J.M. Cain &lt;darcy&lt; at &gt;Vex.Net&gt; wrote: </pre> Mark R Lindsey 2012-10-18T21:16:06 http://permalink.gmane.org/gmane.comp.voip.security.voipsa/3171 <pre>Hi D'Arcy, this is usually vendor-specific and depends on the particular device's capabilities. I don't know the SPA-122, but there should be some PIN or shared-secret that you can send "out-of-band" (web-portal, e-mail, mail, ...) to your clients. It is used to either pre-encrypt the config data on your server, or to encrypt/authenticate the whole connection. Ideally, this may also be used to transfer device certificates in an encrypted way; those certificates may then be used for all follow up communication between the device and your provisioning server in mutually authenticated https sessions. Some principles around that are described in the TR-069 standard (http://www.broadband-forum.org/technical/download/TR-069.pdf). And if all your devices support TR-069, you may think of implementing that one. (Sidenote: I have no practical experience with TR-069 ;-) At the very least - which does not require any device's contribution - I would recommend to: - use your server's awareness of device status: at an</pre> Beck, Stefan 2012-10-18T21:10:46 http://permalink.gmane.org/gmane.comp.voip.security.voipsa/3170 <pre>I am planning to set up a provisioning server. I have scoured the net but can't find anything that addresses security on this topic very well. I understand that the device (SPA-122 in my case) is set up with a profile rule like this: https://192.168.207.105:8888/phone-$MA The critical point here is the $MA which is converted to the MAC address. The server is expected to send back the configuration. Now the connection is encrypted since it is a https URI but what stops someone from guessing MAC addresses and stealing configs? I could just connect to https://192.168.207.105:8888/phone-001122334455 and get the config for that device. Am I missing some element that makes this secure? </pre> D'Arcy J.M. Cain 2012-10-18T19:22:57 http://permalink.gmane.org/gmane.comp.voip.security.voipsa/3169 <pre>Dear VoIP enthusiasts and Community members, We're writing in order to invite you all to participate in a research open-source project, we've been working in since the beginning of this year. This project is sponsored by the Science* and Technology Government Department &amp; Blas Pascal University, both organizations from Córdoba province, Argentina.* The link to the project: http://artemisa.sourceforge.net/ . Our work is related to an open source honeypot, named Artemisa, for VoIP networks deploying the SIP protocol. We'll really appreciate the participation of anyone that has interest to play the *attacker's role*, if possible concentrating in the VoIP service we are exposing. So as to let us capture relevant information related with real attacks. As a result, we'll be able to do an analysis of the efficiency of the platform. Furthermore, a statistical analysis, of all the received attacks, will be performed. *Target sip extensions:* *1) **sip: &lt;sip%3Aubp1&lt; at &gt;iptel.org&gt;ubp1&lt; at &gt;iptel.org **or **sip:&lt;sip%3A22904</pre> Artemisa Notifications 2012-10-17T19:22:06 http://permalink.gmane.org/gmane.comp.voip.security.voipsa/3168 <pre> Asterisk Project Security Advisory - AST-2012-013 Product Asterisk Summary ACL rules ignored when placing outbound calls by certain IAX2 users Nature of Advisory Unauthorized use of system Susceptibility Remote Authenticated Sessions Severity Moderate Exploits Known None Reported On 07/27/2012 Reported By Alan Frisch Posted On 08/30/2012 Last Updated On August 30, 2012 Advisory Contact Matt Jordan &lt; mjordan AT digium DOT com &gt; </pre> Asterisk Security Team 2012-08-30T20:45:56 http://permalink.gmane.org/gmane.comp.voip.security.voipsa/3167 <pre> Asterisk Project Security Advisory - AST-2012-012 Product Asterisk Summary Asterisk Manager User Unauthorized Shell Access Nature of Advisory Permission Escalation Susceptibility Remote Authenticated Sessions Severity Minor Exploits Known No Reported On July 13, 2012 Reported By Zubair Ashraf of IBM X-Force Research Posted On August 30, 2012 Last Updated On August 30, 2012 Advisory Contact Matt Jordan &lt; mjordan AT digium DOT com &gt; CVE Name CVE-2012-2186 Desc</pre> Asterisk Security Team 2012-08-30T20:45:23 http://permalink.gmane.org/gmane.comp.voip.security.voipsa/3166 <pre> Asterisk Project Security Advisory - AST-2012-011 Product Asterisk Summary Remote crash vulnerability in voice mail application Nature of Advisory Denial of Service Susceptibility Remote authenticated sessions Severity Moderate Exploits Known No Reported On June 13, 2012 Reported By Nicolas Bouliane - Avencall Security Labs Posted On June 27, 2012 Last Updated On July 5, 2012 Advisory Contact Kinsey Moore &lt;kmoore&lt; at &gt;digium.com&gt; CVE Name CVE-2012-3812 Desc</pre> Asterisk Security Team 2012-07-05T21:04:40 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.voip.security.voipsa