Previously I mentioned that Hannes Tschofenig had a presentation up about SIP security that he gave at the ETSI Security Workshop early this month. We were contacted by folks at ETSI to let us know that all the workshop presentations are now available online. I haven’t looked through them yet, but the workshop agenda looked good to I am looking forward to checking these presos out. Thanks to ETSI for making them publicly available.
Technorati Tags:
sip, etsi, standards, security, voip security
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 Podcast#73 is now available for download. In this show, Jonathan and I discuss SIP security issues at IETF 70, Skype security, vulnerabilities in Cisco and Nokia phones, Vietnam’s cyberdissidents, VoIP security news, listener comments and more..
Technorati Tags:
blue box, bluebox, voip security, voipsecurity
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.”
Back to telephony SPAM or SPIT again. Hannes Tschofenig noted on his blog the publication of an RFC draft on the use of CAPTCHAs in SIP.
For the uninitiated, CAPTCHA means “Completely Automated Public Turing Test to Tell Computers and Humans Apart”, or in other words an automated test of your humanity. In the context SPAM over Internet Telephony, the aim is to tell genuine human callers from ‘bots’ or software that aims to make our phones ring and play unwanted marketing messages at us.
Some of the choices are laid out there, for example a system (corporate PBX for example) could challenge an incoming call, by playing a sound, then asking you to describe the sound. Or in the case of a video call, show you a picture and ask you to describe it in words before connecting the call. A moment’s examination would allow a human to conclude “teapot”, where a computer looking at a cartoon or photo teapot would need to expend a lot of CPU to reach the same result.
Ok, you may say that computers are so smart now that they can recognize pictures, or do automatic speech recognition (speech to text) remarkably well. This is true, to a degree, but the fact is that clever CAPTHCAs will demand heavy processing on the attacker’s side, and this works against what they are trying to do. After all, they want to implement systems that can make thousands of calls per hour at low cost. If we increase the cost of the calls by adding a quarter of a second of CPU to each call, then we give the telephony spammers a capacity problem, and force them to spend much more on server machines. By making SPAM an economic problem once again, we can raise the barriers to entry.
The draft text can be found here, and Hannes’s blog is here.
I wrote previously about new Internet-Drafts out about a “framework” for combating Spam for Internet Telephony, a.k.a. “SPIT”. With the IETF 69 meeting coming up in a few weeks in Chicago, Hannes Tschofenig is really looking for some feedback on these docs so that he can incorporate any feedback before the IETF 69 meeting. We would strongly encourage people to take a look at these docs and send comments directly to Hannes Tschofenig. I have commented… please add your voices. (He’s looking for all kinds of feedback… for instance, I gave some input on an earlier draft that a section needed to have more details added because I didn’t understand it overly well.)
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:
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!
A story: ZZZ Telemarketing (not a real name) is locked in a heated fight with their bitter rival, YYY Telemarketing (also not a real name), to win a very large lead generation contract with Customer X. Customer X has decided to run a test pitting the two companies against each other for a week to see who can generate the most leads. The ZZZ CEO has said to his staff that it is “do or die” for the company. If they fail to win the contract, they will have to shut down – they need to do “whatever it takes” to win over YYY. A ZZZ staffer discovers that part of why YYY has consistently underbid them is because they are using SIP trunks to reduce their PSTN connection costs. But the staffer also discovers that YYY is using very cheap voice service providers who run over the public Internet with no security.
Discreet inquiries are made in the dark corners of the Internet. A large sum of money is exchanged through third-parties. The test begins on Monday and both firms are off in their own buildings rapidly calling. But at a designated time on Tuesday, a bot-herder somewhere out on the Internet connects to an IRC chat room and enters a line of text. Moments after the Enter key is pressed, “bots” on tens of thousands of zombie PCs wake up and start slamming the SIP servers at YYY and its providers with enormous numbers of bogus SIP messages, each of which require processing. Effectively all outbound (and inbound) PSTN connections grind to a halt. YYY IT staff try desperately to stop the attack but don’t have any real knowledge of how to defend against these attacks. Because the attacks paralyzed YYY’s SIP server but left their Internet connection still usable, their ISP won’t help and says it is a problem for their telephony providers. Those providers, of course, are preoccupied trying to fight off the the attack themselves. Meanwhile, hidden out on the net, the bot-herder watches the attempts and simply brings more botnets online as some nodes are successfully shut down or blocked.
Late on Wednesday at a designated time, the bot-herder enters the IRC room again and enters another command. All bots immediately cease their attacks. YYY can now make calls, but in their desperate attempts to restore connectivity the YYY IT staff has made such a mess of their network that it takes them until extremely late in the evening to return full service. Thursday morning YYY is back in full operation, but it’s too late to overtake ZZZ’s head start. ZZZ wins the test and the contract. (And YYY’s lawyers desperately search for some way to pin this on ZZZ.)
Is this just a piece of creative fiction? (or a nightmare?)
Today, probably yes… but last week the first steps toward bringing about the reality appeared in the VOIPSEC mailing list when a group of academic researchers announced the availability of a “VoIP bot” for testing automated attacks against VoIP systems that use the SIP protocol. While the researchers indicated they were making it available to aid in the efforts to develop effective tools to prevent attacks, the cold, hard reality is that the same tool and code can be used for attacks by those out operating botnets for malicious purposes. Deploy it on hundreds (or thousands) of zombie computers and an attacker potentially has a great way to execute a distributed denial of service (DDOS) against a company with, for example, a SIP trunk across the public Internet. Thereby potentially shutting down that company’s access to the PSTN. No inbound or outbound phone calls for the duration of the attack.
Welcome to the era of VoIP botnets.
With all the VoIP security tools out there, we knew it was only a matter of time before this occurred, but now the proverbial genie has been let out of the bottle. (or is it “bot-tle”?)
REALITY CHECK #1 – Now, before anyone cues the song “It’s the End of the World as We Know It” and starts to rip out their VoIP deployment, let’s be clear that this bot only affects systems using the SIP protocol. Given that the vast majority of corporate/enterprise VoIP deployments today occur with proprietary protocols (and this is true of all the main VoIP vendors), this news has little immediate impact on that segment of the market. However, most all enterprise vendors are now supporting SIP phones and/or SIP trunks – and so this definitely will be a concern in the future. In the PSTN line replacement market, though, there certainly are a good number of service providers offering SIP connections/trunks. If they are doing that across the public Internet (versus their own network where they can better control traffic) then this is definitely something of concern to them.
REALITY CHECK #2 – Let’s also be clear that there is no massive botnet out there right now out there waiting to kill all your SIP trunks or SIP sets (that we know of). What was released was a “proof-of-concept” that showed in a very basic way what could be done. The real threat is that attackers could modify the code, improve/tweak it, and start to deploy it out there in larger botnets. If we don’t look at ways to address the issues raised here, it will, though, become a more serious issue.
With those statements out of the way, let’s look at what this proof-of-concept bot does. First, as shown on the README page, you connect to an IRC server and create a chat room/channel. You then install the software onto a PC and run it (it’s a Java JAR file), providing the name of the IRC server and channel to which you are connected. You then simply start executing SIP attack commands. If you start up several instances of the bot connecting to the same IRC channel, you can issue commands that are implemented by all your bots.
Simple. Easy. (Scared yet?)
So what does it do? Well, here are the commands:
A limited command set today, but the researchers indicate they will be refining it – and the source code is now out there for anyone to obtain and modify. And for something like a DOS (or DDOS) this could be effective. I only installed one bot on my test network, but I did see that it did generate a large number of packets against a SIP server I have running here. You could see the power of multiplying that.
So with the genie out of the bottle, what do we as VoIP security professionals do about it?
I’ll offer several suggestions (and certainly welcome more as comments to the post):
Going back to my story at the top, YYY might not have had the problems if their SIP server were set to reject all packets that did not originate from their service providers… or if they had required encryption with mutual authentication so that spoofed IP addresses couldn’t affect things… or if…
The reality is that there are solutions out there today that will go far in blunting the effect of these type of attacks. We just need to be sure that we are using and improving those solutions… if we don’t… well… then we will be cueing up that song!
Other comments or suggestions?