Category: VoIP Security

Dec 19

SS7 Security On Techmeme? A Reminder About Interconnected Systems…

techmeme-ss7SS7 security issues reported on Techmeme?  I did a double-take yesterday and, as Jay Cuthrell noted on Twitter, wondered if this was a “ThrowbackThursday” taken to the extreme.  But no, there was indeed a report in the Washington Post about German security researchers discovering that aspects of SS7 signaling that could be used to listen to phone conversations and/or read text messages on mobile networks.  As the article notes:

The flaws discovered by the German researchers are actually functions built into SS7 for other purposes – such as keeping calls connected as users speed down highways, switching from cell tower to cell tower – that hackers can repurpose for surveillance because of the lax security on the network.

The researchers noted that one of the attackers could get around existing encryption mechanisms used on mobile networks:

For calls or texts transmitted using strong encryption, such as is commonly used for advanced 3G connections, hackers could request through SS7 that each caller’s carrier release a temporary encryption key to unlock the communication after it has been recorded.

SS7, or Signalling System 7, is of course the dominant set of telephony signaling protocols used in the legacy Public Switched Telephone Network (PSTN) made up of today’s wired and wireless (mobile) telephone networks.  As such, we don’t write about SS7 hardly at all here on the VOIPSA blog as it is not related to VoIP.

However, there were three important thoughts to me coming out of this article:

1. VoIP can be more secure than the PSTN. The report mentions the encryption of the underlying 3G transport infrastructure being subverted.  However, with VoIP apps that are “Over-The-Top” (OTT) riding on the mobile data network, the encryption can happen from within the app on one mobile device all the way to the app on the other mobile device – or at least back to a central set of servers.  Now, there can be other security vulnerabilities with such a system, but the transport layer could at least be secured.

2. Telecommunication systems are only as secure as their weakest link – and are interconnected.  The bigger concern is of course that most of our telecom systems are all interconnected… and you can have the most secure VoIP system in the world, but if you wind up connecting to the PSTN – and specifically in this case to mobile PSTN networks – then you are open to exactly these kind of attacks.  Obviously if you are communicating only within an OTT “walled garden” where you only talk to others using the same OTT app you can be secure, but the moment you go out to the PSTN you are open to all the issues there.

3. Fixed lines are no safer if you talk to mobile users. The article ends with a German senator saying “When I really need a confidential conversation, I use a fixed-line phone“.  I don’t know about that.  For one thing, if the person you are calling is a mobile phone user, you are again open to these kind of attacks.  Secondly the Snowden revelations of the past year have certainly shown us that large agencies have the ability to listen in to communications on the networks of the PSTN.  If I absolutely want a confidential conversation, I’m personally going to use one of the VoIP applications that has end-to-end encryption. I’m NOT going to trust a fixed line any more than I would trust a mobile phone.

And I guess the final thought is of course that the legacy PSTN is full of security issues – they just aren’t necessarily as open to all to see because of the more closed nature of the traditional telephone networks.

A good reminder, though, that telephony security has always been a problem – and we need to ensure that both our VoIP and traditional networks have adequate security.

Meanwhile, it was rather fun to see SS7 mentioned on Techmeme… not something you’d expect to see!

Dec 13

Verizon Launches Voice Cypher Secure VoIP Mobile App… With A Government Backdoor

Verizon Wireless this week did something that initially seemed quite impressive – they launched “Voice Cypher”, an app available for iOS, Android and Blackberry that promises secure end-to-end encryption. It uses VoIP and is an “over-the-top” (OTT) app that works on any carrier.  If you read the marketing material on their web site, it all sounds great!  Indeed their “Learn More” page has all the right buzzwords and security lingo – and says quite clearly: Voice Cypher provides end-to-end encryption between callers, even if the call crosses over multiple networks.” They include the requisite network diagram that shows how it protects against all threats:

Verizon Wireless Voice Cypher

It turns out there’s just one small little detail … as reported by BloombergBusinessweek, the app comes complete with a backdoor so that Verizon could decrypt the phone calls if requested to do so by law enforcement!

As the Businessweek article states:

Cellcrypt and Verizon both say that law enforcement agencies will be able to access communications that take place over Voice Cypher, so long as they’re able to prove that there’s a legitimate law enforcement reason for doing so.

Unfortunately, in this post-Snowden era I don’t know that many of us put a great amount of trust in our governments to only access communications with a “legitimate law enforcement reason”.  Or perhaps the concern is that what gets classified as “legitimate” can be widely construed to mean almost anything.

The article does point out that Verizon is bound by CALEA to provide lawful intercept  to the phone networks, but points out an interesting caveat that Verizon could have used:

Phone carriers like Verizon are required by U.S. law to build networks that can be wiretapped. But the legislation known as the Communications Assistance for Law Enforcement Act requires phone carriers to decrypt communications for the government only if they have designed their technology to make it possible to do so. If Verizon and Cellcrypt had structured their encryption so that neither company had the information necessary to decrypt the calls, they would not have been breaking the law.

A Verizon Wireless representative indicated that they believe government agencies looking for ways to protect sensitive information may be  customers of this service, as may be corporate customers concerned about leaking private information.

But… as we continue to hear more and more information about the massive amount of pervasive monitoring and surveillance by government agencies from many different governments around the world, you do have to wonder how safe those agencies and companies will feel with a “secure” solution that already comes with a backdoor.  The problem with a known backdoor is that even if you may trust Verizon Wireless to only allow legitimate law enforcement access… how do you know that some attacker may not be able to penetrate that backdoor?   The “secure end-to-end encryption” isn’t entirely secure.

Given that the service has a higher price tag of $45 per month per device, I do wonder how many businesses or agencies will actually embrace the service.

On reading about this Voice Cypher service, it certainly sounds quite interesting.  We need more secure voice solutions out there – and it’s very cool that Verizon Wireless is delivering this as an OTT mobile app that will work across different carriers.

It’s just too bad that it’s not truly “secure end-to-end”.  :-(

P.S. I also recorded an audio commentary on this same topic.

Nov 21

7 Asterisk VoIP Security Advisories Issued

Asterisk logoThe 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 1.8.32.1, 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!

Oct 31

Slides: Reboot the Open Realtime Revolution – #MoreCrypto (Fall 2014)

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:

Jan 07

Wishing You A Very Secure 2014!

2014Happy 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!

Dec 17

Two New Asterisk Security Vulnerabilities Related To SMS And AMI

Asterisk logoThe 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!

Nov 25

Large-scale Attacks Against VoIP and Videoconferencing Happening Today?

Voice Ops mailing listAre 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.

Aug 30

2 Asterisk Security Vulnerabilities Could Lead To Remote Crashes

Asterisk logoThe 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.

Jul 29

Can We Create A "Secure Caller ID" For VoIP? (Join Tomorrow’s STIR BOF To Learn More)

Can we create a "secure Caller ID" for IP-based communications, a.k.a. voice-over-IP (VoIP)? And specifically for VoIP based on the Session Initiation Protocol (SIP)? Can we create a way to securely identify the origin of a call that can be used to combat robocalling, phishing and telephony denial-of-service (TDOS) attacks?

That is the challenge to be undertaken by the "Secure Telephone Identity Revisited (STIR)" group meeting tomorrow morning, July 30, 2013, at 9:00 am in Berlin, Germany, as part of the 87th meeting of the Internet Engineering Task Force (IETF). The meeting tomorrow is a "Birds Of a Feather (BOF)", which in IETF language is a meeting to determine whether there is sufficient interest to create a formal "working group" to take on a new body of work within the IETF. The proposed "charter" for this new work begins:

Over the last decade, a growing set of problems have resulted from the lack of security mechanisms for attesting the origins of real-time communications. As with email, the claimed source identity of a SIP request is not verified, and this permits unauthorized use of source identities as part of deceptive and coercive activities, such as robocalling (bulk unsolicited commercial communications), vishing (voicemail hacking, and impersonating banks) and swatting (impersonating callers to emergency services to stimulate unwarranted large scale law enforcement deployments). This working group will define a deployable mechanism that verifies the authorization of the calling party to use a particular telephone number.

The agenda for tomorrow's STIR meeting begins with a presentation by Henning Schulzrinne, now CTO of the US Federal Communications Commission (FCC) but also a long-time IETF participant and one of the co-authors of the original RFC 3261 specification for SIP. Henning will be laying out the problem statement and there will be a discussion of the proposed scope of the IETF work. He'll be followed by presentations of potential solutions by Jon Peterson, Eric Rescorla and Hadriel Kaplan and then a discussion of the proposed charter and the work to be done. Given the intense debate that has occurred on the STIR mailing list over the past weeks I expect tomorrow's session to be one where some points will receive a great amount of passionate debate and discussion. (If you are interested in listening in or participating remotely in tomorrow's STIR meeting, see the information later in this article.)

Revisiting Previous SIP Identity Work

As some background, the Internet Architecture Board (IAB) laid out some of the challenges to "secure origin identification" in IP-based communication last November and took a very high-level look at the overall issue. Next, in preparation for what became this STIR effort, Jon Peterson, Henning Schulzrinne and Hannes Tschofenig authored a draft problem statement and requirements document.

The "Revisited" part of the group name is a nod to the fact that this whole issue of asserting "identity" has been explored within the SIP community in the past. Way back in 2006, RFC 4474 defined what has been called "SIP Identity" and provided a method for cryptographically signing certain SIP headers to identify the origin of a call. Unfortunately, RFC 4474 turned out not to work well with the way SIP was actually deployed and so usage has been virtually non-existent. An effort to update that document, what is called "RFC4474bis", has also been proposed and some of those ideas may be incorporated into the new proposed work for the STIR group.

There have also been other efforts such as the "P-Asserted-Identity (P-A-I)" defined in RFC 3325. The challenge here, though is that theoretically P-A-I is supposed to be limited to usage within a trusted network, although in practice it may be seen by other networks. There have also been several efforts to define or document identifiers for billing purposes (including my own P-Charge-Info) although these efforts are trying to solve a slightly different problem.

The point here really is that the STIR effort is drawing upon a rich body of "SIP identity" work that dates all the way back to some early drafts in 2002. Much thought has been given to this issue and many of the people involved with STIR have also been involved with earlier efforts and understand well some of the challenges faced by that past work.

An Important Difference

One important difference between STIR and earlier "SIP identity" efforts is that initially the STIR effort is only focused on telephone numbers. The draft charter explicitly states this:

As its first work item, the working group will specify a SIP header-based authorization mechanism to verify the originator of a SIP session is authorized to use the claimed source telephone number, where the session is established with SIP end to end. This is called an in-band mechanism. The mechanism will use a canonical telephone number representation specified by the working group, including any mappings that might be needed between the SIP header fields and the canonical telephone number representation.

and later:

Expansion of the authorization mechanism to identities using the user@domain form deferred since the main focus of the working group is to develop a solution for telephone numbers.

Previous "identity" work was also undertaken to include a "SIP URI" or "SIP address" and while the ultimate STIR mechanism (or a variant thereof) might also work for SIP URIs, the focus in this initial work is all around securing the origin identification of telephone numbers.

This initial focus makes a great amount of sense given that so much of the SIP traffic today is a result of telecom service providers moving their regular calls to telephone numbers off of the legacy PSTN networks and over to IP networks where they use SIP. Additionally, a great amount of the "problem" traffic seen in VoIP today can be created by attackers who use simple VoIP software to generate their calls to regular telephone numbers.

Remotely Participating In Tomorrow's STIR BOF

If you are interested in participating in the meeting (or at least listening in) on Tuesday, July 30, the meeting will go from 9:00 - 11:30 local time in Berlin, Germany. Berlin is in Central European Summer Time (CEST) which is UTC+2 (and 3:00 am US EDT / midnight US PDT for my friends back in the USA).

You can hear the audio stream at:

You can also join the Jabber chat room at:

The slides and other meeting materials can be found at (and note that materials may not be uploaded until shortly before the session and so you may need to refresh your browser):

Alternatively you can use the "MeetEcho" conferencing system that integrates the audio, the slides and the Jabber chat room at:

More information about participately remotely can be found on the IETF 87 Remote Participation page.

To get the most out of the meeting, you'll also want to read these three Internet Drafts that will be part of the solutions being discussed:

.... and be prepared for what should be a LIVELY discussion!

If you are unable to participate remotely, the session will be recorded and you will be able to listen to the archived audio stream, view the Jabber chat logs and also playback the MeetEcho recording.

Getting More Involved

Beyond listening to tomorrow's BOF session, the best way to get involved - either to actively participate or to at least monitor the effort - is to join the STIR mailing list at:

https://www.ietf.org/mailman/listinfo/stir

The list is open to anyone to join. There are no membership or corporate requirements or fees - anyone with an email address may participate.

WARNING! - As can be seen in the list archive, there is currently a large volume of discussion and it will probably continue for some time. If you do join the mailing list you may want to consider setting up rules to sort the STIR email into a folder - or just prepare for the volume to be added to your inbox.

The other way to be involved is to monitor and read the documents that are created for the STIR effort. Newer documents are being created with "stir" in the document name and so they can be easily found at:

http://datatracker.ietf.org/doc/search/?name=stir&activedrafts=on

Other documents that are useful to understand this effort are linked to earlier in this article and can also be found in the text of the proposed STIR charter. After tomorrow's STIR BOF session there will be more information about how the effort will proceed within the IETF. The meeting tomorrow should result, I expect, in the recommendation to go ahead with formally creating a working group and undertaking this work, but we'll see what outcome occurs.

Can a method of secure origin identification for SIP-based VoIP calls be created? Given that basically all telecom traffic is in the process of moving to be based on IP, the need for a secure origin identifier is very clearly here - and many of us do believe we can develop a system that will work in today's environment.

What do you think? Are you ready to join in and help?

Update: Added the additional charter text about "Expansion of the authorization mechanism to identities..."

If you found this post interesting or useful, please consider either:

Apr 22

At SIPNOC 2013 This Week Talking About VoIP And IPv6, DNSSEC … and Security, Of Course

Sipnoc 2013 logoOne of the conferences I've found most interesting each year is the SIP Network Operators Conference (SIPNOC) produced by the SIP Forum, a nonprofit industry association. Part of my interest is that it is only an educational conference, i.e. there's no massive exhibit floor or anything... it's all about education. It also brings together pretty much all the major players in the "IP communications" space - certainly within North America but also from around the world.

I'll be there this week in Herndon, Virginia, talking about how VoIP can work over IPv6 and how DNSSEC can make VoIP more secure. The sessions I am directly involved with include:

  • Panel Discussion: Anatomy of a VoIP DMZ
  • VoIP Security BOF
  • Panel Discussion:  IPv6 and SIP - Myth or Reality?
  • Who Are You Really Calling? How DNSSEC Can Help

There are quite a range of other topics on the SIPNOC 2013 agenda, including a number of other talks related to security.  

It should be quite a good show and I'm very much looking forward to it.  I'm particularly looking forward to my "DNSSEC and VoIP" talk on Thursday as that is a topic I've not presented on before... but I think there is some quite valuable potential about using DNSSEC with VoIP.

If you are there at SIPNOC this week, please do say hello!

P.S. While SIPNOC is not being livestreamed, you may find some people tweeting using the hashtag #SIPNOC.

If you found this post interesting or useful, please consider either: