Monthly Archives: December 2007

Blue Box Special Edition #22: SIP and NAT Traversal

MD_bluebox157-2.jpg Blue Box Special Edition #22 is now available which explores and explains the details around SIP and NAT traversal. In this interview I sat down with Dr. Jonathan Rosenberg, a Cisco fellow and author of a wide range of RFCs and Internet-Drafts related to SIP to talk about SIP and NAT traversal. We explore what the problem is, how ALGs and SBCs attempt to solve the problem and how the IETF has looked to address the issue through first STUN, then TURN and now finally ICE. I think you’ll find it a very educational and informative session.

On a similar note, you may also be interested in Blue Box Special Edition #20 where I sat down with Cullen Jennings to talk about overall security issues with SIP. These two podcasts together give you a solid overview of the current security issues with SIP.

Technorati Tags:
, , , , , , , ,

Blue Box Podcast #72 posted – Asterisk vulnerabilities, Skype and the German government, VoIP security news and more

MD_bluebox157-2.jpgBlue Box Podcast #72 is now available for download. In this episode, Jonathan and I discuss the Asterisk vulnerabilities that came out at the end of November, the German government’s interest in installing spyware in order to record Skype calls and a number of other VoIP security news items as well as listener comments.

Technorati Tags:
, , ,

Trixbox contains “phone home” code to retrieve arbitrary commands to execute?

UPDATE: A summary of the Trixbox “phone home” issue has been posted, complete with code samples.

Over the weekend, Than Taro, posted to the VOIPSEC mailing list news about the Trixbox IP-PBX product containing code to retrieve commands to execute locally. Than writes:

A set of scripts were recently discovered in the trixbox line of PBX products, which connect to a remote host every 24 hours, to retrieve an arbitrary list of commands to be executed locally. These scripts were added under the guise of submitting ‘anonymous usage statistics’, however,
with the help of DNS pollution, or malice on the part of the sponsoring
company (Fonality), all up-to-date versions of trixbox could be
instantly disabled, or worse.

According to trixbox Community Director, Kerry Gerrison, a new version of trixbox will be available by December 18th which will allow you to ‘opt-out’ (meaning that it will still be enabled by default) of this behavior.

Than points people to these two links to read more:

Trixbox if you are not aware, is the former “Asterisk@Home” product that basically adds a layer of management and applications on top of the open source Asterisk PBX. After it was purchased by Fonality they have been working hard to compete against Digium for the hearts and dollars of companies looking to move to Asterisk-based solutions.

I’m traveling right now and and haven’t been able to thoroughly read the posts. On first glance, though, it sounds like the functionality that Trixbox includes (and, it seems, has included for quite some time) is what is quite common among “managed” commercial products – and even products that are not “managed” do often have these types of functions… but usually there is some option to disable it! (And the better ones, in my opinion, start with it disabled and let you choose to join in their program.) Such collection of statistics and information is incredibly useful to a product manager, so I understand Trixbox’s motivation.

However, it would seem, certainly from the tone of Than’s post to VOIPSEC, that Trixbox was not entirely clear about what they were doing. Given that, it’s only natural that some people would attribute malicious aims to the code when it was found in the code base. It’s not clear to me yet how transparent Trixbox was about what they were doing (it sure sounds like they were not). Trixbox’s Kerry Gerrison does state in the forum:

We certainly could have gone to any amount of effort to hide this and we fully disclosed our intention to collect bits of data well over a year ago with the release of trixbox 2.0. The engineers asked how how covert we wanted it to be and Andrew and I insisted on several key points:

a) Its easy to disable
b) It is not compiled code so anyone can clearly see what the code is doing
c) It could not take up any appreciable system resources
d) Collection had to happen at off-hours so as to never impact a system
e) We would not hide any components of it from the users

All of our scripts that we write are completely open code that we welcome the community to go through and be the check and balance against anything we do and we have always been like that. The really hard core guys here had some really sneaky ways to implement this that nobody would ever find or be able to disable but that went completely against most of the directives we laid out so we did it in the most basic means possible so that people could disable it as well as review the code.

The data sent from a system is less than 1k.

So it would appear that they have at least been open about it in the code. Perhaps they did, though, need to be a bit more open in discussing publicly what they were doing in advance. I don’t know… I need to read more to see what they did do. (The forum thread is very long.)

The one other worrying aspect of what is being reported is that the code would retrieve commands to be run on the local system. Some of these systems that I have seen in the past simply package up statistics locally and then send them in to some central host for analysis. There is no retrieval of commands to be run. Now, I have seen “remote management” interfaces that did retrieve commands for local system to run, but for what I would think are obvious reasons, those interfaces were highly secured and encrypted so that the command channel could not be compromised by an attacker. I will be interested to read about how secure – or not – this command channel was made by Trixbox. Kudos to the Trixbox folks for reacting and putting out a new version this week allowing the functionality to be disabled. (Although it would be nice if it could be disabled by default.)

All in all it’s a good reminder that as we are in this online world where applications can indeed “phone home”, you do need to understand whether or not your apps are connecting back to servers and what they are doing when they do so.

Pointers to any audit methodology for forensic analysis of VoIP systems?

At a recent conference where I spoke about VoIP security, a researcher at a government agency (and if I recall correctly, also a part-time professor at a university) approached me afterward and asked if I knew of any “audit methodology” for analyzing VoIP systems, especially from a forensic point-of-view. I did not… but thought I’d ask the question here?

Is anyone aware of any work to define a methodology for auditing VoIP systems?

(If not, it sounds like a great project for a group like VOIPSA to take on. Anyone interested in heading up such a working group?)

Vietnam’s dissidents turn to VoIP to escape government censorship

Fascinating article last week in Canada’s Globe and Mail titled “Cyberdissidents weaving along new path” that discussed how dissidents in Vietnam are turning to VoIP:

Just last month, Vietnam’s supreme court sentenced two so-called cyberdissidents to terms of three and four years in jail for distributing “anti-government propaganda” on the Internet and in print. But Mr. Quan and others like him have found a way to dodge the government snoops: VoIP, or Voice over Internet Protocol, is harder to monitor than other means of communication. Using VoIP services such as Skype or Paltalk that let users make phone calls over the Internet, dissidents can discuss plans, organize meetings or circulate petitions out of the hearing of government agents – or so they hope.

Now I’m not going to turn this into a “poli-blog” and weigh in on the pros or cons of Vietnam’s government. But it is to me an interesting illustration of the potential usage of VoIP by those people concerned about being monitored by their government. There is a natural tension between those wanting privacy from government monitoring and the government’s desire to listen in on those it views as threats. (And the similar example could be made in other countries for criminals (or terrorists) seeking to hide their conversations from government agencies set on finding them.)

It was also intriguing to see how the dissidents made use of the “multi-modal” communication available in Skype and other clients:

Just to be sure the authorities aren’t listening, Mr. Quan often uses a VoIP feature that lets users type messages as they talk. By typing half of what he wants to say and speaking the rest, he hopes to throw off police who may have tapped into one or the other. Mr. Quan gives an example: “[Speaking:] I will meet you [typed:] at the Hanoi club [spoken:] at 2 p.m.”

Also interesting to see that the aging dissidents see VoIP as a way to connect with the younger generation of Vietnamese.

Anyway, I found the article an interesting view into how VoIP is entering into the age-old battle between governments and those who want to escape government scrutiny.

ISIC for VoIP Phone Stacks

In my last post I noted that it’s a good idea to know how robust your IP phone is to attacks against the stack and mentioned the Targa3 tool for classic attacks. Continuing in this testing approach I’d like to bring up a fantastic tool called ISIC. If you dare to run ISIC, I can almost guarantee will make any IP phone drop dead in its tracks, reboot, show wierd characters on the screen, etc., etc.

Take my word for it, you do not want to run this monster on a production network. To wit, the ISIC page states the following:

“Warning: ISIC may break shit, melt your network, knock out your firewall, or singe the fur off your cat”

A key takeaway of ISIC is that it is not just a single tool, but rather a suite of tools; with each tool (esic, udpsic, tcpsic, etc.) geared toward targeting a specific layer of the IP stack.

Oops… Skype failed to mention this wee minor security update…

B9C2EAA9-B78E-4378-9433-6D6EC2DEC3B4.jpgSkype today announced that there is a serious security vulnerability in Skype for Windows versions older than 3.6.x.216. As noted:

An exploitable memory corruption may occur during the parsing of URIs which can result in arbitrary code execution under the user rights of the current Windows account.

It turns out that this was fixed in the release back on November 15th, but Skype had an “unintentional communication oversight”:

At Skype, we strive to inform the public of vulnerabilities and malware that may affect Skype software. While this particular vulnerability was fixed, there was an unintentional communication oversight and we failed to bring the case to the public’s attention. All we can do now is to apologize.


Thanks for the apology, Skype… and now would be a really good time for any Windows Skype users out there to look at upgrading!

P.S. Tip of the hat to Ryan Naraine’s Zero Day blog where we noticed the item this morning.

Technorati Tags:
, , ,

Toasting VoIP Phones with Targa3

With all of the VoIP tools available it’s easy to forget to test the IP stack of your VoIP phone for stability from classic attacks. With that in mind, a good tool for accomplishing this basic vetting is called Targa3. Written way back in 1999, Targa3 encompasses several attacks such as Jolt, Nestea, etc. to “generate attacks using invalid fragmentation, protocol, packet size, header values, options, offsets, tcp segments, routing flags, and other unknown/unexpected packet values.”

You can grab Targa3 from Packetstorm here. Oh, and happy toasting. 🙂