Over on the Blue Box site, I’m pleased to announce that I uploaded Blue Box Video Edition #1, our very first experiment with adding a video component to the podcast. In this 5-minute video, I was out at VoiceCon San Francisco last week and interviewed Sachin Joglekar from Sipera Systems about the SIP softphone exploit they first demonstrated at Black Hat. Comments and opinions are definitely welcome. Would you like to see more of these type of videos?
Category Archives: Security
VoiceCon: "SIP Security" by Cullen Jennings and Eric Rescorla
This afternoon at VoiceCon in San Francisco, Cullen Jennings (of Cisco and Area Director for the Real-time Applications and Infrastructure area of IETF) and Eric Rescorla (Network Resonance, security advisor to IETF RAI area and involved with TLS spec) gave a 3 hour tutorial on “SIP Security”. Both Cullen and Eric (also known as “ekr”) are extremely involved with IETF efforts on securing SIP, so they were definitely the ones to do this presentation.
Cullen started out giving an overview of basic SIP and the issues within SIP that create challenges for security: routing/retargeting, forking and media before SDP answer (“early media”). Cullen gave the example for “early media” of getting the ringtone back, for instance, when you call someone in Europe. Streaming early media also sets up the media path so that there is no clipping. Lastly, some companies use early media in the PSTN to stream IVR msgs (FedEx, for example, plays the first 5 secs of their call center) and SIP needs to interoperate with those systems. (Open question – what do you do when you get early media from two endpoints that were forked? )
Cullen went on to describe the threats to VoIP, which he nicely summarized on one slide: Toll Fraud, Eavesdropping, Learning private information, Session replay, Fake identity & impersonation, Hijacking calls, Media tampering, DoS, Spam. He went on to elaborate on the different kinds of attackers.
Eric then stood up to give an overview of cryptography. Eric, one of the fastest talkers I’ve met, walked us through symmetric encryption, digest authentication (let’s you authenticate without having to send password in the clear, because both ends know the password), the key management problem (typically the hardest aspect of any security system), public key cryptography, digital signatures and hashes. Eric then went into a great step-by-step tutorial of how TLS is put together, starting with a basic channel security protocol and then talking about how to fix replay attacks, adding client authentication and adding in algorithm negotiation. One of the best descriptions of TLS that I’ve yet seen.
Cullen came back up to talk about securing the signaling. First he spoke about digest authentication and then got into TLS, pointing out that a major issue with TLS is the last hop. Proxies can easily get signed certificates, but getting certs in all the phones is a challenge. Cullen spoke about SIP “outbound” (also see here), which is a proposal that is close to getting to an RFC that addresses the issue of phones not having certs by essentially having the phones create TLS connections to their local proxy first. That last hop is now secured.
Cullen then moved into one of my favorite topics – identity. He spoke of the new(er) Identity RFC, RFC 4474, which standardizes a mechanism for a proxy to cryptographically assert the identity of one of the proxy’s users. The nice thing with SIP Identity is that you don’t need to modify the phones. It’s all done in the server software. SIP Identity looks to play an important role in efforts to combat SPIT, so it’s a key piece of the puzzle.
He continued into S/MIME and the problems with why it hasn’t really been widely deployed: users don’t have certs, no directory of certs and what about multiple handsets/devices? He then described a proposal that is an Internet-Draft, “Certificate Management Service for SIP” (status here), that would provide a mechanism for exchanging certificates for end-to-end encryption.
Cullen concluded by discussing how SIP deals with privacy issues, such as how to make anonymous calls (such as those needed by women’s shelters, whistleblowers, national security). The main recommendation is the need to have better anonymizing services to hide IP addresses in the From headers inside a SIP message.
Eric came up then to provide the last major segment around media encryption. As we’ve written about here and discussed over on Blue Box, the major issue in securing media really comes down to dealing with key exchange. Eric relayed the basic issues, the status of where the discussions are and then walked through the various solutions. He outlined the problems of MIKEY, the attempted (and failed) solution with sdescriptions and then the basics of ZRTP and DTLS. Eric, one of the people involved with the DTLS spec, gave a great overview of the DTLS spec and how it works.
Cullen came back up to wrap up the session with a comparison to the PSTN where he again stated his assertion that with VoIP we will wind up with far better security than that of the PSTN. He concluded saying that signaling security is mostly solved, RTP security is getting close, privacy works but does needs some work on location anonymous and that “security should and will be automatic.”
VoiceCon: Dave Endler & Mark Collier’s "IP Telephony Security Threats and Countermeasures"
Today here at VoiceCon in San Francisco, Dave Endler and Mark Collier (both of whom are involved with VOIPSA) gave a 3-hour tutorial on “IP Telephony Security Threats and Countermeasures”. For those who have read Dave and Mark’s “Hacking Exposed: VoIP” book, the tutorial followed the overall flow of the book. They began with Dave talking about gathering information about a target, using scanning, enumeration, Google-hacking, etc. Dave continued with talking about attacking the network through DoS, eavesdropping and then network interception – and the appropriate countermeasures to defend against the attacks. After the break, Mark went into attacks against Avaya systems and appropriate countermeasures. Dave followed with a similar section on attacks and countermeasures for Cisco systems. Mark came back to talk about attacks against applications, fuzzing and ultimately social attacks such as SPIT and voice phishing. Mark also spent a good amount of time talking about the various tools they developed as part of the book. Mark noted that they have updated the tools available on hackingvoip.com and will be making more updates in the coming months.
In his section on attacking Avaya systems, Mark Collier stressed a point we’ve made here on this blog:
“It’s great to have encryption enabled for signaling and voice and to buy phones that support it. Encryption is great and I highly recommend it. But if you don’t disable telnet or change default passwords, all that secure encryption really isn’t worth much.”
Indeed!
All in all a great session for folks looking for an introduction to VoIP security attacks and appropriate countermeasures.
BlackHat/DEFCON VoIP Security Tools Update
There were a number of new tools released at the recent BlackHat and DEFCON conferences that I’ve just finished adding to the VoIPSA Security Tools List.
First, during the BlackHat Voice Services Security track, Himanshu Dwivedi & Zane Lackey spoke about attacks against H.323 and IAX. They released a number of tools including H225regreject, IAXHangup, IAXAuthJack, and IAX.Brute. Now you can easily launch many of the same attacks (as well as a few new ones) that you’ve known and loved from attacking SIP against both H.323 and IAX.
Next, Zane Lackey & Alex Garbutt debuted their RTPInject tool during the BlackHat turbo-talk track. It’s essentially a nice, pretty, easy to use GUI version of the RTP audio injection attack that I demoed last year at EUSecWest using the rtpinsertsound and rtpmixsound tools.
At DEFCON, Ian G. Harris released a tool called INTERSTATE which is a stateful protocol fuzzer for SIP.
Finally, I released my new RTP steganography tool, SteganRTP, at DEFCON. It uses steganographic data embedding techniques to create a covert channel in an RTP session’s audio payloads which it uses to transport it’s own custom communications protocol. The protocol provides user chat, file transfer, and remote shell access (if enabled).
All of the tools mentioned above can be found via the VoIPSA Security Tools List.
Podcast: "The Real Risks of VoIP Security" Panel from VON Europe 2007 in Stockholm, Sweden
Were you unable to get to VON Europe ’07 in Stockholm, Sweden back in June to hear the panel session on “The Real Risks of VoIP Security“? Well now you can hear it. Blue Box Special Edition #19 is now available for download.
In this session, our own Martyn Davies is the moderator and the panelists are Ari Takanen of Codenomicon, Cullen Jennings of Cisco and Akif Arsoy of Verisign. Readers of the VOIPSEC mailing list will have seen posts from Ari at various times and it’s hard to escape Cullen in the world of IETF standards! Rather than just going through endless slides, the panel engaged in a conversation based on questions from Martyn and then the audience. It was a lively session with lots of good questions, interaction from all three of the panelists and Martyn with the audience… and Cullen making the kind of statement “that everytime someone from Cisco makes a statement like this we make ourselves subject to attack” (you’ll have to listen to understand that teaser 🙂
I think you’ll find it both enjoyable and educational. Thanks to Martyn for producing the recording and for Ari, Cullen and Akif for agreeing to have it distributed. Thanks also to Carl Ford, Jeff Pulver and the rest of the VON team for allowing us to record and distribute the session.
Jonathan and I welcome any and all comments about these special editions. You can leave them here on the VOIPSA weblog, on the Blue Box weblog, sent to blueboxpodcast@gmail.com or called in to our comment lines at +1-206-350-2583 or sip:bluebox@voipuser.org.
Telecom Junkies podcast: Interview with a VoIP Hacker (Robert Moore of the Pena/Moore voip fraud case)
Remember the Pena/Moore voip fraud case back in June 2006? Would you like to know how the attacks were done? And how you can protect your network?
First, for those who don’t recall, this was a case where Edwin Pena was alleged to have set himself up as a voice service provider and then, with the assistance of a developer named Robert Moore, routed his customer’s calls across the networks of other VoIP service providers. Pena is alleged to have stolen at least 10 million minutes from other voice service providers and made in excess of $1 million dollars. Pena subsequently fled the country (and remains even today a fugitive). We wrote about it here and also covered it in Blue Box podcasts #31 and #33 and I was a guest on a Telecom Junkies podcast back in July 2006 discussing the case.
In any event, one year later Robert Moore has been convicted for his part in the scheme and on July 24th was sentenced to a two-year term in prison, 3 years probation and a $150+K fine.
Before he reports to prison in about 6 weeks, though, Moore got in contact with Jason Huffman from The Voice Report to ask if Jason was interested in an interview. Given my prior involvement with the Telecom Junkies podcast, Jason contacted me to see if I would also be interested in coming onto the show. Both he and I were concerned about interviewing someone recently convicted (i.e. not wanting to glorify the crime or criminal), but I shared Jason’s view that if we could obtain information about how the attacks were done we could potentially help people protect their systems against these type of attacks. (Jonathan was also invited and provided great feedback but was unable to attend due to scheduling issues.)
The result is a new Telecom Junkies podcast: “Interview with a VoIP Hacker” which is available for download.
As we’d discussed in our previous coverage of the case, there were really two different types of systems that were attacked:
- Voice gateways of VoIP service providers
- Servers/routers of other businesses that were compromised to hide the source of traffic going to the voice gateways
In the interview, Robert Moore confirms that all the voice gateway attacks were H.323 (no SIP was involved) and they weren’t terribly sophisticated because the VoIP service providers didn’t have all that much security in place.
Moore also indicates that all the other boxes (#2) were compromised primarily by easy means such as weak and easily guessable passwords – or even worse, unchanged default passwords. In some cases, there were boxes on the Internet with exposed SNMP ports that then let the attackers learn all about the box so that they could then research potential vulnerabilities. This part really had nothing whatsoever to do with VoIP but instead with really just basic IT security practices which were (and undoubtedly still are) very obviously not being followed by many folks out there.
In any event, the interview is now available for listening. Meanwhile, Moore is soon heading off to prison and Pena is still somewhere out there…
P.S. If anyone listening can identify the name of the second switch vendor that Moore indicates he went after, neither Jason nor I could identify it despite my request for the name to be repeated.
UPDATE: Thank you to all who responded. The other switch was a Quintum Tenor – http://www.quintum.com/
Four Asterisk security vulnerabilities released
Last week the folks at Digium released 4 security advisories on their www.asterisk.org/security web site. They are:
- ASA-2007-014 – Stack Buffer Overflow in IAX2 channel driver
- ASA-2007-015 – Remote Crash Vulnerability in IAX2 Channel Driver
- ASA-2007-016 – Remote Crash Vulnerability in Skinny channel driver (note that the advisory PDF is actually at this link versus the one currently on their web page – UPDATE: The ASA-2007-016 web page has been fixed.)
- ASA-2007-017 – Remote Crash Vulnerability in STUN implementation
There are fixes for all the issues (basically, to upgrade to the current release of the Asterisk stream you are using) and if you are using Asterisk (or a derivative of Asterisk) we would encourage you to read these advisories and take the recommended actions.
On a side note, it’s definitely been great to see the changes Digium has brought to reporting security issues with Asterisk. First was the security portal at www.asterisk.org/security and then starting in April were these well done security advisory documents. Kudos to Kevin Fleming and the rest of the developer team there. (Thanks also to Kevin for starting to post these advisories to the VOIPSEC mailing list.)
"Voice over VoIP" project aims to show use of "covert channels" to tunnel voice inside of voice
We were contacted today by Takehiro Takahashi, a graduate research student at the Georgia Institute of Technology, who has an intriguing new research project they called “Voice over VoIP”. From their main web page:
Vo2IP is a proof of concept attack which demonstrates a new type of VoIP threats, the VoIP covert channel. With Vo2IP, you can establish a hidden conversation by embedding further compressed voice data into regular PCM-based voice traffic (i.e. G.711 codec). Therefore anyone who is wire-tapping your conversation will decode something completely different from the actual conversation – granted that he is not aware of the use of Vo2IP.
As I understand it, they basically take a G.729 audio stream and tuck that into a spare 8Kbps that can be found in a G.711 audio stream. An eavesdropping attacker would hear only the overall G.711 audio while the Vo2IP clients on either end encoded/decoded the covert stream (more details here and here). In any event, Takehiro and his fellow researchers would be very interested in any feedback folks have on the project. Source and binary code for Windows is available. Please email Takehiro with any feedback.
We Know Where You Live
One aspect of VoIP security that keeps coming to my attention in recent weeks is that of location privacy, or in other words, does the call recipient (or others ‘listening on the line’) know where you are?
At a VON Europe panel this week, Cullen Jennings, Distinguished Engineer at Cisco, was talking about peer-to-peer (P2P) SIP, and how the P2P approach definitely helps with location privacy. He gave the example of emergency procedures in the USA, which require the country’s President and Vice President to be in different physical locations from each other yet still be able to communicate. At the same time, they must prevent eavesdropping enemies from locating the Vice President physically.
I said that ‘P2P helps’, but perhaps I should say ‘can help’, with the right systems in place. In the UK last week, Sky News ran a story about how criminals might use encrypted VoIP to run circles around the police, due to the difficulty of tapping and listening to the calls. I hope to be able to write in more detail in the next few weeks why this is basically untrue, but the information I have received is that the VoIP providers “can be very helpful” to the police in these cases. Even if a VoIP stream cannot be decrypted, it is often possible to obtain a list of times, durations, and IP addresses that can easily provide both location and evidence. Also, if a VoIP call breaks out onto the PSTN, a service offered by many or most VoIP telcos, then once again you have a location (albeit the call destination rather than the source), and you have the opportunity to monitor the call.
No-one likes to think that all their calls are being tracked, or that their location is known at all times, but of course in democratic countries we assume that there are enough checks and balances to ensure that this information is available to few and will not be abused. At the same time, criminals and terrorists should not assume that new technologies like VoIP and IM give them a cloak of anonymity, because this is definitely not the case.
IETF group puts forward framework to combat SPIT (VoIP spam) for discussion
As systems become increasingly interconnected, how do we prevent Spam for Internet Telephony, a.k.a. “SPIT” or “VoIP spam”. As we talked about in this blog and on the Blue Box podcast, SPIT today is not really a huge issue because the PSTN serves as a de facto firewall between companies/entities. But as we move toward increasing interconnection and to the point where a random SIP user could make a SIP connection across the Internet to any other random SIP user, we definitely do have to worry about SPIT and how to prevent it.
Within the IETF, a group has been working on the issue and now has two documents available for review:
- A Framework for Reducing Spam for Internet Telephony
- Requirements for Authorization Policies to tackle Spam for Internet Telephony and Unwanted Traffic
This is the initial release of both documents and the authors are definitely seeking feedback. Speaking of the authors, they include many of the names we have mentioned here in the past involved with VoIP security within the IETF space: Hannes Tschofenig of Nokia Siemens, Henning Shulzrinne of Columbia University, Dan Wing of Cisco, Jonathan Rosenberg of Cisco and David Schwartz of Kayote. (Geoffrey Dawirs of University of Namur and Thomas Froment of Alcatel-Lucent are also authors of one, but I don’t believe we’ve spoken of either of them here before.) They are definitely people who understand the space and have put some thought into it.
I would encourage everyone to take a look at those documents and send in feedback, either to the IETF mailing lists or directly to Hannes Tschofenig (editor of both docs). We have an opportunity here to make sure that interconnected VoIP does NOT become the utter cesspool of spam that email has become. Let’s make sure we do it right!

