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.

Many VoIP protocols, including IAX2 and SIP, have a very large allowed character set in the dialed extension, a character set that allows characters that are used as separators to the dial() and the queue() applications, as well as within the dialstring that these applications send to the channel drivers in Asterisk. A user can change the dial options and dial something we should not be able to dial in your system. This article describes the issue in more detail and gives you some help on how to avoid this causing trouble in your Asterisk server.

Olle goes on to explain the issue in more detail and explain about how input from VoIP channels should be filtered before being sent to the Asterisk ‘dialplan’ for processing. He includes a plea for assistance:

We need everyone involved to pump this information out in all the veins that runs through the Asterisk eco-system. Audit your dialplans, fix this issue. And do it now. Everyone that runs a web site with dialplan examples – audit your examples, fix them. Everyone that has published books – publish errata on your web site. Please help us – and do it now.

Olle’s article goes into much more detail and offers suggestions for what you can do to protect your system. If you are an Asterisk administrator, it’s definitely an issue you should investigate and act on.

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

http://www.krebsonsecurity.com/2010/01/fbi-investigating-theft-of-500000-from-ny-school-district/

http://www.wired.com/threatlevel/2009/12/feds-warn-small-businesses/

Although the targets here were school districts one can easily see the correlation to the SMB space when thinking of resources available and operational processes within an organization. How long would it take for an SMB to notice that the transfer or payment of funds was not proper and then correct it? How much can they afford not to recover? As noted in one article the red flag was raised by the bank and not the customer! One wonders how many SMB’s would receive the same amount of diligence from their banking institutions.

So how does this tie in with VoIP security? Even in these tight economic times unified communications has continued to increase in deployments due in part to operational improvements and cost reduction promises. Growth in UC deployment means increased deployments of SIP trunking and SIP trunking usually means port 5060 is open in your firewall and network. Now we see that this open port can possibly be used as a probe point to other servers and services within the network through the firewall. Its time for SMB’s to think of more than just a firewall and anti-virus (as most SMB’s do) as protection enough from threats.

http://www.theregister.co.uk/2010/01/06/web_based_firewall_attack/

We can understand the criminal intent to go for the ‘big score’ (against the big institutions) but these attacks should remind all to never underestimate the lure of easy cash wherever it may be or whatever the amount – never think your business is ‘not large enough’ to be a target. It’s not the size of the prize but the ease of exploitation that makes you a target.

Growth of SIP trunking:
http://www.infonetics.com/newsletters/newsletter-CRS-Enterprise-Voice-SIP-Trunking-Survey-102709.html

Shodan bills itself as a “Computer Search Engine” and some folks have raised questions about the impact, ethics, etc. So far, Shodan has remained under-the-radar, but I expect we’ll see more coverage and questioning of what value-add this service provides to security efforts.

A few simple searches of Shodan will provide the reader more insight of the capabilities of this service. Bear in mind that searches can get much more specific. Also, Shodan is growing, and it’s worth re-visiting the site to gain better perspective of updates.

Example searches:

1. VOIP — http://shodan.surtri.com/?q=voip
2. Nortel — http://shodan.surtri.com/?q=nortel
3. Mitel — http://shodan.surtri.com/?q=mitel
4. .mil — http://shodan.surtri.com/?q=.mil
5. SCADA — http://shodan.surtri.com/?q=scada

My one bit of feedback to the folks at Digium would be that their advisories do not provide any information about mitigating circumstances. (Would be great if they could add such a section.)

In this particular case, I confirmed with Digium that this advisory only affects systems that allow public unauthenticated calls over an IP connection. So Asterisk systems that are only used for PSTN connectivity – or only allow authenticated connections/calls – are not vulnerable to this attack. My Digium contact indicated:

The attacker would have to be capable of negotiating a RTP stream and then sending the Comfort Noise payload within the stream to crash the system.

He also indicated that IAX connections are not affected as they do not use RTP streams. So basically you are only vulnerable to this attack if you allow anyone to connect to your Asterisk box over an IP network presumably using the SIP protocol.

If you aren’t allowing those connections, it’s probably still good to upgrade… but you are apparently not vulnerable to the specific attacks outlined in the advisory.

Jonathan and I have decided that we won’t be returning Blue Box to its original weekly schedule. We’re not sure, honestly, how often we’ll put out new episodes… we will see how schedules and such align. In the meantime, BBP 86 is up there for those who would like an update.

Thanks to all of you who have continued to listen and who also sent notes to us while we were offline wondering how things were going. Thanks.

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

For those not familiar, the story began back in June 2006 with the initial reports that Pena masterminded a scheme to sell phone service and then running that service over other providers networks. We covered this at some length back in Blue Box Podcast #31. Then, in September 2006, Pena fled the country and was a fugitive abroad until he was nabbed in Mexico in February 2009.

Meanwhile, his co-conspirator Robert Moore was convicted and sent to jail. I had a chance to interview Robert in conjunction with the Voice Report folks as part of their Telecom Junkies podcast (also linked here) which provided some insight into how the attack took place.

The good news now is that Pena is back in the US, in jail, and to be arraigned sometime today. Good to see this work by the FBI and other agencies.

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

However, if we take a look at some of the VoIP clients offerings available we notice that a few of these clients have the ability to receive incoming calls, even when the software it self is not running.

At first sight this seems to be a Good Thing – however, there are severe security implications by doing this. Users will in fact willingly, put them self under a man-in-the-middle attack.

3rd party proxies

Before continuing, let me use two pretty well known mobile applications as an example: Fring and Nimbuzz. Both applications support a whole slew of different means of communication – but if we take a closer look at the physical size of these program it become quite apparent that these applications does not have all the code for all the various services they let the user access.

The general rule is that these client providers will act as a proxy between the users client and the users service provider. Basically, when setting up your Nimbuzz client for SIP usage – it is not the client that will connect to your SIP server, but a server in the Nimbuzz network.

So in effect, Nimbuzz and Fring does keep a copy of your SIP credentials. It is unclear if they store the credential when the users client is not online.

SIP and the Apple Push Notification Service (APNS)

This is the new kid on the block. For quite some time now, the iDevices have had the ability to receive Push Notifications. This is something that could be of great use, and Apple has on numerous occasions stated how this technology can be used.

In practice a service provider can use the APNS to send out notifications to a specific iDevice. As far as I know, Apple has put no restriction on the content of such notifications.

What is happening behind the scene, is that SIP credentials stored in the iVoIP Client are transferred over to the client providers infrastructure (CPI). A server in the CPI will then re-register itself as a SIP client to your SIP server, with your SIP credentials.

When an incoming calls are present, the SIP signaling will be sent to the server in the CPI – and this server will then send out a Push Notification over the APNS netowrk, ending up in your iDevice. When the device receive the notification, it will display some information to the user. If the user confirm the notification – the VoIP Client is started, registering to your SIP server and will then accept the call.

In my opinion, giving away your SIP credentials to a 3rd party you have no control of, seems like a very bad idea. I also suspect that most service providers Acceptable End User Policy prohibit a user to give away his SIP credentials.

None of the companies providing 3rd party proxy solutions as their core business have, as far as I have found, publicly shown any documentation from a 3rd party stating that they do have a well funded security policy that is being upheld.

I do suspect that these companies are prime target for Black Hat telecom hackers. Just getting access to thousands of thousands SIP accounts which can be resold IS a tempting target.

Possible solutions

The easiest way out of this mess if of course not to enable the client to use the APNS network. However, this defeat using a iVoIP Client efficiently.

A much better solution would be for the CPI to offer a WebService solution.

When a call comes into the switch/PBX, the switch could then do a WebService call to the CPI, and the CPI would then issue the Push Notification message over the APNS.

This is a clean and efficient solution that will have the same result for the end user, without compromising security: A Push Notification message of a incoming call – enabling the iDevice to start up the iVoIP Client and let the client handle the call.

Another solution could be to let companies with their own APNS agreement, send out their own Push Notifications. I have not spent too much time with the rules that Apple have for the APNS, so I can not say if this is in fact possible.

That said, occasionally a Windows rootkit surfaces that is so mean, nasty and downright cool, that it becomes a must-know. Such is the case with the newest release of Stoned Bootkit. Be sure to go to their site and check it out, along with the paper, but here are a few highlights:

Understanding the threats that Windows rootkits like this pose to VoIP security, especially on end users, is key.

Of the many PHS 6000 features, the device also supports two-way video conferencing between patient and caregiver. As this communication takes place over the broadband connection, it’s reasonable to assume that some sort of VoIP software is in place. Of course, details at this point are thin, and it’s even hard to get a real handle on what the PHS 6000 operating system really is, with some reports indicating Microsoft Windows XP, and others indicating a embedded Linux derivative. Still, it looks like there is a VoIP stack, and it’s likely SIP-based.

Clearly, the importance of the security of devices like the Intel PHS 6000 is apparent. And with the growing interest and funding towards cost-reduction and tele-health, we can expect to see these types of devices deployed widely. But what of the security posture? Sure, there’s boasting of encryption for the connection, but features like SSL mean little in the face of real attacks and vulnerabilities — think SSL encryption downgrade attacks, spoofing and man-in-the-middle vectors to start.

To get the word out, I’ve started a LinkedIn group called MedSec to get together like-minded, talented security people with an interest in medical device security. I’ve been chumming the waters with this approach in the hopes that the right people with the right connections conduct proper security evaluations of this PHS 6000 device, and it’s back-end management system as well. Of course, if approached, I’m interested in some hand’s on time too