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”.
Resources
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)
