VoIPowering Your Office: Can You Trust Anyone? Part 2

Monday Jan 14th 2008 by Carla Schroder

As the dust settles on the trixbox secret snooping fracas, it appears that the good folks at Fonality have now done all the right things.

Last week we looked at the tempest over the "phone home" script in Fonality's trixbox CE (Community Edition). The problem has been resolved: A workaround was publicized right away, a fix released within a few days, and the current trixbox CE releases incorporate the fix.

I said I would talk to the folks at Fonality, so here we are. I spoke to Chris Lyman, the CEO of Fonality, and Kerry Garrison, the trixbox Community Director, and their security engineers to get their perspective on these events. I also talked to my own little herd of helpful gurus, because while this incident is relatively minor, it's a useful lesson in sorting out conflicting information. The Open Source world is even freer with opinions than it is with code, so sometimes it takes a bit of work to sort things out.

Security hole?
We'll start with the security implications, since that is the most crucial issue. I reported that the phone-home script—which is officially called Heartbeat V3.0—put the user at risk for remote exploits. So how would this happen? CEO Lyman explains:

"The first time it connected, a unique encryption key pair was created and exchanged. Then every 24 hours it opened an encrypted connection, based on that key, to a Fonality server and transmitted its heartbeat data. At one point, with that daily connection the script could also be modified by Fonality servers. This was done such that we could improve the script, make it more efficient, fix bugs, etc."

So if someone were to successfully exploit this ability, they could have sent an arbitrary list of commands to be executed, which of course is a bad thing. How much of a threat might this be in real life? For an attack like this to succeed, one of two things have to happen: Fonality's servers have to be compromised, or your network connection must be compromised.

The second scenario requires a successful man-in-the-middle (MITM) attack. An MITM attack occurs when an attacker succeeds in intercepting your network transmissions, and is able to read, insert and modify messages without you or anyone else knowing about it. There are a number of ways this can happen. One is to compromise your DNS server, hijack your name services, and divert your traffic through their systems. Another way is for someone inside your network to eavesdrop and perform other mischiefs, which is pretty easy to do. Anyone who has access to the wires carrying your traffic, such as inside a data center or Internet service provider can also eavesdrop at will.

The defense against these is strong encryption, and a protocol like SSH that detects mischiefs and warns you. But MITM is also a potential weapon against strong encryption, because setting up encryption depends on first exchanging encryption keys. An attacker who is in a position to intercept the initial key exchange can then substitute their own keys, and then they own you. So theoretically, there was a moment of opportunity when Heartbeat ran for the first time. But in real life, when someone has succeeded in a MITM attack you're already toast—your entire network is already compromised.

Other, likelier avenues of remote attacks are through poorly secured routers (have you changed your default password yet?) and wireless access points. So the first release of Heartbeat V3.0 had an unacceptable level of remote control for a lot of admins, but the real-life risks were small.

Inside job
I also reported that Heartbeat opened the door to an inside attack; that is, by a disgruntled or dishonest Fonality employee. A successful compromise of Fonality's servers would have the same effect. Mr. Lyman claims that they have strong measures in place to prevent this from happening. As you'll recall, the original incarnation of Heartbeat v3.0 allowed the (presumably authorized-only) folks at Fonality to modify it and run arbitrary commands on user's trixbox systems. As long as this was possible, many users would not allow it to run at all, no matter how much they believed in Fonality's good intentions and security measures. So Mr. Lyman made these changes:

"Now, the daily check-in is one-way. This means Fonality cannot force the script to do anything new. However, we have retained the right to tell the script to "stop checking in." This last vestige of control we feel is not only necessary, but ethical. E.g., If this script is going haywire, we can still tell it to stop running."

New Heartbeat
The second biggest problem was the lack of disclosure. Nobody likes to feel like something sneaky is happening on their computer systems. Mr. Lyman and Mr. Garrison have said several times that this was an oversight. In the current trixbox CE release, the existence of Heartbeat and what it does is prominently disclosed during installation, as are the steps to disable it. So what does this thing do, anyway? Read the official explanation. You can read the new Heartbeat script yourself to verify what it does. Why does Fonality even want to collect this data? To help fund trixbox development. Read the official explanation for details.

Even the best people make mistakes; what counts is what they do to make it right. The nice thing about using Open Source software is it enables "trust, but verify".

A good informative discussion; hit the "thread" link to see all posts
VoIPowering Your Office: Eavesdropping on VoIP Calls (Part 1)
VoIPowering Your Office: Encrypting VoIP Calls (Part 2)

Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved