The Digium / Asterisk Security Team has obviously been extremely busy ensuring that Asterisk is as secure as possible given that yesterday they released 7 security advisories, although only one of them (AST2014-16) was rated as “Critical”. The others are rated as “Moderate” or “Minor” – but still are good reasons to upgrade to the latest versions of Asterisk. The list of advisories is:
The issues are all fixed in the latest versions of Asterisk:
- Asterisk Open Source 22.214.171.124, 11.14.1, 12.7.1, 13.0.1
- Certified Asterisk 1.8.28-cert3, 11.6-cert8
Kudos to the Digium/Asterisk Security Team for the work they do in keeping Asterisk secure – and also for their openness in reporting the issues publicly!
Olle Johansson is back with another set of excellent slides about VoIP security and the need to have “MoreCrypto” everywhere. It’s a great set of slides that talks about where we have come from and where we need to go. Definitely check it out on SlideShare at: Reboot the Open Realtime Revolution – #MoreCrypto (Fall 2014) or in the embedded version below:
There’s a good discussion going on right now (September 2014) in the VoiceOps mailing list about how you can mitigate SIP threats by configuring the policies and settings on your session border controller (SBC). It started out with a detailed question from Robert Nystrom asking about how to configure an Acme Packet SBC in the most secure manner and asking about how best to configure access control lists (ACLs). Several answers can be seen in the VoiceOps archive from folks such as Ryan Delgrosso, Mark Lindsey, Jim Gast and Patrick McNeil, offering commentary and suggestions about how best to proceed.
If you are not already subscribed, the VoiceOps mailing list is a great resource. As stated on the subscription page:
This list is for discussions related to managing voice networks, both traditional and IP.
The VOIP Operators’ Group (VOG) charter is to facilitate the creation, maintenance, and operations of Voice over Internet Protocol (VOIP) related networks, products, and services.
Similar to the North American Network Operators’ Group (NANOG), The Voice Operators’ Group seeks to assist in the creation of a robust, stable and growing VOIP ecosystem.
While the topics are definitely not all about security, I would encourage you to join the list if you do anything with the operation of VoIP networks – or if you are just curious to learn more about such networks.
Happy New Year! Welcome to 2014! We’re looking forward to more activity happening here at VOIPSA this year… stay tuned for more information! In the meantime, we hope that you all have a very secure 2014 without any major security issues with your VoIP and other communication systems!
We are unfortunately aware that the mail archives for the VOIPSEC mailing list have not been functioning for a long time. The list still does have occasional active conversations on it and anyone is welcome to subscribe. However, the archive on the list page as well as on the VOIPSA site page for the list has been broken for a while now. As part of our work updating the VOIPSA website I’ve been in touch with our hosting vendor to see about getting the archives back in action. Stay tuned….
The great folks at the Digium / Asterisk Security Team have issued two new security advisories that folks running Asterisk should pay attention to. They are:
AST-2013-006: Buffer Overflow When Receiving Odd Length 16 bit SMS Message – If you have Asterisk set up to receive SMS messages, it seems that a 16-bit SMS message of a certain size can cause the Asterisk server to have a buffer overflow and the system to crash. The fix is to upgrade to the latest version of Asterisk. It sounds like the only attack method is via SMS and so if you are not connecting SMS to Asterisk it would seem this advisory would not apply to you.
AST-2013-007: Asterisk Manager User Dialplan Permission Escalation – The Asterisk Manager Interface (AMI) allows you to control the operation of your Asterisk server through external applications or other systems. The Security Team notes that the AMI interface does allow for the execution of dialplan functions that can go beyond simply controlling Asterisk but can in fact issue shell commands to the underlying operating system. The new versions of Asterisk now include a new option in asterisk.conf called, amusingly, “live_dangerously”, that can be set to “no” to forbid the execution of these extra functions. They note that for backwards compatibility the default for this option is “yes” because there may be applications in use that rely on these shell functions. It would seem prudent, though, to see if you can set this to “no” to provide the highest level of system security.
I am not currently running any Asterisk systems myself but it would seem to me that a basic “security 101″ level you should also be making sure that access to that AMI port on your Asterisk server is restricted to only the systems running any applications that need that access.
In any event, if you are an Asterisk user and haven’t upgraded to the latest version, these security alerts may be a good reason to do so!
Are there large-scale attacks happening against VoIP and videoconferencing systems today? Or is it limited to one particular system? In a posting this morning to the VoiceOps mailing list, J. Oquendo wrote:
We have seen a larger than normal, if not, one of the largest attacks against some of our VoIP and video conferencing systems today. Initially, we fielded a report of a “system gone bad” followed by another, then another, and another. This has now carried on into some of our videoconference units (LifeSize).
Because our goal is to get telephony up and running, there was not much we could do via incident response, so I have little to add on attack vectors however, I will state that PBXNSIP has been the primary target, with about a dozen of these being hit pretty hard to the point I’ve had to block all, stop the software and re-start it.
Given that J. Oquendo has been around VoIP security circles for quite a few years now and worked on a number of different projects, I’m inclined to believe his account. Are any of you seeing increased attacks? If so, I think he’d certainly like to hear from you. If you’re not a member of the VoiceOps list, you might also want to join that list as it’s become quite a good resource for people involved in the operations of VoIP systems.
If you are an author here at Voice of VOIPSA and are wondering why you just received an email about a password change, I went through and reset all the passwords on our user accounts. There was no security issue – I just realized that some of the accounts have not been used for a long time and I had no idea about the strength of the passwords. If you want to login you’ll need to use the “Forgot my password” reset link to generate a link to a new password (or contact me and I can reset it). My apologies for any inconvenience.
P.S. In doing this, I found a really nice random password generator at: http://sandbox.coderlab.net/rpg/index.php
The great folks on Digium’s security team published two security advisories this week that could lead to remote crashes of an Asterisk server.
The first, AST-2013-004, Remote Crash From Late Arriving SIP ACK With SDP, has this description:
A remotely exploitable crash vulnerability exists in the SIP channel driver if an ACK with SDP is received after the channel has been terminated. The handling code incorrectly assumes that the channel will always be present.
The second, AST-2013-005, Remote Crash when Invalid SDP is sent in SIP Request, has this description:
A remotely exploitable crash vulnerability exists in the SIP channel driver if an invalid SDP is sent in a SIP request that defines media descriptions before connection information. The handling code incorrectly attempts to reference the socket address information even though that information has not yet been set.
My one critique of the security advisories is that they don’t contain any “mitigating circumstances” that explain the circumstances under which the vulnerabilities could be exploited. For instance, it would seem from reading the documents that at least in the first case there would need to be a successful SIP connection established first – and then ended – before the packet could be received that would cause the crash. Unfortunately I don’t personally know Asterisk’s internals well enough to comment on that.
Regardless, the fix here is to upgrade to the latest versions of Asterisk as documented in the security advisories.
Kudos to the Digium folks for issuing these advisories and continuing their clear process of letting people know about security within Asterisk.
This week the SIP Network Operators Conference (SIPNOC) takes place in Herndon, Virginia, and the SIPNOC agenda turns out to have a great focus on security as it relates to VoIP and IP-based communications in general. The security-related sessions include:
- The Growth of Robocalling SPIT
- Communications Service Providers and Threat Intelligence Sharing
- Panel Discussion: Anatomy of a VoIP DMZ
- VoIP Theft: Werewolf or Hydra
- Who are You Really Calling? How DNSSEC Can Help
There will also be a “VoIP Security Birds-of-a-feather (BOF)” session tomorrow evening where we’ll be sharing information about VoIP security issues and learning from each other about what issues people are seeing.
Sponsored by the SIP Forum, SIPNOC is an educational event that brings together primarily technical and operations staff from a wide range of telecommunications and VoIP service providers. It is not a trade show, i.e. there is no exhibit hall. It is just focused on providing educational sessions and networking opportunities.
I’ll be there at SIPNOC speaking about DNSSEC, IPv6 and moderating the VoIP security BOF and the VoIP DMZ panel . I look forward to meeting up again with many of the folks who have attended SIPNOC in the past years. The event is not livestreamed, but if you are in the DC area and want to attend, registration is still open.
If you are there at SIPNOC 2013, please do say hello!