Best Practices: Securing IM Against Attacks
Free instant messaging services are just one of the many security holes facing corporate IT
In 2001, the CEO of eFront, a Web-site affiliation service, found that hundreds of his instant messaging (IM) conversations had been stolen and posted online. The logs included details and sensitive commentary on business partners—and that was just for starters.
In light of that incident, and similar threats today, many companies weigh whether IM is a corporate productivity tool or a security liability. While a range of enterprise tools exist to encrypt and protect IM communications in transit, many organizations allow employees to use free IM services, which introduces security risks, such as the one noted above. To discuss best practices for securing IM, plus the evolution of IM attacks, Security Strategies spoke with Eric Chien, the chief researcher for Symantec Security Response.
How secure is IM use in companies today?
There are a few security concerns with instant messaging that exist … First and foremost, you can transfer files, just as you can with e-mail. Already today we have instant messaging worms that iterate through your instant messaging buddy list … This affects home users as well.
[Take] all of the free instant messaging clients—AOL, Yahoo, MSN, ICQ, IRC … None of them by default [has] encryption. This means people using it for business purposes, inside companies, don’t realize that when they’re sending a message from their cube to the one next to them, that [message] goes outside the company, and then back to the guy sitting in the cube across from them. And that message goes out in plain text, which means someone could sniff the text … That’s a big concern, because … all that data can be sniffed and stolen by potentially malicious users.
Is corporate antivirus equipped to deal with IM?
Most of the antivirus products out there, Symantec included, already have plug-ins for instant messaging. What this allows you to do basically is prevent … attachments or [potentially] malicious code from even coming to you so that you have to choose whether to run it. It also intercepts and blocks malicious code.
What posture should organizations take toward IM use?
We ask customers [at conferences], "How many of you believe you have instant messaging used on your networks?" and you have almost 100 percent hands. Then you ask, "How many of you have an IT policy regarding instant messaging?" and you’ll see very few hands getting raised. Anecdotally [however], I’d say [use of policies] is getting better.
But for the most part, instant messaging still isn’t under the IT umbrella. That’s the first piece of business advice, first and foremost—they have to bring it under the umbrella. If it’s not a business need, they can block it, using firewall rules and proxies. It’s not trivial—instant messaging clients are designed to get around that—but it’s possible.
What’s another best practice?
[Companies should] standardize on one instant messaging client, and that instant messaging client must support encryption. Fortunately … all the major instant messaging vendors do provide enterprise-grade encryption … So when someone leaves, [companies] can also shut down accounts as well.
Why do many companies have their heads in the sand over IM?
One of the easy things businesses can do today is to block the use of instant messaging, but that takes away from the freedom of a lot of those employees, and my guess is that a lot of employees have a need for that. It’s very hard for system administrators to tell users they can’t use instant messaging; [users] would probably be chasing them down the road with lit torches and pitchforks.
What sorts of malicious code should people watch for over IM?
First, attachments … Second, backdoor Trojans that … don’t replicate, but someone sends them to you … It hooks up to your instant messaging client, so any time the message contains something—a keyword, for example—the keyword is intercepted, then … [used as a trigger]; it parses [the message] for commands [to execute] … This allows hackers to remotely control your machine using instant messaging. Then anything that you can do through your computer, [attackers] can do remotely.
How difficult is it to write Trojan backdoor programs?
Many instant messaging clients have APIs that allow you to hook into them, to allow you to do that sort of thing … We’ve already [seen] cases where someone has used IM, kept log files of all their conversations, and those log files have been stolen off of their computers [by Trojan software]. So … that risk is already out there. It’s something IT administrators have to get under their umbrella and under their control.
What about future IM attacks? Could they be worse?
There are some other things we’re interested in with instant messaging … and that’s a blended threat. If there was to be an instant messaging blended threat, that threat could potentially spread to half a million machines in under 30 seconds …
With something like Code Red or a Sasser, they’re limited by their ability to find hosts, and they find them by brute-scanning hosts. They start with 0.0.0.0, and go up to 255.255.255.255 … using UDP [User Datagram Protocol], Slammer took 20 minutes to scan the entire Internet to find vulnerable machines. But with instant messaging you already have a list of vulnerable machines—your buddy list.
How did you quantify the potential threat?
The way we arrived at those numbers—500,000 machines in 30 minutes—is … we took the number of unique machines on your buddy list, [plus] you need to factor that some buddies are already infected, plus the latency factor, and … in simulations [we found] a half-million machines in 30 minutes.
Have these automated infections, targeted at IM buddy lists, appeared yet?
This is definitely an interesting, future threat. The reality is … if that was to happen, a denial of service would occur on the servers for instant messaging; there’s no way they’d be able to handle all that traffic at one time. That would effectively stop the threat at that point, because as the servers go down, the messages couldn’t travel any further, and the vendor could patch the vulnerability … [The vendor] could also include some server-side filters to prevent [the attack] from spreading. So even though it could spread very quickly, it could also be cleaned very quickly.
So even though IM clients are relatively lightweight and easy to hack, there’s a potential stopgap?
It’s an interesting shift—Code Red and Slammer continue to propagate today, because they continue [to exist] on users’ computers. But when you talk about IM, all [clients] must connect to a server … and [those servers] can prevent you from connecting if you don’t have [a] vulnerability patched.
Are there any best practices you advocate beyond the above?
Another best practice is user education. That’s across the board for e-mail, instant messaging … [For example,] teach users to not download executables from unknown sources, or even known sources. [When it comes to attachments] we use these analogies … [If a friend e-mails and says] meet me at the park at 3am tonight, would you go to the park? Well, probably not, you’d probably call the person—did you ask me [to do that?] … Even in IM, it’s easy, it’s in real time—did you send me this file, what’s it about? Users [need to be aware of] these common, best computing practices.
- - -
Seven IM Best Practices For Security Managers
- Secure desktops: Deploy antivirus software and personal firewalls on all PCs
- What’s the policy? Establish a corporate policy for IM use. Encourage users not to end confidential information over public IM (AOL, Yahoo, etc.)
- Go Private: Deploy private corporate IM servers, if possible, to isolate corporate IMs from the outside world
- Block Out-of-band IM: Properly configure corporate firewalls to block unapproved IM traffic
- Enforce IM settings on PCs: on clients, ensure file transfers are refused by default, for example
- Patch: Install patches to IM software as soon as possible
- Monitor: Use vulnerability management software to ensure IM client policy compliance
Mathew Schwartz is a Contributing Editor for Enterprise Systems and is its Security Strategies column, as well as being a long-time contributor to the company's print publications. Mr. Schwartz is also a security and technology freelance writer.