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.