Tampilkan postingan dengan label SECURING INSTANT MESSAGING. Tampilkan semua postingan
Tampilkan postingan dengan label SECURING INSTANT MESSAGING. Tampilkan semua postingan

Securing instant messaging in your corporation

Rabu, 07 Januari 2009 | Label: | 0 komentar |

Instant messaging may soon become an indispensable business tool; however, the risks of using an
unsecured IM platform in corporations are high. This section explores the security issues introduced. 
with the use of corporate instant messaging and offers best practices that can help in deploying a
secure IM platform.
UNDERSTANDING INSTANT MESSAGING AND CORPORATE FIREWALLS
Many corporate customers may wish to use their network firewall to block users from communicating
over insecure instant messaging systems. Unfortunately, out-of-the-box firewall configurations
are often not sufficient enough to block access to the latest generation of popular IM systems. These
IM systems were designed with firewalls in mind and employ a number of techniques to sneak past
corporate firewalls to reach their servers.
All IM clients are preconfigured with one or more TCP/IP network addresses that allow them to
connect to their IM server(s). Once connected, the clients can exchange messages with other
IM clients. Because many companies configure perimeter firewalls to block all Internet services
except for a small critical set (e.g., SMTP email, HTTP Web surfing, and DNS), IM providers have
designed their clients to tunnel over these commonly allowed Internet services, if required, and
slip past the corporate firewall .
For instance, if they initially encounter trouble connecting to their servers, many IM programs attempt
to contact these servers using network port number 80, the port used by browsers to surf the Web.
Given that most corporate firewalls are configured to allow any PC on the company network to surf the
Web, the firewall will pass transmissions through port number 80, including transmissions sent by an
IM client to contact its server. To the firewall, the IM client looks just like any other Web browser.
However unbeknownst to the firewall, the IM client sends messaging commands rather than Web
surfing (HTTP) commands to its server.5
Imagine that an instant messaging client is a fugitive on the run from the authorities. The fugitive
wants to cross a police roadblock (a firewall) on the main highway to reach his safe house (the instant
messaging server) and hide. Because the fugitive knows that the police are blocking traffic on all
lanes of the highway, he decides to take the bike path next to the highway (HTTP, port 80). Since the
police assume that only legitimate cyclists (Web surfers) will use the bike path, the fugitive can safely
slip by the roadblocks and reach the safe house. This analogy illustrates at a basic level how instant
messaging systems avoid detection by corporate firewalls.
In summary, to block instant messaging clients in a corporation, they must be prevented from reaching
their IM servers. To do this, the firewall administrator must add either the server address name(s)
(e.g., instantmessageserver.chatservice.com) or the server IP addresses (e.g., 11.22.33.44, 11.22.33.45)
to the firewall block list for every instant messaging service to be blocked. Given that some IM systems
(such as IRC) can connect to multiple independent servers, blocking these systems may require a fair
amount of research; however, this is the only way to achieve the desired results with any certainty.
UNDERSTANDING INSTANT MESSAGING FILE TRANSFERS AND CORPORATE FIREWALLS
Because existing instant messaging systems use peer-to-peer communications to send files
between users (rather than communicating through a central server that can be tweaked to allow
access), it is much easier to configure perimeter firewalls to block file transfers than to block simple
message exchanges.
The best way to block file transfers at the corporate firewall is to add rules to block the port number(s)
used by popular IM products for peer-to-peer file transfers. This ensures that any attempt to transfer
files through the firewall using one of these IM systems will be stopped. However, transfers between
two users within the corporation will not be blocked by this technique. Furthermore, at least one
existing commercial instant messaging system provides file transfer mechanisms that allow users to
sneak past corporate firewalls. For this reason, and because no current commercial corporate firewalls
scan instant messaging file transfers for viruses, organizations should deploy antivirus software on all
desktops to detect any infections entering through IM services.
In the future, we will likely see the commercial release of new firewall products and other types of
proxies that can scan IM file transmissions traveling between the corporation and the Internet.
Symantec is currently investigating various solutions in this space.
INSTANT MESSAGING BEST PRACTICES
Symantec recommends the following best practices for securely deploying instant messaging
systems within an enterprise:
Establish a corporate instant messaging usage policy
Given the risks involved in using public instant messaging systems, corporations should consider
prohibiting the use of public instant messaging systems entirely, or ask employees to refrain from
using public instant messaging systems for business communications.
Properly configure corporate perimeter firewalls
System administrators should configure perimeter firewalls to block all non-approved instant messaging
systems. Given that the firewall must block both messaging and file transfers, adding firewall rules for
both cases is also a good practice.
To block messaging, an administrator may add rules to their firewall to block access to all popular IM
servers. If this is not feasible, administrators can configure firewalls to block commonly used IM port
numbers from all clients on the network. Note, however, that this still permits properly configured IM
clients to tunnel through the firewall.
To block file transfers, system administrators can identify the port number(s) used for peer-to-peer file
transfers by each IM product and configure the firewall to block all communications over those port(s).
Deploy desktop antivirus software
Because current corporate firewalls are unable to scan IM file transfers for computer viruses, worms,
and Trojan horses, it is imperative for an enterprise to roll out up-to-date antivirus protection on all
desktops. Desktop antivirus is currently the last—and only—line of defense against IM-delivered
malicious code.
Employ personal firewalls to ensure policy compliance
Personal firewalls like the Symantec™Desktop Firewall (SDF) can be configured to prevent uncertified
and unapproved programs, including unapproved IM products, from communicating over the Internet.
A desktop firewall can provide far more granular protection than a perimeter firewall because
the desktop firewall can be configured to permit or deny communications on a per-program basis
(e.g., Chat Program A can use the Internet, but Chat Program B cannot use the Internet), whereas
the perimeter firewall can provide only a blanket policy for the entire machine.
Deploy corporate instant messaging servers
If at all possible, a corporation should deploy a secure instant messaging server on the company
network and configure all IM clients to connect to this server.
A number of private companies offer IM products for sale to corporations. In addition, systems such
as IRC can be obtained for very reasonable prices (or for free). Deploying one or more IMservers within
the corporate network to ensure that all internal IM communications are kept behind the corporate
firewall is a valuable practice.
Recommended instant messaging client settings
If a corporation chooses to use an external instant messaging system—one whose servers are operated
by the instant messaging provider—the following security practices should be kept in mind:
1. For the best security, do not use any external IM system that does not employ a certified
encryption system.
2. Configure all IM clients so that they will accept chat requests only from users specified in
employees’ buddy lists. This prevents attackers from connecting to computers on the network
and sending malicious code. Only those users explicitly specified by employees should be able
to contact them.
3. Configure the IM system to either block file transfers or allow such transfers only from users
specified on the buddy list. If this is not feasible, configure the IM software to prompt the
employee before all file transfers.
4. Configure the IM system to use antivirus software to scan file transfers, if supported.
5. Configure IM accounts so they are not listed on public servers. This further prevents unsolicited
chat requests.
Install all instant messaging patches as soon as possible
System administrators should roll out new fixes as soon as possible when security holes or bugs are
found in corporate instant messaging systems. CodeRed, Nimda, and even the Internet Worm of 1988
all used known vulnerabilities to spread to new systems. It is likely there will be future attacks on instant
messaging systems employing similar techniques.
Use vulnerability management solutions to ensure policy compliance
Corporations should consider using vulnerability management (VM) tools, such as the Symantec
Enterprise Security Manager (ESM), to ensure that users don’t change IM client settings in a manner
that violates company policy. Such tools can provide system administrators with an overall view of IM
policy compliance and facilitate the process of updating machines that violate policy. VM tools also help
administrators determine whether IM software is up-to-date, whether users are running versions with
security holes or buffer-overflow vulnerabilities, and whether users are running company-required
antivirus and personal firewall packages.
read more...

Instant messaging vulnerabilities and exploits

| Label: | 0 komentar |

This section describes significant vulnerabilities that are present in common instant messaging
systems and the types of attacks that can exploit them. A discussion on safeguarding corporations
from these threats immediately follows in the next section entitled “Securing instant messaging in
your corporation.”
EAVESDROPPING0
Given that most IM systems do not encrypt network traffic, a determined third-party can eavesdrop
on conversations between two IM users using a packet sniffer or similar technology. As discussed
previously, this holds true for both client-server and peer-to-peer messaging models.
ACCOUNT HIJACKING
Many instant messaging systems are vulnerable to account hijacking or spoofing, allowing an attacker
to hijack another user’s instant messaging account and impersonate that user in conversations with
others. A number of Web sites provide do-it-yourself tools or describe techniques for launching such
an attack.
Password protection is very limited in most instant messaging systems. Some IM systems store
user passwords in data files on the client’s PC. In some cases, these passwords are encrypted; in
other cases, they are plainly visible. There currently exists at least one Web site that gives detailed
instructions on how to crack the password encryption scheme for one popular IM system.
DATA ACCESS AND MODIFICATION
Like all Internet-enabled software, IM programs could have bugs that may be exploited by attackers
over the Web. Using attacks such as buffer overflows or malformed data packets, an attacker could
gain access to a PC on which a vulnerable IM client is installed. Given the large number of ancillary
features present in many IM products, there are numerous potential areas for attack.
As an example, in May 2002, a hacking group known as w00w00 identified a vulnerable piece of
computer code in a popular instant messaging program. This vulnerability could have been exploited
by an attacker to gain full access to targeted systems. From there, the attacker could have installed
computer viruses, stolen or deleted data, and even grabbed passwords. Fortunately, the IM vendor
moved quickly in this situation and issued a fix for the vulnerability to protect their customers.
WORMS AND BLENDED THREATS
Like email systems, instant messaging platforms provide the enabling technologies that are needed
for spreading worms and blended threats (such as CodeRed).
First, the instant messaging software provides a robust communications channel between system
users. Second, virtually all IM software products maintain a list of buddies with whom the user
frequently interacts. Like email address books, buddy lists can be leveraged as hit lists to spread
a worm rapidly through the IM user base. Lastly, some of the instant messaging systems are
scriptable or programmable, providing malicious programs targeted at these systems with a
mechanism by which to spread.
Given the ubiquity of popular instant messaging systems, a blended threat targeted at such a system
could potentially spread to tens of millions of personal and business computers in just a few hours. Once
in each system, a worm could delete data, install back doors, and possibly export critical data.
Symantec™ experts predict that such an attack will more than likely happen within the next decade, if not
sooner. The fast growth of broadband Internet connections will only exacerbate these security problems.
Blended threats and computer worms can spread through instant messaging systems in two ways:
by leveraging IM scripting and by exploiting a buffer overflow or other vulnerability in an instant
messaging system.
Scripting instant messaging threats
As described earlier, IM systems provide scripting capabilities that let other programs or script files
(e.g., Visual Basic or JavaScript) control the client IM software via simple programming commands. By
taking advantage of such commands, malicious code can use the IM system as a communications
platform to send itself into other members of the system, change program settings, steal confidential
information, and perform other potentially malicious actions. Similar functionality in traditional email
clients has been exploited in the past by malicious worms such as LoveLetter and SirCam.
There are dozens of real-world worms that propagate using IRC as a communications platform.
These worms are written in a scripting language provided by popular IRC client software and typically
work as follows: a user with a computer that has been infected by a worm joins a discussion group
and begins chatting. As subsequent (and still as yet uninfected) users join the same chat group, the
worm detects the new users and sends a copy of itself to them in the form of a script file. In some
instances, the receiving user is prompted to open the file; in others, the user receives no notification.
Once the worm infects the new computer, the cycle begins anew.
In addition to IRC worms there now exist a number of Windows®-based worms targeted at certain
IM systems. These worms use scripting techniques similar to those used by the Nimda and
LoveLetter and SirCam threats, to send themselves from user-to-user via instant messaging software.
Fortunately, none of these worms have been widespread so far, but they clearly demonstrate that
instant messaging platforms are susceptible to such attacks.
INSTANT MESSAGING THREATS THAT EXPLOIT VULNERABILITIES
As we have seen with CodeRed and Nimda, it is possible to construct a blended threat that spreads
without user interaction by exploiting vulnerabilities in an Internet-enabled software platform such as
a Web server. In the future, we could see similar worms or blended threats that exploit bugs or other
vulnerabilities in client-side IM software. Such a threat could, for instance, use a buffer overflow
attack on an IM client program to gain access to a new system. Once in the system, it could access
the user’s buddy list to gain a new set of targets.
This is an area of great concern, given the speed at which such a threat could possibly spread
and the large number of machines the threat could affect. While CodeRed was able to attack
several hundred thousand Internet servers in hours, a well-crafted IM-based worm would have the
potential to hit millions or even tens of millions of home computers or wireless devices in the same
amount of time.
Denial-of-Service
Like other communications systems, instant messaging platforms are susceptible to denial-of-service
attacks. For example, an attacker could send large numbers of specially crafted TCP/IP packets to IM
servers residing in the IM provider’s infrastructure to prevent legitimate messages from flowing
through the system. This would be similar to the denial-of-service attacks launched on major Internet
properties in the last few years. Alternatively, an attacker could send large numbers of packets to a
specific user or set of users to flood them with chat or file transfer requests.
Instant messaging server vulnerabilities
While many security experts have focused on the vulnerabilities of IM clients, it is also important to
consider potential IM server vulnerabilities. If attackers gained access to these servers, they could also
eavesdrop on all conversations, impersonate any user, launch denial-of-service attacks, or spread
malicious threats with little effort. Recall that little, if any, IM traffic is encrypted, meaning that an
attacker in control of an IM server can gain access to the contents of every transmission.
read more...

Instant messaging primer

| Label: | 0 komentar |

      While instant messaging may seem like a new technology, it is actually decades old. The first system,
IRC, was developed in 1988 by Jarkko Oikarinen3. Still in use, this system allows users to form ad-hoc
discussion groups, chat with one another, and exchange files. Since the introduction of IRC, many
new IM systems have been launched; for example, ICQ, AOL Instant Messenger, MSN Messenger, and
Yahoo Messenger. While each of these offers different features, they all provide the same basic
zxservice: peer-to-peer real-time chatting and file transfer capabilities.

INSTANT MESSAGING AND CLIENT-SERVER COMMUNICATIONS
Virtually all IM systems employ the same basic client-server
architecture. Users install instant messaging clients on their
client machines—desktop computers, wireless devices, or
PDAs, for example—and these clients communicate with an
IM server in the messaging provider’s infrastructure to locate
other users and exchange messages. In most instances,
messages are not sent directly from the initiating user’s
computer to the recipient’s computer, but are sent first to
an IM server, and then from the IM server to the intended
recipient. (See Figure 1.)
In the majority of client-server instant messaging systems,
data exchanged between users is plainly visible, making it
susceptible to eavesdropping.

INSTANT MESSAGING AND PEER-TO-PEER COMMUNICATIONS
While most instant messaging systems use centralized servers to
transmit all messages, some systems do offer peer-to-peer messaging.
In such a model, clients contact the IM server to locate other clients.
Once the client chat program has located its peer, it contacts the peer
directly.

INSTANT MESSAGING AND ENCRYPTION
Today few, if any, public instant messaging systems encrypt messages
as they travel from the client to the server and back to the second client.
This data is potentially visible to eavesdroppers anywhere along its
Internet path or within the IM provider’s network. Also, popular IM systems do not encrypt
peer-to-peer traffic. As shown in Figure 1, even if two users are sitting in adjacent cubicles, their
messages travel over the Internet, potentially revealing sensitive information.
Corporations should consider the confidentiality of instant messaging to be only as safe as sending all
internal and external company email using a public email service. For client-server-client
systems, traffic sent between two users can be assumed to travel unencrypted over the Internet. For
peer-to-peer systems, if either client is outside the corporate firewall, all traffic again flows unencrypted
over the Internet. In both cases, content can be intercepted by attackers with the proper tools.

INSTANT MESSAGING AND FILE TRANSFERS
In addition to sending messages between users, instant messaging systems allow users to exchange
files. Current systems transfer files directly between peers rather than through the server, as with text
messaging. In other words, the technique shown in Figure 2 is always used for file transfers. This
peer-to-peer scheme is used to eliminate the high bandwidth demands that server-centric file
transfers would place on the provider’s network.
Currently, none of the major instant messaging systems encrypt files transferred between instant
messaging clients. While the files do not directly flow through instant messaging servers, they may
flow over the Internet, over a corporate LAN or WAN, or over both. If both users are on the same
company network, file transfers will likely remain on the corporate network; however, if one of the
users is outside the network, files will be sent unencrypted over the Internet.

INSTANT MESSAGING AND SCRIPTING
A handful of instant messaging platforms offer scripting capabilities, enabling users to write Visual
Basic, JavaScript, proprietary script code, and other complex programs to control various features in
the messaging client. This functionality, while convenient, provides mechanisms that enable the spread
of computer worms and blended threats. Scripts such as these are able to instruct the instant messaging
client to do any number of things: contact other users, send files, change program settings, and/or
execute potentially malicious actions. A more detailed discussion surrounding these kinds of security
issues is provided in the following section on instant messaging vulnerabilities and exploits.

INSTANT MESSAGING AND OTHER FEATURES
Finally, in response to a highly competitive instant messaging market, some instant messaging
companies have added additional functionality to messaging clients to gain customers. For example,
ICQ contains a mini-Web server that allows users to run small Web sites directly from a desktop
computer. As with any Web-enabled software feature, such functionality creates the security risk that
the site could be hacked to break into a system.
read more...