IM Threats: The Dark Side of Innovation

Theres innovation, and then theres innovation. The dark side of innovation is evident in the rising threat from smarter IM worms. After all, innovation isnt so great when it means that hackers are getting sophisticated enough to write IM worms that can chat you up or deliver rootkits.

As it now stands, recent worms can tell what language to speak to you in and will even attempt to fool users with rudimentary conversations.

In August, researchers discovered that an IM-delivered virus queried the configuration of the client software to determine the language used to send the next message. The Mete worm, consequently, was delivered in Spanish.

Earlier this month, a worm programmed to chat with its victims hit AIM. IM.Myspace04.AIM was coded to chat and persuade the victim to click on a malicious URL embedded in the IM message. If the first attempt at infection is unsuccessful and the victim replies to doubt the legitimacy of the link being sent, the worm replies with the following message: "lol no its not its a virus."

Worse than social-engineering ploys is the first incident of a rootkit to spread via IM. In October, the lockx.exe rootkit file was installed when users clicked on the file link from their IM windows. Neither rootkit nor worm were new, but the use of IM as a vector were. More followed: Earlier this week, a Christmas-themed rootkit came in the Santa IM worm.

The dangers of SDBot appearing in an IM attack highlights a rapidly emerging trend for malware: Bootstrap onto the system, download a number of tools including a rootkit and spyware, use an IRC (Internet Relay Chat) network to control the botnet, and continue propagating.

As reported by Ziff Davis Internet News Michael Myser, this type of attack could give an attacker access to and remote control of the PC and may be used to steal information or promulgate more viruses. Beyond that, IM attacks have a built-in path for further infection, being able to automatically pass to users on Buddy Lists.

Rootkits can shut down anti-virus software, alter a users search page, run CPU usage to 100 percent and automatically download unwanted programs such as 180Solutions, Zango, MaxSearch and others.

Resource Library:

Beyond these recent leaps in innovative worm-building, hackers still have plenty of room to grow. Researchers are predicting that the future holds the potential for far worse than what weve already seen: namely, fully automated worms that can exploit vulnerabilities.

Jose Nazario, senior software engineer at network security firm Arbor Networks Inc., worm researcher and author who tracks malicious activity on the Worm Blog, told Ziff Davis Internet News Ryan Naraine for his report on the inevitability of an automated IM worm, the situation is "ripe" for a fully automated worm to cause serious damage.

"Im really surprised we havent seen a fully automated worm on these IM networks," Nazario said in his interview with Naraine. "To me, its begging to happen. … Pretty soon, someone will find a way to package one of these attacks with an unpatched vulnerability to cause some real problems."

Indeed, IM systems have become an increasingly favored target for attackers, with nearly 75 new IM viruses reported in August and September, according to the Q3 Threat Report by San Diego-based Akonix Systems Inc., a messaging security developer.

For its part, FaceTime recently reported a 20-fold increase in the appearance of worms and viruses on IM clients over last year. Meanwhile, peer-to-peer networks, such as Kazaa and eDonkey, are also increasingly facing IM attacks, with the total rising 9 percent in August, according to Akonix.

Protecting a business from IM-propagated threats can be done the hard way or the gentle way. Nazario suggests some common sense approaches, including that businesses instruct employees not to execute files from IMs, even if they come from trusted sources.

Consider enterprise editions of IM that employ security measures. Some vendors, for example, send test questions in response to unsolicited IMs to ensure they havent come from a remotely controlled computer or bot network.

Another approach is to route IM over a proprietary network, created to "strip out" viruses before they reach PCs in the enterprise.

A harsher approach to securing IM comes from suggestions left by readers in eWEEK.coms TalkBack forum. Nazario vetted the following suggestions but noted that they constitute substantial changes to the ways in which IM applications are written, restricting what they can do and confining them to a small, padded cell in which to operate.

First, have AIM on startup tell Windows "I want to read data files in My AIM Files and I want to write files in My AIM Downloads and I require no other direct access to files."

Next, require the use of the common files dialog box, and pass just the handle—not the file itself.

Also allow AIM to tell the kernel what IOCTLs (input-output controls) it expects to issue itself (i.e., none) and allow the kernel to reject requests coming from AIM for those IOCTLs, at a cost of four single-cycle instructions per IOCTL call.

Allow AIM to tell the runtime library which categories of functions it will be using, and allow the runtime library to then cut off access to other functions (again four x86 instructions per library call). For libraries like libJPEG, allow them to give up access that they dont need.

Force the application to provide data in a checked buffer (buffer, length), rather than directly reading files (which actually can be a performance win, since the application may be able to avoid chatty I/O calls that a library may have to make in order to be portable).

Just because you can program your IM application into a padded cell doesnt mean you should. Gentler approaches may work far better, Nazario said, simply because users are notoriously resistant to having their beloved IM tampered with.

"Its pretty easy to lock these [IM applications] down and restrict them to what they need to do," Nazario said. "[eWEEK.coms TalkBack Posters are suggesting] substantial programmatic changes to the application itself, to basically restrict it and keep it confined to a small, padded cell where it can operate."

The padded-cell approach imposes some sticky usage situations for users. For example, a thoroughly locked-down IM application could force users to put files into specific folders in order to share them with other IM users. In theory, thats a good approach to securing the network. Unfortunately, its also a recipe for triggering user resistance and workarounds.

"If users are given the option to ignore that kind of security guard, they will ignore it, or theyll find their way around it," Nazario said.

Nazario tends to eschew the strait-jacket approach to securing IM, preferring to first figure out what people are using and how. Second, he determines if theyre using authorized IM applications. The final step is figuring out how to secure those authorized applications that are in use.

How the securing gets done will depend on what particular network configurations youre dealing with but may include gateways, proxies or third-party IM.

Nazario recommends that those who decide to set up a proxy IM server should monitor activity on two levels: activity and content. First, monitor activity to ensure that the IM isnt up to no good.

Second, inspect content by checking for signs of exploit attempts. For example, IM that uses the slang of a teenager could be suspect, as is IM that prompts users to click on links.

As far as third-party IM providers go, Nazario suggests that the most fundamental aspect of choosing a provider is whether the provider supports the IM applications used already by an enterprise.

"If Im on AIM and a third-party application does not support AIM, Im probably not going to continue to look at it," he said. "Im not going to switch networks" in order to go with a given third-party hoster, he said.

After determining whether a third-party IM provider supports your enterprises IM application, assess how the provider fends off attack. Issuance of trial responses is a good first step in light of how IM threats are operating at the current time, for example.

Thus, spam links that contain malicious links would be challenged with an automatic reply such as, "Im sorry, I didnt catch that, could you repeat that?" or, "Did you mean to send that?"

This type of Q&A is a good mitigation strategy that will catch up worms such as the chatty one that recently attempted to lure users into conversation, Nazario said.

However, even this type of trial response wont stop threats that attack holes in the software itself, he pointed out.

This is what it all boils down to: When you think of innovation in IM threats in the coming year, envision a race. Malicious IM worm senders are the dark horse, and theyre steadily innovating up to the finish line. The finish line for the bad guys is that of creating a fully automated worm that exploits known application and system vulnerabilities.

Neck and neck are the providers. Through them, through AOL and Yahoo and MSN, are routed all messages. Theyre the "key reason we havent seen any massive flareup" of IM outages at this point, Nazario said.

"Yahoo, AOL, [et al.] are doing, for the most part, a good job of squelching" malicious IM activity, he said.

For example, MSN at one point began forcing people to use its most up-to-date version. For the most part, Nazario said, that was a wise move. Although there were bugs in the code, Microsoft has been working to address them.

And it does behoove these companies to use the most bug-free version possible. After all, when IM users hurt, the providers go down, and nobody likes that.

Check out eWEEK.coms for more on IM and other collaboration technologies.