Category Archives: VoIP Security

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!

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.

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!

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:

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!

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.

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.

U.S. DHS Warns of TDoS (Telephony Denial of Service) Attacks

DHS TDOS AlertThe U.S. Department of Homeland Security recently issued a bulletin titled “TDoS Attacks on Public Safety Communications” and while it was “Law Enforcement Use Sensitive/For Official Use Only” a copy was obtained by Brian Krebs who wrote about it on his site and also published the DHS bulletin publicly.

This resulted in a small flurry of related articles that Mark Collier listed on his VoIP security blog. Most of the articles, unfortunately somewhat predictably, seem to be rehashes of Brian Krebs’ post and/or the DHS bulletin.  However, the point is definitely solid – these are real attacks that are happening on call centers out there, including those operated by emergency services organizations.  No one wants to be on the receiving end of hundreds (or thousands) of phone calls clogging up your call center and making it unusable for regular business.

The connection to VoIP is that made by Brian Krebs in his article:

According to a recent report from SecureLogix, a company that sells security services to call centers, free IP-PBX software such as Asterisk, as well as computer-based call generation tools and easy-to-access SIP services, are greatly lowering the barrier-to-entry for voice network attackers.

This is the key point.  VoIP systems make these kind of attacks much easier to create.  Anyone can take one of the various free VoIP servers and create a script that will generate a crazy number of phone calls.  And of course the Caller-ID can be easily spoofed using the same servers.  I’m sure there are already scripts out there that automate all of this for would-be attackers.

The challenge is then finding either a VoIP service provider (or “ITSP” or “SIP Service Provider”) who will let the attacker send out phone calls to the PSTN – or to find victims that allow incoming SIP connections (which means that attacks could come from any Internet connection).  Or to find components of the SIP signaling infrastructure that have weak (or no) authentication and through which an attacker can send calls.  For example, SIP gateways that allow incoming SIP calls with minimal (or easily spoofable) authentication.

It’s not necessarily easy to do, but VoIP systems do make it easier than it was in the past, largely because the attackers can obtain a degree of anonymity through masking their source, and also because of the automation of the calling possible through the systems.

Defending against a TDoS is not the easiest, particularly when the attackers can use spoofed Caller IDs to hide their origin.  Here is a place where VoIP actually helps because if the calls are coming in over IP, firewalls and other network monitoring tools can be used to recognize patterns and potentially identify and block sources of the attacks.  There are companies such as SecureLogix (whose CTO is Mark Collier, whom I linked to earlier) who do sell products and services to help address these threats. As we increasingly move to IP-based communications there will no doubt be many more companies and service providers offering such services.

We as an industry do need to do what we can to help people understand both the threat posed by these attacks, and also the mitigations and possible solutions.

In the meantime, expect more people to be talking about this issue due to this DHS bulletin and the surrounding attention in the media.

What do you think?  What should be done within the VoIP vendor/organization community?  What are good steps to promote to defend against TDoS attacks?

Is The “VoIP” in “VoIP Security” Still The Right Term?

VoipqShould we still be talking about “VoIP security”? Or should we be using some other language?

Back when we started VOIPSA in 2005, “voice over IP (VoIP)” was the term we all were using, but as we look at what kind of activities come next, we’re starting to wonder if we should be talking about “communications security” a bit differently.

For starters, in the past 8 years we’ve moved far beyond simply “voice” into video over IP, text messaging over IP, data sharing over IP… all within a single communications session. Is that still “VoIP”?

Beyond that, we’ve seen a range of other terms coming into usage, including:

  • unified communications (UC)
  • real-time communications (RTC)
  • cloud communications
  • IP communications

and many more. Plus new technologies are out that have pushed “VoIP” beyond its traditional proprietary protocols and the open standard of the Session Initiation Protocol (SIP). We’ve seen the strong emergence of XMPP (Jabber) and its related “Jingle” protocol. We’ve seen the explosion of interest in the WebRTC / RTCWEB protocols and tools.

Are all of those “VoIP”? Or are they something more?

Should we be talking about…

  • UC security?
  • real-time communications security?
  • IP communications security?

Or perhaps just plain old “communications security”? (or is that too generic?) I’ve seen some people talking about “SIP security”, but now that is specific to a single protocol.

Or is “VoIP security” still an okay term to use?

What do you think? What do you use? What do you hear vendors and others using? How should we be talking about securing all these many ways we have to communicate now over IP networks?

Please do let us know either as comments here or out on social networks. (Thanks!)