How to Protect Against IM Vulnerabilities and Unauthorized IM: The Basics and The Vulnerabilities

The Basics of Instant Messaging: How does Instant Messaging Work?

To get a better understanding of the vulnerabilities that come with Instant Messaging (IM), we have to understand the basics first. How does an Instant Messaging program work? Does it have corporate IT support? Why or why not? How far does the problem spread?

Almost all of the IM programs use a client-server architecture. A user signs up to the IM system, receives/chooses a username and password combination. Then the user starts the IM client program, enters his credentials and the program connects to the server, verifies the user’s identity and if successful, connects the user to the system and retrieves his preferences and his contact list. Some IM programs use a different approach: the user asks for a connection to another user and the server returns the requested user’s IP address to the client program. Then both clients, the one who requested the connection and the other party whom he wants to be connected, know eachother and begin to send messages.

Instant Messaging Vulnerabilities

So far, the IM platform seems very easy and manageable. No, it’s not and the platform on which the IM programs operate have two fundamental risks:

1. The communication between the client(s) and the server are not encrypted. This is the same as writing a letter and sending it without an envelope, allowing anybody who handles or intercepts its way to read it.
2. The clients are adding special features to distinguish themselves from the others. The most frightening feature is allowing scripting on the client systems by using Visual Basic, Java or any proprietary language.

If we look at the first vulnerability, it is no more than offering everything private to travel freely over the Internet. Whatever you write, whatever you send as a file can be seen, read, downloaded, logged and saved. The eavesdroppers work is easy: find an IP address, sit down and read whatever is on the screen. Then, the client programs are prone to account hijacking, leading to identity theft. The password protection is very limited and some IM clients store the username and passwords on a file on the disk, offering everything to the attackers in a golden plate. If you don’t know how to steal those, a quick search will take you to many how-to sites that describe the process. If these are not enough, the IM programs have bugs/limitations that can be exploited by the attackers. This is not only for the IM programs, but for all the software installed on the computer (including the operating system).

If we look at the second vulnerability, it is not less frightening than the first one. You would not want a piece of malicious code working on your favorite IM program, which seems to change skins but God-knows what it is doing in the background.

Instant Messaging Vulnerabilities - Continued

Combine both and you have an unmatched platform to infect the computers and spread malware: you have the connection, you have the scripting and you have the contact list. What can an attacker want more? Nothing. Plainly nothing.

I’d like to take you back a few years and make you remember the famous “Love Letter” virus that spread widely on the Internet in a very small amount of time: it used e-mail programs’ vulnerabilities, it had used the scripting support, and it was spread by using the contact list that the users kept on their computers. Now, the problem is worse, since the IM programs are always online and always connected, resulting in a faster malware spread rate.

And, if these are not enough, then consider the unencrypted data flying everywhere: what if an attacker listens to the conversations on the server rather than the clients?

Considering all above, it is no surprise that corporate IT personnel tries to block the IM traffic on the network. Compromising security for one client may take down the whole network.

What’s worse, the IT personnel are seriously crippled by the abilities of the IM programs. The programs are designed with the firewalls in mind and they have everything they need to bypass the firewall rules. And they do not have one server, they have many. They have everything to disguise themselves from being seen.

Let’s give an example: suppose that the program MyChat needs to connect the server mychat.myserver.com at port 9190 to operate. And let’s further suppose that the network administrator blocked MyChat from connecting mychat.myserver.com at 9190. The client program will immediately try to connect mychat1.myserver.com from 9191. If this one is discovered, it will try mychat2.myserver.com from 9192. If the network administrator blocks all the ports, then MyChat will make a request from port 80, which is the port that the HTTP protocol runs: blocking port 80 will mean blocking the Web. And they will not do that with an IM identity, they will ask for connection as a normal web browser.

Still not enough, the IM programs allow file sharing. You know what I mean, a user can send a file to another user. What if the file he sends is an infected file? Or what if the filesize is so large that the transfer will result in a considerable load to the network? Or what if the file contains critical information about the company?

This brings us to another point: the security of the corporate data. IM clients allow fast connections and they can easily be used to transfer files to the outsiders. Using the IM programs inside the company is very useful (if done in a proper way) but the network administrators shall not forget the fact that there are also people who are outside the company but connected to the same IM network with the ability to sniff all the data. Now we have another serious problem.

Best Practices to Protect Against Instant Messaging Vulnerabilities

Although the situation looks hopeless, it is not. There are a lot of measures that a system administrator take to protect his network against the instant messaging vulnerabilities:

1. Train the users: This is a cliché, but it is fundamental. Schedule a training program and tell the users about the risks that IM programs have (and avoid to make this training program overly technical). It may be a good idea to inform the users about avoiding popular IM programs for work-related communication.
2. Establish a corporate IM policy: This can be banning the use of IM programs altogether or deploying a secure, certified IM program inside the company. If instant messaging to be allowed, the policy shall include banning the non-certified IM programs, configuring them to disallow any communication (chat or file transfer) from the people not present in a user’s contact list, configuring the antimalware products to scan every communication and configuring the in-company IM accounts so as not to be listed on the public IM networks as a minimum. Another option may be to deploy in-house IM servers which are closed to the outside communication.
3. Configure your firewall as appropriate: As we have noted before, blocking certain ports or blacklisting IM servers may not result in complete isolation due to the tunelling ability of the IM programs. The peripheral firewall can be configured to block file transfers and the ports that the IM programs make transfers.
4. Deploy personal antimalware software: Corporate antivirus products are not able to scan the IM chats, file transfers and the possible malware associate with the instant messaging whereas desktop (or personal) antimalware products can do this perfectly. But don’t forget that personal antimalware products are the last defense line.
5. Deploy personal firewall software: Personal firewall software can be configured in more detail compared to the corporate firewall software. You can allow IM program X to access the Internet but block IM program Y.
6. Update the programs: The update patches shall be reviewed and applied to the programs as soon as possible to avoid zero day attacks on the IM programs. This item can also be included in the corporate IT policy.
7. Add IM programs to vulnerability assessments: Again, the IM programs can be buggy and may contain holes that may be exploited. Therefore they should be included in the corporate vulnerability assessments (penetration tests).

Given all these and all the measures are applied in place you can be pretty confident that your network is in a better shape on an IM point. As all administrators know, static or one-time measures never prove to be effective in the IT industry. Blocking a certain port today and not thinking about the possibility of a new IM server opening some days later means that you have the probability to compromise your network tomorrow.