Monthly Archives: August 2007

FYI – I’m speaking on VoIP security at Ingate SIP Trunking Seminar Series Sept 11 in LA (concurrent with Internet Telephony Expo)

image 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.

A trio of new security blogs: Sipera’s VIPER Lab, Tipping Point’s DV Labs… and Microsoft "hackers"

image There have been some new blogs related to security launched lately that I thought we should mention here for readers to check out. First up, VoIP security vendor Sipera Systems launched their Sipera VIPER Lab Blog with the primary author thus far being Sachin Joglekar, their Vulnerability Research Lead (who you can also see in Blue Box Video Edition #1).   Given Sipera’s focus on VoIP security, posts there may be of obvious interest to readers here.  Sachin just put up a good post yesterday, “What we SHOULD have learned from last year’s well-publicized VoIP attack“, about the Pena/Moore VoIP Fraud case, pointing out what we should have learned, but probably didn’t, from the VoIP fraud attack.

image Over at TippingPoint, their Digitial Vaccine Labs quietly launched their “DVLabs Blog” a few months back. While not focused on VoIP security and including a range of different authors, I mention it really because TippingPoint employs VOIPSA Chair David Endler and also Dustin Trammell, a frequent contributor to this blog.   There’s some good info posted on the DV Labs blog, and those of us who enjoyed “SysAdmin” magazine may like Dave’s lament: “Sys Admin Magazine Goes Quietly Into That Good Night“.

image Finally, over at Microsoft, there’s a brand-new blog out called “hackers @ microsoft” which, in its only post so far on August 25th, says “Microsoft employs some of the best hackers in the world and actively recruits them and develops them.  They work on all kinds of projects, whether it be in development, research, testing, management and of course security. ” Yet to be seen is how often people will post there, how many people will post and what the quality of the information will be.    There’s not a direct link (yet) to VoIP security, but given that it is at Microsoft, it may be interesting to follow.  We’ll see.

So there you are… three more blogs to check out.  By the way, if you know of other new blogs related to VoIP security, feel free to leave a comment to this post or drop me a note.  We’re always glad to help promote others who are talking about VoIP security.

Remote eavesdropping vulnerability with Grandstream SIP phone – now slashdotted

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.

Blue Box Video Edition #01: SIP softphone exploit demonstration by Sipera Systems at VoiceCon San Francisco 2007

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?

Video thumbnail. Click to play
Click To Play

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.

It’s official – Skype blames the outage on Microsoft (indirectly)

Well, the official word is out from Skype and it can be summarized: the reboots from Microsoft patches triggered a previously-undetected condition and crashed out network. 

Skype PR staffer Villu Arak writes in “What happened on August 16“:

On Thursday, 16th August 2007, the Skype peer-to-peer network became unstable and suffered a critical disruption. The disruption was triggered by a massive restart of our users’ computers across the globe within a very short timeframe as they re-booted after receiving a routine set of patches through Windows Update.

The high number of restarts affected Skype’s network resources. This caused a flood of log-in requests, which, combined with the lack of peer-to-peer network resources, prompted a chain reaction that had a critical impact.

Okay… I can buy that this type of thing could trigger some kind of chain reaction, but I don’t understand why this month was different than any other month.  For.. what? two or three years now (more?) Microsoft patches have been coming out like clockwork on the second Tuesday of each month.  Each second Tuesday or Wednesday, the millions of computers set to auto-update do so.  All those zillions of computers restart automatically.  Each and every month.  What was so special about this August that was different from every other month?  Was the number or restarts in a short period of time really that much different from other months? Why? Is the issue that there are so many more Windows Skype users than in previous months and years? Was this just the so-called “tipping point” when there were enough Windows Skype users that the normal restarts triggered this chain reaction?

The issue has now been identified explicitly within Skype. We can confirm categorically that no malicious activities were attributed or that our users’ security was not, at any point, at risk.

In other words, it was not a DDoS by Russian hackers, as one rumor had it (which had actually already been dismissed by every security researcher who looked at the alleged exploit code).

This disruption was unprecedented in terms of its impact and scope. We would like to point out that very few technologies or communications networks today are guaranteed to operate without interruptions.

Fair enough statement – if you are looking at data or web technologies… but the PSTN, to which Skype would seem to like to be compared, is designed to operate without interruptions (or with as minimal as possible).  You know, there is this wee little market for “carrier-grade” equipment/software/etc. that is designed to be highly available without downtime.  If a carrier’s network were down for over 48 hours, there would be a zillion lawsuits, intense government inquiries and more.  The carriers that make up what we call the “PSTN” put an incredible effort into ensuring availability.  If Skype wants to play in that game, they have to be ready to play at the same level.

Skype has now identified and already introduced a number of improvements to its software to ensure that our users will not be similarly affected in the unlikely possibility of this combination of events recurring.

Good. We would expect that.

I appreciate that Skype has been as communicative as they have through their blog and heartbeat site.  Thank you, Skype, for communicating – and leaving the comments open.  However, to me the information provided today is still lacking one key piece:

Why were the mass restarts associated with the August 2007 Microsoft updates different from the mass restarts associated with any other month’s Microsoft updates

(Cross-posted from my Disruptive Telephony blog where I’ve been tracking the Skype outage.)

Technorati tags: , ,

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.

How to Break Asterisk

Just to show that VoIP security is not all about SIP, researchers Himanshu Dwivedi and Zane Lackey from iSEC Partners have produced some interesting material on vulnerabilities in IAX, which they just presented at the recent Black Hat conference. IAX (pronounced eeks) as you may know, is a proprietary protocol often used to connect together Asterisk servers for the purposes of call routing. Implementors say that it is simpler than SIP, and also tunnels through firewalls better than SIP, thanks to a ‘VPN like’ approach that tunnels signalling and media together down the same pipe.

iSEC came up with a number of novel attacks including exploiting authentication problems with the use of MD5 hashes; man-in-the-middle and DoS. They have a very nice paper here that describes their attacks in detail, and they have also made available some code (in Python) that you can use for your own experimentation.

Not stopping at IAX, they also had a go at the granddaddy of VoIP protocols, H.323, and have published a couple of attack tools there too. It’s enough to keep you busy all Summer long.

More: Black Hat USA 2007 abstracts
iSECPartners

Administrivia – change in RSS fee URL (but you don’t have to do anything)

FYI, if any of you are incredibly attentive, you may notice that the URL for the RSS feed has changed on the site.  You don’t have to do anything if you are currently subscribed.  The old feed URL works just fine.  We are just now promoting the Feedburner URL so that we can get a better view of stats around subscribers.  The Feedburner feed is basically just a wrapper around the old feed URL, so the content is identical. (If you want to unsubscribe with the old URL and subscribe with the new one, you can, but no need to do so.)