Voice of VOIPSA

Within the IETF there’s been a bit of discussion in the past months
about voice spam/SPIT and just recently RFC 5039 from Jonathan
Rosenberg and Cullen Jennings was published that specifically
addresses the issue of SIP and Spam.

The RFC is an excellent summary of the current thinking about the
SPIT problem and potential solutions to address it. If you haven’t
read the document, I would *highly* recommend it.

A concern I had, though, was that it did not appear to me that
existing documents address the issue of what SPIT could look like at
a network level. For instance, if a network administrator monitoring
network traffic suddenly saw a large flood of SIP INVITE packets
coming into his/her network, it could be:

1. a telemarketer/spammer launching a flood of SIP connections to
deliver SPIT;
2. an attacker launching a DoS attack through one of the various SIP
attack tools out there; or
3. a legitimate notification system starting to notify a range of SIP
endpoints.

I could very easily see existing network tools that look at traffic
and perform anomaly detection (and potentially source suppression)
being modified to suppress large flows of SIP traffic. This last case
of legitimate traffic concerned me and so I put together an Internet-
Draft talking about the types of legitimate systems that might
generate a significant volume of traffic that could resemble SPIT (or
a DoS attack).

I put the document out primarily to stimulate discussion. Are these
legitimate scenarios being addressed in current thinking about
SPIT? If not, my point really is that they need to be considered.

Comments about the document are very definitely welcome. Are there other scenarios I
should include? Am I accurate? Am I overstating the case? or what?

Technorati Tags:
ietf, security, sip, standards, voip, voip security

Hannes Tschofenig is over at the 3rd ETSI Security Workshop in France this week and yesterday gave a talk about SIP security. He has now posted the slides to his blog - My Slides from the 3rd ETSI Security Workshop:

Yesterday I gave my presentation at the 3rd ETSI Security Workshop. My presentation title was ‘IETF Security’ and that is obviously pretty fuzzy. After looking on the agenda I decided that the most useful topic to speak about would be SIP identity management and media security. In case you are interested in this topic, please take a look at the following slide set.

His slide set does give an excellent overview of security issues in SIP, the various RFCs and approaches, etc. As he mentions, he focuses on identity and media security. A great contribution to the ongoing dialog on these issues. In fact, much of the workshop agenda looks quite intriguing. It will be interesting to see if other presenters make their slides available or if conclusions are posted anywhere.

Note to other presenters: If you do put your slides up somewhere, we’re glad to link to them here. In fact, if you use SlideShare (or a similar service), we’ll be glad to embed the presentations directly in this blog.

Technorati Tags:
ietf, security, sip, standards, voip, voip security, hannes tschofenig

The IETF leadership recently announced that they are seeking final comments on an Internet-Draft called “Requirements from SIP Session Border Controller Deployments” (current draft also available here) as they decide whether to move this document to an Informational RFC. The abstract of the document is as follows:

This document describes functions implemented in Session Initiation Protocol (SIP) intermediaries known as Session Border Controllers (SBCs). The goal of this document is to describe the commonly provided functions of SBCs. A special focus is given to those practices that are viewed to be in conflict with SIP architectural principles. This document also explores the underlying requirements of network operators that have led to the use of these functions and practices in order to identify protocol requirements and determine whether those requirements are satisfied by existing specifications or additional standards work is required.

If you work with SBCs, use them in your networks, or work for a SBC vendor, now is a good time to ensure that this document captures the requirements you have for deploying SBCs. Once finalized as an Informational RFC, the idea is that it will be used to assist in the potential creation of new SIP-related standards or the modification of existing standards. Now is the time to voice your opinion (and the note from the IETF explains how to do that). Comments have been requested to be received by January 16, 2008.

Technorati Tags:
ietf, security, standards, voip, voip security, session border controllers, sbcs

Blue Box Special Edition #22 is now available which explores and explains the details around SIP and NAT traversal. In this interview I sat down with Dr. Jonathan Rosenberg, a Cisco fellow and author of a wide range of RFCs and Internet-Drafts related to SIP to talk about SIP and NAT traversal. We explore what the problem is, how ALGs and SBCs attempt to solve the problem and how the IETF has looked to address the issue through first STUN, then TURN and now finally ICE. I think you’ll find it a very educational and informative session.

On a similar note, you may also be interested in Blue Box Special Edition #20 where I sat down with Cullen Jennings to talk about overall security issues with SIP. These two podcasts together give you a solid overview of the current security issues with SIP.

Technorati Tags:
blue box, bluebox, dan york, danyork, ietf, sip, standards, voip security, jonathan rosenberg

I’ve long been a staunch opponent of the “isolate your VoIP network from your data network” strategy. I personally believe that by putting up such restrictive barriers as would be required to provide any sense of actual security, the owners and administrators of a VoIP deployment are severely limiting the potential value they are able to receive from using Internet telephony. One of the Great Promises of VoIP is the ability to integrate communications with other productivity technologies such as work-group software and CRM applications. A lot of VoIP security practitioners tout the isolation strategy as a solution for the insecurity of the VoIP core devices and endpoints when in reality it is little more than a stop-gap, and not a very good one at that. By providing a false sense of security by way of network isolation, many VoIP deployment administrators may become complacent and pay less attention to the security posture of the actual VoIP devices and endpoints themselves. If you plan to integrate your communications system into the data-flow of your business in even the most minimal way, you’ll find quickly that most types of isolation that are available either provide a barrier to the desired functionality or open up so many holes in the barrier that it may as well not be there.

(more…)

In a few hours I’ll be boarding a plane back to New York where I’ll be attending Interop New York this afternoon and tomorrow. If any of you reading this will be there, please do drop an email. Tomorrow, I’ll be on a panel at 2:45pm with Jonathan Rosenberg about “Voice-oriented Attacks”. (Side note to Interop: Please make it so that we can link to individual sessions instead of having to link to the entire list of “security”-related sessions!) If you aren’t aware of who Jonathan Rosenberg is, he works for Cisco and is a huge contributor to IETF efforts related to SIP and in fact was one of the co-authors of RFC 3261 which is the primary RFC defining SIP. He’s also the author of “The Hitchhiker’s Guide to SIP” which aims to help guide people through the maze of the many, many documents that now are part of “SIP”. More relevant to tomorrow’s session, he’s also the author of a series of NAT traversal protocols for SIP, namely STUN, TURN and now ICE. Eric Krapf, the moderator of the session, is aiming to make it a more interactive and discussion-focused session (i.e. no slideware-to-death)… we’ll see if we can make it fun as well. I’ve also asked Interop for permission to record it and run it as a Blue Box podcast - we’ll see if they give me permission.
Note that if you are a CISSP, the ISC2 is holding a member reception today (Wednesday October 24, 2007) starting at 5:30 PM in Jacob Javits Center Room 1EO2 - LEVEL 1. Assuming that everything works with my flights today, I’ll be there.
I’ll even have some new business cards to give out…

P.S. I’ve now been public about who my new employer is.

Technorati Tags: cisco, conferences, danyork, jonathanrosenberg, security, voip, voip security, voipsa, voxeo

Blue Box Podcast #69 is now available for download. In this 46-minute episode, Jonathan and I discuss the Linksys SPA-941 vulnerability mentioned in the VOIPSEC list, a potential SIP DDoS, a new release of SIPVicious, a suggested Asterisk security roadmap, other VoIP security news, listener comments and more.

If you are an Asterisk user, what do you see as the “security features” that it needs to have? I’m out here at the annual AstriCon event in Phoenix, Arizona, where on Thursday I am giving an “industry perspective” under the title: “Hacking and Attacking VoIP Systems - What You Need to Worry About” Given that I’m doing the talk under the VOIPSA banner, I’ll be giving my “standard” view on what the main threats are to VoIP, the tools that are out there to attack them and the best practices to protect against those threats. However, whenever I do this kind of “industry view” at a conference like this, I always try to include a section at the end that is specific to the audience.

So in this case, I thought I’d tack on a bit at the end about a “security roadmap” for Asterisk, i.e. what are the top 5 things that Asterisk developers should be thinking about. My slides are actually done (and I’m currently at 6 items on the list), but I’m not going to really post them here until I give my talk. (Come on, I have to have a bit of suspense, don’t I?) In the meantime, I thought I’d ask the question here on the blog:

What security features do you think are necessary in Asterisk?

Well, okay, I’ll list three obvious ones: 1) TLS-encrypted SIP; 2) SRTP (yes, there’s a patch, but it’s not in the main load); and 3) SRTP key exchange (sdes, DTLS, ZRTP, etc.)

But what are the other three on my list? And what would be on your list? (And if you list some great ones I haven’t thought of I’ll be sure to credit you in my preso.)

By the way, Thursday should be an interesting day (for me) here at AstriCon because there are actually three talks related to security. Obviously mine but then one right before me from someone named Mike Storella and titled “Realizing the Benefits of a Secure VoIP Telephony System” and one in the afternoon from a Patrick Young titled “Enterprise VoIP Security“. It will be entertaining to see if we are all reading from the same general pages. I’m also going to see if I can get their permission to record the sessions and put them out as Blue Box special editions. We’ll see.

In the meantime, if any of you reading this are attending AstriCon, feel free to drop me a note as I always enjoy meeting up with readers.

Technorati Tags: asterisk, astricon, security, voip, voip security, voipsa

FYI, for those of you attending the Internet Telephony Conference & Expo in Los Angeles on September 10-12, I’ll be participating in a panel session that is part of Ingate’s SIP Trunking Seminar Series.  I expect it will surprise no one to learn that I’ll be on the panel about “Enterprise Security and VoIP” speaking on behalf of VOIPSA.  My particular session is Tuesday, September 11, 2007, from 9:30-11:00 am.  More details and the schedule are available online.

The sessions are free and open to anyone to attend.  Simply fill out the pre-registration form. If you are going to be there at the show, please do drop me a note, as I’m always interested in meeting readers or others interested in VoIP security.

Back on August 22nd, Radu State from the Madynes research group in France posted a security advisory to the VOIPSEC mailing list, “Remote eavesdropping with SIP Phone GXV-3000“.  He also posted it to full-disclosure and several other lists.  As he writes:

While playing with the SIP Madynes stateful fuzzer, we have realized that some SIP stack engines have serious bugs allowing to an attacker to automatically make a remote phone accept the call without ringing and without asking the user to take the phone from the hook, such that the attacker might be able to listen to all conversations that take place in the remote room without being noticed.

The Madynes team also included the perl exploit script in the advisory as well, enabling someone wishing to test this to easily execute the attack.   They indicate that they have found this vulnerability in several SIP stacks and that they can disclose the vulnerability with the Grandstream phone as Grandstream was apparently notified of this issue back in May.  They indicate that “fixed software will be available from the vendor” - however as of today, Grandstream’s firmware page is still showing the same load as that found to be vulnerable by the researchers.  Unless I missed it, I can’t seem to find any page on Grandstream’s site dealing with security issues.

The reason I mention this here, partly, is because the issue was slashdotted, based on the Sûnnet Beskerming article “Listen to SIP Phones Even When They are on the Hook“.

If you use Grandstream phones, I would suggest you should be contacting Grandstream to find out when a fix may be available.  If you a producer of SIP phones, you might want to have a look at the exploit, which seems to be fairly straightforward, and see if your phones are vulnerable.