Monthly Archives: May 2007

Google launches security blog

While it is not about VoIP, per se, Google’s new “Online Security Blog” is definitely good to see, in my opinion.  In their first post, they talk about malware and have some interesting stats on where the malware is coming from.  Their second post is about virtual machines.  We’ll see where the blog goes, but to me it’s just good to see an organization with as much data as Google can amass now talking about security.

Technorati tags: ,

IPTComm 2007 Conference Agenda Published

The papers are in and the conference agenda is now published.

There’s plenty of meat here for those interested in VoIP Security, with  talks on intrustion detection and prevention, SIP security architecture, SIP fuzzing and DoS prevention.  Jeff Pulver will deliver the keynote, and many of the speakers are the same people that create such interesting discussion trails on the Voipsec list anchored on this site.

If you’re in New York  July 19th/20th, it’s going to be a great session.  Registration is open here.

DEFCON 15 to include talk on “VoIP and Steganography”

As he writes over on his own blog, frequent contributor (to this blog) Dustin D. Trammell will be speaking at DEFCON 15 about VoIP and steganography.  His presentation “Real-time Steganography with RTP” will be about some new research he’s been doing.  I don’t know about you, but I’ve always had a fascination with steganography, long before I even had a clue that there was a word for it.  The idea of hiding messages inside of other innocuous messages… a very simple case being the old “shopping list” where the first letters of each word actually spelled out some other message… or something like that.   I have no idea what he’ll be speaking about, but the topic sounds intriguing.  (And we’ll just have to see if we can prevail upon him to write up some text here after the event… or talk about it on Blue Box.)

Security: A Question of Balance

According to, Ivan Krstić, Director of Security Architecture for the One Laptop Per Child project, used a keynote speech at AusCERT 2007 to criticize the architecture of modern operating systems, which allow every application to run with maximum access rights to the machine.

This is of course a topic that exercises many security managers these days, since there are so many things that a multimedia PC can do today, including playing, recording and editing music & video; creating and editing images and text; phoning, instant messaging and video calling. What is more there are vast numbers of applications that can be rapidly bought and downloaded from the Internet, giving near instant on-demand installation of nearly any type of application. For convenience, most users run in administrator mode all the time, as it avoids answering pesky questions when we want to install and gratify our need for new software.

Many VoIP users run softphones on their PCs. Softphones are cheap, and can be extremely convenient to use. They also create new possibilities, like being able to record calls or teleconferences without spending a lot of money on recording hardware and software. From a security point-of-view, of course, this is a risk, since the softphone can control all the facilities of your PC, has access to the disk drive, and could potentially record audio, or perhaps even all LAN traffic, without you knowing. From a LAN architectural point of view, some experts say that you should use VLANs, so that VoIP phone handsets and PCs cannot interact with each others’ traffic. This would avoid a PC being able to initiate SIP calls (if, say, a malicious user wanted to run some SIP scanning software on a machine), but if you want the convenience of running softphones, then the PCs must be able to make SIP calls, so really VLANs are out.

So once again it really comes down to security versus convenience. We can lock down PCs completely and make them “safe”, but then you could argue that users will be less productive, if the IS department must get involved whenever any new thing will be installed. At the other end of the scale, letting users install everything they want, from wherever, whenever they feel like it, is a recipe for a security disaster. It’s a balance, and that is one of the reasons that security is a difficult area.

To talk about the One Laptop Per Child project for a moment, this is an effort to build a $100 laptop (the XO) that can be made in the millions to provide to school children everywhere. If you haven’t heard of this before, I strongly recommend that you watch the video from TED 2006 where Nicholas Negroponte explains what they are trying to do. A very worthwhile project and this video is 18 minutes of gold dust. Describing one of their pilot projects in a remote village Cambodia, Negroponte says of the children with their laptops: “They only know Skype, they’ve never heard of telephony.”

How to be a Spook

MI5, the UK’s Security Service, wants more geeks, according to The Daily Telegraph, and will be advertising on the Tube (London Underground) in the next few weeks to try to boost recruitment. Would be’s imagining the life of James Bond, Harry Palmer or really even Austin Powers need not apply, though, since they are most likely in MI6 anyway.  The job-in-hand here is intelligence analysis, lawful interception in foreign languages and network security.  Their online jobs page can be found here.

It’s only a few years ago that MI5 were first allowed to openly advertise jobs (which makes you wonder what the recruitment process was before), but now they have a pretty nice website, which makes it much easier to see what the whole setup is about.

Ready or not… here come the IRC-controlled SIP/VoIP attack bots and botnets!

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:

  • spit – sends an audio file to a specified SIP address
  • dos – sends successive SIP invites to a SIP address for a specified period of time
  • scan – takes a list of possible user names and sends a SIP INVITE for each one (trying to determine what SIP usernames are used)
  • crack – if you know SIP user names (potentially from ‘scan’) you can try to crack the password
  • register – if you know a SIP username and password, the bot will send a SIP REGISTER packet

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):

  1. Play with this proof-of-concept bot – In order to defend against something, we need to understand it. Grab this one now and start understanding how it works…. before larger botnets targeting VoIP do actually get out there.
  2. Understand what SIP security options you have – If you are using SIP in your VoIP infrastructure (either for phones or for trunking) understand what options you have for securing the SIP signaling. Can you encrypt the SIP signaling? Can you only accept connections from specific endpoints? Talk to you vendors and service providers. With either of those options you would greatly reduce (if not eliminate) the impact of a botnet attack.
  3. Ask your SIP service provider if they support secure SIP connections (and if not, when they will) – As we have ranted here and on the Blue Box podcast, service providers offering SIP connections over the public Internet without securing those connections are, in my opinion, playing a dangerous game and are most likely the first to be affected by something like this.
  4. Test, test and re-test your SIP systems, phones and other endpoints – The VoIP security tools are out there to test your implementation. What are you waiting for? Test anything with a SIP connection (obviously your own devices or with the permission of the owner). Report any issues to the vendors (and if the vendor doesn’t respond, contact us here at VOIPSA and we’ll see if we can put you in touch with someone).
  5. Participate in IETF efforts to better secure SIP - As I wrote last week, there are definitely areas of SIP security that need to be improved within the IETF. We need to get better support all around for TLS-encrypted SIP (aka “SIPS”). We need to solve the SRTP key exchange problem. We need to make get NAT traversal mechanisms like ICE fully standardized. We need vendors and service providers to implement existing RFCs… and we need to reach closure on other issues. Join the SIP, SIPPING and RTPSEC mailing lists. Comment on existing Internet-Drafts or contribute new ones.
  6. Understand “botnets” and what network defenses you can use – Botnets are not new. There is a great amount of info out there already (some pointers here, here, here and here). Talk to others in the field and see what defenses you can use within your existing network infrastructure.
  7. Ensure you aren’t a source of zombie computers – It goes without saying that just in general you should already be employing mechanisms to ensure that spyware/malware isn’t being installed on your computers. Anti-virus is part of that, as are things like ensuring that all computers are up-to-date on patches.
  8. Don’t panic – As I said at the beginning, we are not aware of any massive botnets out there targeting SIP (at least today… check back tomorrow). This is just yet one more thing to add to our list of many other things to be considered as we look at how to secure VoIP.

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?

SIPIt 20 shows the very clear need for SIP security interoperability

Last week, SIPit chair Robert Sparks posted the results of a SIP interoperability survey to the IETF SIP mailing list coming out of the recent SIPit 20 event held in April. For those not familiar with “SIPit” events, they are week-long events sponsored by the SIP Forum held twice a year where vendors bring together their SIP products to test interoperability between their various products and implementations. This particular event, the 20th, was hosted by Alcatel Lucent in Antwerp, Belgium. 67 vendor teams participated, of which 59 completed the web-based survey that generated this data.

The full results of the survey make for interesting reading, but I thought I’d pull out some of the security-related items. First up, SIPS (aka TLS-encrypted SIP):

There was a lot of (understandable) confusion about what to do with sips:. Most implementations that could handle TLS are not yet trying to handle sips:. The few that did try to do something sane with sips: are watching the discussion on the SIP mailing list. In any case, there was not a set of implementors present who felt sips was sufficiently specified and would be unhappy if the definition changed. I also didn’t find anyone who felt an existing deployment would suffer from any change to the definition.

Next up, NAT traversal and STUN/TURN/ICE:

When asked about STUN support, the client implementations replied:
8% I implement all the client requirements of draft-ietf-behave- rfc3489bis
6% I implement some, but not all, of the client requirements of draft-ietf-behave-rfc3498bis
4% I implement all of the client requirements of RFC3489
14% I implement some, but not all, of the client requirements of RFC3489
60% I do not implement STUN as a client
8% Other

There were several STUN servers and at least two TURN servers. We had more TURN clients this time, and successfully exercised TURN. Three implementations claimed support for ICE, but no interoperability was reported (I suspect there were versioning issues that couldn’t be overcome in the time-scale of the event). There was one ice-tcp implementation present.

And the big one of most interest to me personally (and with my emphasis added):

There were 9 SRTP endpoints (down from 12 at the last event). Only 4 of those used sdes.
Interoperability after key exchange was lower than at SIPit 19.

There was only one RTP over DTLS implementation present.

Anyone doubt that we still have a good bit of work to do??

As I mentioned, the full survey results are definitely worth a read if you are interested in SIP interoperability.

Digium creates Asterisk security portal

Given recent announcements of security fixes in Asterisk, it was great to see: 1) Kevin Fleming from Digium posting Asterisk security advisories to the VOIPSEC mailing list; and 2) the creation of a security web page at:

Kudos to Kevin and the others at Digium for making this security information more readily accessible.