1. Privacy and integrity of iVisit communications
e.g., can people eavesdrop on my iVisit conversations?
2. Threats to host system operating iVisit client
e.g., does operating an iVisit
client make my host system
more vulnerable to attacks?
3. Threats to other hosts on a private network enabled to
allow iVisit traffic
e.g., does opening firewall to
allow iVisit traffic make my
network less secure?
4. Threats to host system operating iVisit server
e.g., does operating an iVisit server make host system more vulnerable
to attacks?
1. Privacy and integrity of iVisit communications
iVisit audio, video and live chat is carried directly from peer-to-peer,
and is not currently encrypted. So, anyone who is able to
eavesdrop on the network between you and the other parties you are
connected to could potentially eavesdrop on your communications. However,
this is more secure than e-mail, because all e-mail passes through
an e-mail server, and is stored there for a period of time. This
makes an e-mail server a very attractive target for a hacker. If
they can install an eavesdropper near the e-mail server, or
gain logon access to it, they have immediate access to a large
amount of communication of many people.
The left-most "Public" button in iVisit chat window sends
text directly to the people you are connected to as described above. However,
if you push down one of the other chat window buttons, then the text
is sent as an iVisit "Message". These do pass
through the iVisit server, and are stored there until the recipient
receives. Hence, they present the same vulnerability as e-mail.
The iVisit client and server will not allow any communication
without strong authentication. The authentication scheme
is based on Kerberos-like tickets, using AES (Advanced Encryption
Standard) encryption. This is unlike e-mail, which makes
it very easy for a sender to masquerade as another user.
2. Threats to host system operating
iVisit client
If you do not open the file sharing window, the iVisit
client has minimal interaction with the operating system, mainly
just reading or writing data to the audio system, camera,
screen, one UDP network port, and it's own file storage area. It
can be run with minimal system privileges. Installation requires
no changes to the System, other than establishing Registry entries
that define ".IVB" as an iVisit file
type. It uses no inter-process communication techniques,
such as RPC, that might allow the iVisit process to
control other components of the system.
If the file sharing window is opened, then additional risks are
created. Any file which iVisit receives is passed to the
Internet Explorer (IE) ActiveX control to open. iVisit then
depends on the security built into IE to protect the system from
harm, so this is similar to the risk entailed in downloading an
unknown file from the Internet. However, no file is ever received
without confirmation that you are willing to accept files from
that sender, and the strong authentication, prevents an attacker
from masquerading as someone you trust.
In order to connect directly to another user, the host IP
address must be revealed to that user. If that user has a
special interest in attacking you, then there are a wide variety
of attacks which can be launched against an IP address. However,
this vulnerability is also created every time you connect to a
www server, or any other host on the Internet. And, in any
case, it exists at all times your host is connected to the Internet,
since your IP address might be attacked for some other reason,
e.g., as a member of a certain domain, or simply as a random scan. Nevertheless,
the iVisit server will never reveal your IP address to another
host until you agree to connect to them. I.e., the initial
connection negotiation is carried out via the iVisit server, rather
than through direct communication.
It is possible that any executable which processes external
data may be vulnerable to a "buffer overrun" attack. This
results when there is an error in the coding, which allows
it to move data outside the memory allocated for the data, and
into an area of memory that contains instructions for the CPU. With
this technique, a clever hacker can cause the CPU to execute arbitrary
code. We believe iVisit contains no such vulnerability, but
no programmer can ever be certain that their code contains no errors.
3. Threats to other hosts on a
private network enabled to allow iVisit
traffic
In order to operate iVisit on a private network and connect to clients or server
outside the private network, traffic on UDP port 9940 must be allowed to
pass through the firewall. However, the firewall need not forward any unsolicited
traffic from the outside. When 2 iVisit clients agree to connect, after
authentication via the iVisit server, they simultaneously initiate connections
to each other. This outbound traffic signals the firewall that communication
is desired with that external host, so the firewall can freely reject any inbound
traffic from unknown hosts without disrupting iVisit communications.
This is a sharp contrast from most other videoconferencing software, especially
those like NetMeeting that are based on H.323 standard. H.323 requires
over 60,000 ports to be opened. For example, see http://www.homenethelp.com/help/netmeeting-router.asp
4. Threats to host system operating iVisit server
Like the iVisit client software, the iVisit server software is designed to require
minimal interaction with operating system services. It can be operated
under any user account which has privileges to open UDP ports 9946,9947 and 9948,
and that has an area of read/write storage space on the file system. If
there is a firewall between the server and the iVisit clients, then the firewall
must be enabled to allow inbound, unsolicited traffic on those UDP ports. The
potential of a buffer over-run vulnerability also exists within the iVisit server. However,
the server can easily be run under a set of restricted system privileges, so
that any harm of such an exploit would be restricted to the iVisit system itself.
I believe our best evidence of security is that we have been in operation
in the hostile environment of the public Internet for 7 years. Over
that time several security problems have been discovered. In 1999, a hacker
analyzing iVisit network traffic, discovered a way to keep a connection alive
even after the other user thought they had disconnected it. He was able
to create a modified version of the iVisit client software which behaved
in that way. The error in the iVisit protocol which he exploited was rapidly
fixed. I mention this example to demonstrate that iVisit has been under
attack for many years. Public communication systems are especially attractive
for hackers because they can gain notoriety and bragging rights within the community,
without running much risk of criminal prosecution if they are caught. Systems
which are initially designed to run in the trustworthy environment of the enterprise
network often present major security vulnerabilities once any aspect of the surrounding
protection is compromised.
Tim Dorcey
|