Tag Archives: VoIP

Is The “VoIP” in “VoIP Security” Still The Right Term?

VoipqShould we still be talking about “VoIP security”? Or should we be using some other language?

Back when we started VOIPSA in 2005, “voice over IP (VoIP)” was the term we all were using, but as we look at what kind of activities come next, we’re starting to wonder if we should be talking about “communications security” a bit differently.

For starters, in the past 8 years we’ve moved far beyond simply “voice” into video over IP, text messaging over IP, data sharing over IP… all within a single communications session. Is that still “VoIP”?

Beyond that, we’ve seen a range of other terms coming into usage, including:

  • unified communications (UC)
  • real-time communications (RTC)
  • cloud communications
  • IP communications

and many more. Plus new technologies are out that have pushed “VoIP” beyond its traditional proprietary protocols and the open standard of the Session Initiation Protocol (SIP). We’ve seen the strong emergence of XMPP (Jabber) and its related “Jingle” protocol. We’ve seen the explosion of interest in the WebRTC / RTCWEB protocols and tools.

Are all of those “VoIP”? Or are they something more?

Should we be talking about…

  • UC security?
  • real-time communications security?
  • IP communications security?

Or perhaps just plain old “communications security”? (or is that too generic?) I’ve seen some people talking about “SIP security”, but now that is specific to a single protocol.

Or is “VoIP security” still an okay term to use?

What do you think? What do you use? What do you hear vendors and others using? How should we be talking about securing all these many ways we have to communicate now over IP networks?

Please do let us know either as comments here or out on social networks. (Thanks!)

VoIP Fraudster Pleads Guilty to $4.4 Million USD Theft of Services from AT&T, Verizon, Others

FbiNews out of the U.S. Federal Bureau of Investigation (FBI) last week was that a New Jersey man pled guilty to charges that he and his co-conspirators stole over $4.4 million USD of VoIP services from a range of VoIP service providers including AT&T, Verizon and many others.

Reading through the FBI news release, the scam really has nothing to do with “VoIP security”, per se, and everything to do with “social engineering.” Essentially, the group managed to appear to be a legitimate business so that VoIP service providers would let them resell their services to businesses. They then resold that service and pocketed the money without ever paying the service providers.

From the news release, it seems to have been a rather extensive scam:

To make it appear as if the shell companies were legitimate VoIP wholesalers and to induce the victim providers to extend credit to the companies on favorable terms, Tonangi and his co-conspirators took several fraudulent steps, including establishing fake business addresses for the shell companies at prominent New York locations, including the Empire State Building.

The co-conspirators also used Internet-based answering services that purported to connect callers to the shell companies’ various departments, such as accounts receivable and marketing, but really connected to cell phones controlled by the co-conspirators.

Tonangi and his co-conspirators created shell company e-mail accounts in the names of non-existent employees for communicating with victim providers; websites that contained false information, such as the names of non-existent employees and the companies’ fabricated qualifications to serve as VoIP wholesalers; and aliases to negotiate the purchase of VoIP services.

They also fabricated year-end financial reports that bore the logo of a national accounting firm in order to give the appearance that the shell companies’ financial reports had been reviewed by that firm.

When the victim providers sold VoIP services to the shell companies on credit, Tonangi and his co-conspirators would “bust out” the account by causing the companies to use substantially more VoIP services than the companies had been approved to buy in such a short period of time. The co-conspirators would do this over weekends and holidays so that the providers would not notice.

When the invoices for the services came due, the co-conspirators would send fake wire transfer confirmations via e-mail or submit small payments to keep the victim providers from cutting off service.

If victim providers sued or threatened to sue the shell companies, Tonangi and his co-conspirators would respond in legal pleadings or letters that they prepared in the name of a non-existent attorney, Frank Soss. Tonangi and Bhambhani created and used a fraudulent United States passport in the name Frank Soss by downloading and altering a exemplar passport image and photograph from the Internet.

Given the degree of subterfuge undertaken by the group, I’m not at all surprised that they fooled numerous companies into extending credit for VoIP services. When you are doing due diligence on a new customer, you would explore many of the avenues that these folks seem to have covered.

It’s not clear from the news release or any other information I’ve seen online what if any VoIP technology was used here but given that the group was acting as a legitimate business they didn’t need anything very sophisticated. Many software and service options would have met their needs.

It’s good to see the FBI successfully cracking this fraud ring… sadly I’m sure there will be others as we see the increased usage of VoIP across the industry.

P.S. Thanks to J. Oquendo in the VOIPSEC mailing list for alerting us to this news from the FBI.

Voipscanner.com – a hosted service for scanning IP-PBXs

VoipscannerThis week at the SIPNOC event near DC, an attendee asked if I knew of any hosted services that would scan the external interface of a network to see if the VoIP services were secure. He sells SIP connectivity to small businesses, many of whom typically have purchased an IP-PBX from somewhere like a retail store and have minimal IT expertise. He wondered if there was a service he could refer these small businesses to so that they could check the security of their system. Basically something for VoIP along the lines of hosted services like “Shields Up” that will check the security of your firewall.

I didn’t know of such a service, but posted the question to the VOIPSEC mailing list. A couple of people contacted me privately about some services in the works, but then someone did pass along a link to a public service available now:

https://voipscanner.com/voipscanner/

Now, I’ve not used this service but I’m certainly aware of Sandro Gauci and a number of the different tools he has been working on, including SIPVicious and VOIPPACK. After watching his short video and seeing the sample report, this definitely looks like an interesting service.

Of course, with any hosted service my security paranoia is heightened and I want to know what will be done with my data. Will the scan of my IP-PBX be recorded on the Voipscanner.com servers? Will a copy of my report be saved there? Basically… can I trust the site? In looking through the terms of service after you click the graphic to “apply” for access I didn’t see any wording around this… but it’s also Friday and I’m tired… I could have missed it.

Anyway, this service is out there and for those of you comfortable with using such a service it may be useful for you. If you know of other similar services I’d also love to hear about them.

Webinar Tomorrow: Securing Next Generation IP Communications Systems

International Legal Technology AssociationTomorrow (Friday, December 17, 2010) I will be participating in a webinar entitled “Deployment of Next Generation IP Security” for the International Legal Technology Association, an industry organization looking to “maximize the value of technology in support of the legal profession“. It should be fun and I’m expecting that the questions I’ll receive may indeed be a bit different from doing a webinar to security professionals or enterprise IT staff.

The abstract is as follows:

Deployment of next generation IP-PBXs and Session Initiation Protocol (SIP) are the new standard. AT&T has gone on record stating POTS is dead. So are these new technologies safe? How can you insure a safe and secure environment? Recently in one such sophisticated attack the attacker hacked into the SIP provider and bounced off the IP-PBX which re-directed the calls to a Michigan number which then re-directed the calls to International Countries of known terrorist activity thus racking up over $12,000 in toll-fraud charges. Could this happen to you? This Webinar will look into the following:

  • How to properly choose a SIP provider
  • Voice encryption with emphasis on soft phone deployment on laptops, wireless and Wi-Fi devices.
  • User Authentication via third party certification (Today anyone can download an app or purchase a calling-card which allows them to display any Caller ID Number)
  • Remote User and Voice RTP Stream protection (This is a known VOIP Vulnerability)

Securing your IP-PBX can be simple once you understand the issues. It is then up to you as to what level of protection you which to deploy.

If you are interested in offering a similar webinar to your organization, be it a company, nonprofit or industry group, please feel free to drop me a note, as I’m always open to participating in such sessions (and have done so many times in the past).

And if you are a ILTA member, I look forward to answering your questions tomorrow!

If you found this post interesting or helpful, please consider either subscribing via RSS or following VOIPSA on Twitter.

Facetime, Apple, and VoIP

Very interesting news:  Apple’s new iPhone4 application, Facetime, is a VoIP and IP Video application using SIP signaling and RTP media.  Security researcher and SANS Instructor Josh Wright has posted a very interesting and detailed analysis of the Facetime application on Packetstan, a new blog developed by his other SANS and InGuardians colleagues .  A couple of quick summary points from Josh’s analysis and a quick look at the phone that we have done thus far:

  • iPhone Facetime client doesn’t use SIP REGISTER for authentication
  • Uses STUN for NAT Traversal and resolving the remote callee and called party’s IP address of each iPhone
  • After the remote party’s IP address has been resolved, SIP INVITE and MESSAGE packets are exchanged directly between iPhone devices
  • Cleartext SIP and RTP
  • RTP video appears to use the H.264 video codec, and audio appears to use the AAC-LD codec (the same audio codec used in Cisco TelePresence).
  • FaceTime uses XMPP to authenticate each iPhone to an Apple Jabber server, using TLS and mutual certificate authentication.

Josh and I were discussing this the other day because he was trying to use the ‘VideoSnarf’ tool in order to re-construct the H.264 encoded media packets.  The codec does appear to be H.264, but with some slightly modified reserved fields.  Right now this isn’t working, but we hope to have an updated version of VideoSnarf working together with Facetime traffic in the near future.

This is so interesting because it is the first SIP client on a widely deployed consumer Smartphone device developed and supported by a vendor such as Apple.  I think it signals that we are going to see more of these applications – these are exciting times.  It will be interesting to see how other vendors follow up soon with 2-camera video clients on Smartphones using VoIP protocols, taking the lead from Apple.  I am sure many others will be taking a closer look at Facetime, and the attack surface area here for potential exposures are very interesting, as well as the potential security measures that can be applied in order to protect Facetime traffic.

Attacking the Crown Jewels through VoIP

The security weaknesses of VLANs have been known for years.  Recent case studies have highlighted the potential risk of using Voice VLANs together with VoIP in an infrastructure absent of properly configured security controls.  While visiting Europe just recently, I was reminded of this issue for a couple of reasons.

The British Crown Jewels

Firstly, I saw the magnificent British Crown Jewels in display.  They are quite impressive.  They are arguably the most valuable items in the world possessed by a sovereign state, and obviously need to be properly protected.  It really got me thinking about the origin of the term “Crown Jewels” and how the industry has used this term to refer to protection of a company’s most valuable and precious IT assets and data.  We talk about protecting against the theft of these “Crown Jewels” – a company’s IP, trade secrets, or other mission critical data.  How to protect and defend the “Crown Jewels”?

Theft of the Crown Jewels!

Hotel VoIP Deployments

After seeing the Cullinan I diamond and other precious jewels, I stayed in a hotel in Stockholm that had IP Phones deployed in guest rooms, which had me thinking again about how attackers could access a company’s IT “Jewels” from a physically unsecured area.  A quick and passive view of the IP Phone network configuration showed that this network was most likely vulnerable to the aforementioned VLAN Hop vulnerability.  I’ve been seeing an increasing amount of Hotel VoIP deployments in the last year exactly like this.

Both of these items reminded me of how easy it is for a would-be attacker, sitting in the comfort and privacy of their hotel room, to steal a company’s most valuable trade secrets and data through VoIP, in the right scenario and when the environment is not properly protected.  We’ve seen this before in production environments, in authorized security assessments.  I wanted to reach out to the community and share this with you, and see what others are seeing as well.  I’ve roughly seen 1 in 3 hotels in the past year have VoIP deployed in the guest rooms.  I am curious as to whether others are seeing a similar trend.  What other UC business applications are you seeing deployed in physically remote areas, and how are they being used?

Trunking VoIP to Physically Isolated Areas

When VoIP networks are propagated through trunk ports to physically isolated remote locations that are still under the administrative domain of the same organization, the risk increases that a VLAN Hop into the Voice VLAN can result in unauthorized access to corporate network resources.  Resources that were not intended by the system designers.  I’m making generalizations because every network is different.  But the most common configuration I am seeing takes place because the IP Phones normally need a range of TCP/UCP ports open into the call servers, and the call servers are centrally hosted on the corporate data network.  Sometimes the firewall doesn’t properly implement the policy of least privilege for only permitting operational IP Phone traffic and denying all other traffic.  The best example of a physically remote location that comes to mind is a Hotel room, but I’m sure there are other good examples.  Hotel VoIP deployments with wired ethernet offer benefits to the user such as guest VLAN Internet access from the PC port of the IP Phone.  But if you think about it, it offers the perfect backdoor attack vector into the internal network.  Privacy and seclusion.  An attacker can spend as much time as they please, evading detection and slowly discovering the network.  Each time I see this, it makes me wonder the extent to which this vulnerability is getting exploited in real life, but not being publicly disclosed.  We’ve seen how well publicized CHD / data breaches of the PCI DSS have taken place over wireless networks – I wonder if and how long it will take before this happens over a VoIP infrastructure deployed to a physically remote location which is trunked, unprotected into the internal network where mission critical servers are hosted.

Some would say that this is a network infrastructure “firewall” mis-configuration issue and not a VoIP issue.  They are right.  But you could also argue that this issue opens up only when you deploy VoIP with QoS and VoIP is so tightly integrated with the network and QoS.  The VLAN Hop also enables UC attacks against not only the IP Phones, but the call server as well.  For VoIP to be operational, those TCP/UDP ports between the IP phones and call server must always be permitted, even through a properly configured firewall.

Death of the Voice VLAN

Some have talked about the death of the Voice VLAN and others have questioned the relevance of Voice VLANs to UC Security.  In my opinion, VLANs were never intended for security.  They were designed for one thing:  Broadcast Domain isolation, resulting in improved performance and host management.  Then the “Voice VLAN” came about – a special access port feature for VoIP that enables the easy application of QoS and IP Phone provisioning.  Brilliant, if you really think about it.   Voice VLANs were also never intended for security features.  However, some started seeing it this way because, by default, a PC wasn’t a member of the Voice VLAN, and Voice would have the highest priority on the network in the event of a malware outbreak on the “data” access VLAN, and so forth.  This is still QoS – not security.  A network with properly configured QoS at layer 2 or 3 doesn’t distinguish a virus outbreak from an extremely chatty file transfer application.  In either case, VoIP will take the highest precedence through the network.  Then we started hearing “VLAN is not a security measure” and now we are coming back full circle.

Voice VLANs are never going to die off due to their perceived security limitations.  In fact, they are brilliant .  They make it easier to deploy VoIP and other new and promising UC applications, like IP Video.  Applications like IP video that are heavily reliant on QoS.  This helps us all.  The best thing we can do is recognize their security limitations and that they were never intended for security to begin with.  Which brings me to my final point.

Why?

Many of you reading this are already well aware of this.  But that doesn’t necessarily signify that others who deploy or own VoIP do as well.  Just the other day, I had a conversation with a Network Engineer who had deployed VoIP for a major US sports stadium.  This person believed that the IP Phones configured in the luxury suites were protected against VLAN Hop just because they had deployed MAC Address filtering on the switch ports.  We all know that Voice VLAN Hop and MAC Address spoofing can be automated via myriad tools.  But still, that doesn’t mean everyone else does.

I’m writing you today to ask for your help as  VoIP Security professional in spreading awareness about this issue.  I am open to hearing what you are seeing (specifically vendors and configurations in remote areas, and how the application is being used) or any other friendly comments or suggestions.  This is an area of research and interest.  Please email jostrom {at} viperlab {dot} net.

VoIP Fraudster and Fugitive Edwin Pena pleads guilty

Updating a story we have literally been following for years ever since it broke back in July 2006, the FBI recently issued a news release indicating that Edwin Pena pled guilty in what we have been calling the “Pena/Moore VoIP fraud case”. From the news release:

Edwin Pena, 27, a Venezuelan citizen, pleaded guilty before U.S. District Judge Susan D. Wigenton to one count of conspiracy to commit computer hacking and wire fraud and one count of wire fraud. Judge Wigenton continued Pena’s detention without bond pending his sentencing, which is scheduled for May 14.

The news release goes on to provide a summary of what Pena admitted:

At his plea hearing, Pena, who purported to be a legitimate wholesaler of these Internet-based phone services, admitted that he sold discounted service plans to his unsuspecting customers. Pena admitted that he was able to offer such low prices because he would secretly hack into the computer networks of unsuspecting VOIP providers, including one Newark-based company, to route his customers’ calls.

Through this scheme, Pena is alleged to have sold more than 10 million minutes of Internet phone service to telecom businesses at deeply discounted rates, causing a loss of more than $1.4 million in less than a year. The victimized Newark-based company, which transmits VOIP services for other telecom businesses, was billed for more than 500,000 unauthorized telephone calls routed through its calling network that were “sold” to the defendant’s unwitting customers at those deeply discounted rates.

Pena admitted that he enlisted the help of others, including a professional “hacker” in Spokane, Washington. The hacker, Robert Moore, 24, pleaded guilty before Judge Wigenton in March 2007 to federal hacking charges for assisting Pena in his scheme. Judge Wigenton sentenced Moore to 24 months in prison on July 24, 2007. At his plea hearing, Moore admitted to conspiring with Pena and to performing an exhaustive scan of computer networks of unsuspecting companies and other entities in the United States and around the world, searching for vulnerable ports to infiltrate their computer networks to use them to route calls.

Pena admitted that rather than purchase VOIP telephone routes for resale, Pena—unbeknownst to his customers—created what amounted to “free” routes by surreptitiously hacking into the computer networks of unwitting, legitimate VOIP telephone service providers and routing his customers’ calls in such a way as to avoid detection.

After receiving information from Moore, Pena reprogrammed the vulnerable computer networks to accept VOIP telephone call traffic. He then routed the VOIP calls of his customers over those networks. In this way, Pena made it appear to the VOIP telephone service providers that the calls were coming from a third party’s network.

By sending calls to the VOIP telephone service providers through the unsuspecting third parties’ networks, the VOIP telephone service providers were unable to identify the true sender of the calls for billing purposes. Consequently, individual VOIP Telecom providers incurred aggregate routing costs of up to approximately $300,000 per provider, without being able to identify and bill Pena.

According to the Complaint, in order to hide the huge profits from his hacking scheme, Pena purchased real estate, new cars, and a 40-foot motor boat, and put all of that property except for one car in the name of another individual identified in the Complaint as “A.G.”

So it looks at long last we can end this particular chapter in the story of VoIP security. I suppose we may mention whatever jail time he gets in May… but at this point he has pled guilty and admitted what he has done.

The lesson for security professionals in this whole episode really came out of the interview I participated in with Robert Moore, mostly that you need to remember “IT security 101” and use strong passwords, ensure your systems are patched appropriately, etc., etc., so that your systems aren’t used in a scheme like this!

In any event, this particular story seems to be drawing to an end…

If you found this post interesting or helpful, please consider either subscribing via RSS or following VOIPSA on Twitter.

New Threats, Old Friends

On a lightning visit to the Infosec show in London, I chanced to meet with Ari Takanen of Codenomicon (fuzzing and quality assurance experts). Ari has a new book out: “Fuzzing for Software Security Testing and Quality Assurance”, from Artech House, available at Amazon.com and (as they say) all good bookstores. Of course, just because there’s a credit crunch doesn’t mean that security is any less of a problem, and it doesn’t mean that software defects are any the better. It sounds like Codenomicon have a pretty good market niche.

Enigma Machine

Facetime were talking about their new Unfied Security Gateway. This appliance goes beyond URL blocking and reporting, and implements reporting for VoIP and Skype, and the whole range of IM and P2P applications. In addition they have some pretty granular tools for finding out what the usage of social sites like Facebook (FB) and Myspace, and the resulting bandwidth usage might be. You can even drill down into the subsections being used (apps, music etc), which will be useful as increasingly FB is used for legitimate messaging and networking purposes in business. Facetime’s “special guest” on the stand was an original Engima encryption device, brought down from Bletchley Park (a.k.a “Station X”), the UK’s premier code-breaking museum. This is a refurbished and fully working Enigma, and on the Facetime stand they were even allowing us to have a go. I can report that it is satisfyingly mechanical to use.

AEP were also there showing some high-grade encryption equipment for enabling remote sites with access to secure systems. Law enforcement and government customers have a legal duty to protect the data that they handle, which and even remote users (or temporary sites) must protect data from snooping. Data at rest is a particular risk, and UK government agencies have embarrassingly lost large numbers of laptops and pen drives in recent years. It’s safer to leave the data in the secure site (rather than the USB stick) and access it over secure links when needed. The AEP solution fits into a laptop bag, and enables a team of people to share secure data and VoIP links to a central site, routed over any convenient satellite, 3G or WAN links.

The Infosec show is still on today and tomorrow at Earls Court exhibition centre in London.

“SIP Trunking And Security” workshop coming up at ITEXPO on February 3, 2009

ITEXPO-East-logo-2.jpgIf you will be in Miami at ITEXPO February 2-4 you are welcome to attend a free “SIP Trunking And Security” session I (Dan York) will be doing as part of Ingate Systems’ SIP Trunking Workshops. The SIP trunking workshops are free to all attendees even if you only register for an exhibit pass.

My session will be 11:15-12:30 on Wednesday, February 3rd, and if you do attend please feel free to come up and introduce yourself (or drop me a note in advance to let me know to look out for you). I’ll be bringing my recording gear, too, and the talk will eventually go out in my Blue Box Podcast feed so you will be able to hear it later.

P.S. If you are attending ITEXPO and your company makes a product or provides a service related to VoIP security, please feel free to let me know and perhaps we can schedule an interview to go out as a Blue Box Special Edition.

Technorati Tags:
, , , , , , , ,

How Aircell is (probably) blocking VoIP phone calls on planes (hint… VoIP Whack-A-Mole)

aircell-gogo-logo.jpgHow is Aircell blocking VoIP phone calls from systems like Skype, SightSpeed and Gizmo? (And how did Andy get through with Phweet?)

Ever since last week’s announcement of the “Gogo Inflight Internet Service” provided to American Airlines by a company called Aircell – and the ensuing coverage in the blogosphere – I’ve been getting asked about how exactly Aircell is blocking VoIP calls. Especially after Andy Abramson was able to make a call using Phweet. Aircell is very clear in the Gogo terms of service that no voice calls are allowed:

No Voice Applications. You will not use any type of voice application (including, without limitation, voice over Internet protocol) without written permission from Aircell.

And early users of the system who tried VoIP calls reported that indeed after about 5 seconds or so, their VoIP conversation was terminated. Repeatedly. They could use Skype, for instance, for IM, but not for voice.

So how is Aircell blocking VoIP? (And how did Andy get through with Phweet?)

Unfortunately, I was a wee bit busy last week when all this was breaking, so it’s taken me until now to come up for air enough to write about how Aircell could be blocking VoIP calls on the planes.

THE BIG CAVEAT

First, I should state up front – I have absolutely NO connection to Aircell, Gogo, American Airlines, etc.. I don’t know exactly how they are blocking VoIP calls but am laying out here how they could be blocking VoIP calls.

[I also feel compelled to say that I personally think it’s silly of Aircell to block VoIP because there will inevitably be people who figure out ways to route around the blocking. I think Aircell’s excuse that they want to block people from talking loudly is also rather lame. I’ve been on long flights where I was trying to sleep and I’ve had two people talking very loudly in the seat behind me or next to me. (And yes, sometimes I’ve asked them to please speak quieter.) Other times I’ve had babies screaming and crying for most of the flight… or other “energetic” children carrying on. No, I don’t really want my neighbor to be in an involved VoIP call but my point is that there are disruptions already. Part of me wonders if there aren’t really more technological issues with doing streaming audio/video, but anyway… that’s their policy and if you want to use their service, you have to agree. You don’t (yet) have a choice in services to use, and you probably won’t.]

LET’S PLAY “SPOT THE VOIP PHONE CALL”

Given that Skype conversations in particular are encrypted, I’ve had several people ask me if this means that Aircell can decrypt Skype calls. How else, they ask, can Aircell differentiate between Skype text chat and Skype voice chat? It’s simple really:

Pattern recognition.

A VoIP call in progress has a distinct profile from a network packet point-of-view. In general, the audio streams of VoIP calls (as compared to the call control/signalling channels) have the following characteristics:

  1. there are a zillion small packets
  2. the packets are sent over UDP versus TCP
  3. the packets are sent using the Real-time Transport Protocol (RTP) over UDP

Now with Skype’s encryption, network software can’t know about the contents of the audio stream, so the software can’t know about my #3 here, but the software can recognize the pattern based on the first two. For other non-encrypted services, the software can very simply look for RTP streams.

Now, why do VoIP systems use a zillion small packets? Typically, a VoIP system will sample the speaker’s voice at an interval of every 10, 20 or 30 milliseconds. Most I’m familiar with seem to go for a 20ms rate. So 20ms of audio is captured, encoded digitally and sent off in an IP packet. The exact size of the IP packet will vary depending upon what codec is used to encode the audio. The standard G.711 packets will be at one size and G.729 will be much smaller. Many of the VoIP streams I’ve captured in network traces have a total packet length of somewhere between 35-70 bytes.

To put that in perspective, understand that an Ethernet packet can have typically a max size of 1500 bytes. And packets sent by various protocols can be even larger and will be “fragmented” into smaller pieces (for instance, 1500-byte pieces) to be moved across the network. [Network geeks: Please give me some poetic license here… I realize I could be more precise, but I’m trying not to completely bore the readers.]

The point is that voice packets are typically tiny in comparison to other packets – and there are a lot of them.

How many? Well, if you take a 20ms sampling rate, that means that you are sampling the audio voice 50 times each second… so that’s 50 packets per second for one audio stream. Almost every voice conversation involves two audio streams (one from the caller, one from the recipient) and so you are looking at 100 packets per second for a typical two-way VoIP conversation.

The reason for this is relatively simple. In a file transfer, you are looking to move a file across the network as fast as possible – but you aren’t necessarily in “real-time”. So you generally will stuff the packets with as much info as you can and push them across the network. With voice, we are making use of the fact that the human ear will deal with some lost audio, and so we are chopping up the audio up into a zillion tiny pieces, tossing them in unreliable UDP packets and hoping that enough get there so that the listener can make sense of the conversation.

Put another way, if I wanted to send you this blog post via snail-mail, I could print it out, stick it in an envelope and mail it to you. That’s file transfer. On the other hand, if I were to chop this blog post up and write each word on a post card and stick them in the snail-mail to you, odds are that enough would arrive at the other end that you could assemble them into something like this post. (With luck, maybe you could even make the post shorter!)

That’s VoIP.

So once you know the pattern, it’s fairly easy to spot the calls. For instance, where’s the VoIP call in this network trace?

voipcall-wiresharktrace-raw-1.jpg

Do you see it? How about this trace with a filter turned on to show UDP in red?

voipcall-wireshare-udpred-1.jpg

Ta da… there’s your VoIP call!

Let’s look at this one in a bit more detail:

voipcall-wireshark-udponly.jpg

There it is… all in UDP… and coming in at about 100 packets per second. And if I look at the actual Wireshark traces, I can see that these 100 packets per second are all very tiny sizes. Many of them are between 37 and 50 bytes.

And this is an encrypted Skype call!

No need to decrypt it. Just see that it’s a steady stream of 100 very small packets per second (50 packets per second each way) all over UDP.

Kill the stream. Block it. Conversation dead. No more VoIP on the plane.

It’s basically the network security version of Whack-A-Mole. See a VoIP stream start up… block it. See another one… block it. See yet another… block it. Whenever anything pops up that meets the profile, stomp on it.

This explains, too, why people could talk for a few seconds and then had their conversations terminated. The pattern has to appear in the network monitoring software. The software has to be sure it’s a VoIP stream and not something else… and then the software can block it.

Now I don’t know for a fact that this is how Aircell is blocking VoIP, but it would be easy enough to do it this way.

GETTING MORE SOPHISTICATED

There are, of course, easier ways to kill the conversations. If the VoIP calls use unencrypted audio streams then it’s incredibly trivial to block. Just block the RTP protocol. Period. End-of-story. Now this does involve a hair more packet inspection in that the software has to look farther into the packet headers to see the protocol type, but again this is easy to do. All RTP is typically used for is streaming audio or video… block it and the “problem” goes away.

They could of course go even further into packets and see if they are Session Initiation Protocol (SIP) packets and if so, what the packets are asking to do. If one endpoint sends a SIP INVITE packet to another endpoint and indicates that an audio conversation is to start, the software could again simply block the impending audio stream. (Of course this couldn’t be done if the SIP was encrypted…)

The software could also simply block ports. Block any usage of port 5060 or 5061 and you would probably kill off most “regular” SIP conversations. (Yes, SIP endpoints can make connections on non-standard ports, but the majority of clients probably wouldn’t.) The challenge here is that some SIP endpoints also would use SIP to set up non-audio communication channels like text chat, so blocking all SIP would also block SIP-based text chat which is probably not desirable.

The software could also block on a service level… if it knew, for instance, the host names or IP addresses for the media servers and consumer services (through which the audio would be sent), the software could block all connections to those media servers.

There’s a whole range of additional layers the network monitoring software could use. Any good system will have a “defense in depth” strategy and make use of many of these different algorithms.

Of course, adding on these layers does require more computing power and will undoubtedly add some latency (even on a microscopic level). It may be that for right now they can simply do the pattern recognition approach and shut down VoIP calls.

SO HOW DID ANDY DO IT?

Okay, so how did Andy make a call using Phweet? Given that this post has already gone on this long, I’ll publish my guess in a subsequent post. The text above should give you enough clues, though… any pattern recognition system is inherently fragile because it depends upon recognizing patterns. So what if the audio packets you are sending don’t match any known patterns? What if (hint) the folks at Aircell forgot to watch all protocols?

Stay tuned for some more network charts in my next post… 🙂

P.S. This is, by the way, why I think that these type of systems trying to block VoIP calls are inherently doomed… someone will inevitably find a way to “cloak” their VoIP calls so that they are unrecognizable or indistinguishable from other data traffic… it’s a cat and mouse game and inevitably people will find ways to get around the watchers…

Technorati Tags:
, , , , , ,

Dan York is Best Practices Chair for the VoIP Security Alliance and writes here and at DisruptiveTelephony. You can follow him on Twitter or identi.ca.