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:

• http://www.trixbox.org/forums/trixbox-forums/open-discussion/trixbox-phones-home
• http://www.trixbox.org/trixboxs-new-hardware-audting-tool

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.

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.