Two problems with Alexis/InternetPBX from COM2001

From: Clint Byrum (
Date: 09/28/01

Message-ID: <>
Date: Thu, 27 Sep 2001 16:53:04 -0700
From: Clint Byrum <>
Subject: Two problems with Alexis/InternetPBX from COM2001

We have discovered a situation in which the InternetPBX product from
COM2001 will pass a user's voicemail password in cleartext over the
internet. There is also a minor issue with the way these passwords are

Alexis is a Windows NT/2000 and Exchange based phone system that
provides a lot of interesting features for helping businesses work in a
more virtual manner.

First, the voicemail passwords are stored in plaintext, in the NT and/or
w2k root directory in a file called com2001.ini. The impact of this is
minor, as the file can of course be protected with file system permissions.

"Alexis Server" has a web access component that links in to Exchange's
OWA. It asks for a user's voicemail password before allowing them to
logon. This can be secured using SSL, so the password is protected
there. Unfortunately, the alexis web access toolbar opens a java applet
that connects back to the server on port 8888(by default). This passes
the username and voicemail password in plaintext.

COM2001 is aware of the problem, and informed me that it has been fixed
in the next service pack, but they do not know when that will be
released. As far as we know, there is no "hot fix" available for this
specific problem.

This has some really bad potential effects. Those who could sniff this
password could then utilize the Alexis phone system to make long
distance calls, or calls pretending to use the phone number of the
affected Alexis phone system.

Affects: Alexis Server v2.1

Solution: Block port 8888 to your Alexis server until the service pack
is available. This will, unfortunately, disable some of the features of
the web access, such as call screening. If this is essential
functionality one can downgrade to version 1.1, which does not use the
voicemail password in the webaccess. 2.0 is unable to use SSL for the
webaccess portion and so is vulnerable to similar(and greater) problems.

Clint Byrum
ERP.COM Security