Secure that Client!

In the last issue, I covered the basics of Internet connectivity and security for servers, touching on the use of firewalls to protect machines from attack over the Internet. In this article, I’m going to look at security of client machines, the most common form of deployed computing.

In many ways, securing a client computer is tougher than securing a server. With a server, only experienced individuals should have access to the network and software configuration on the machine; on the client, the operator will likely be an end-user with little or no computer security training. This is the reason many recent computer virus’ and worms have targeted the client for their infection vectors.

Server exploits can be thought of as a “push” methodology — an attacker (a human or a worm/virus) initiates the process, attaching to an exposed service’s TCP/IP port. Client attacks, on the other hand, are “pull”; the attacker must wait for the client to initiate a connection to a hostile server (in the case of a web browser exploit) or to fetch exploit data (for e-mail or application macro attacks). Keep in mind also that a client machine may also be configured as a server, adding to the potential exposures.

“I send you this file in order to have your advise.” The e-mail, appearing to come from someone the recipient likely knew, had an attached file which was randomly selected from the hard-drive of a victim of the SirCam worm. The file itself was modified to carry the SirCam worm as a payload, in addition to the original (potentially private or sensitive) contents.

Clicking on this attachment resulted in the recipient becoming a SirCam victim as well. The worm searches for e-mail addresses on all attached hard-drives, sending itself to all it finds (along with another randomly selected file). It also did other nasty things, like filling the hard-drive with junk and deleting files.

SirCam, LoveLetter, Code Red, Melisa, Valentine, et al, all rely on a human recipient to run them. They get around the old adage to never launch an attachment from someone you don’t know, by appearing to be from someone you do know. Most of them also rely on Outlook (or LookOut, as it’s known in security circles) “helping” the user, by hiding the .vbs or .exe extension which might tip off the recipient that they’re not dealing with just a document or image, but instead an executable program.

Nimda, the most recent worm to attack Windows machines, went several steps further. Leveraging on a bug in Internet Explorer (IE) 5.5 SP1 and earlier, Nimda could infect a client machine simply by having the user view the e-mail in a client (for example, Outlook) which used IE to view HTML e-mail — no launching of the attachment was needed.

Nimda could also infect other clients by way of file shares, as well as servers running un-patched MS Internet Information Server (IIS). Lastly, infected IIS machines could compromise un-patched IE browsers by including the worm’s payload in all HTML pages served by that server.

By using these multiple infection vectors, Nimda was particularly effective at spreading itself. By using both e-mail and web browsing, most firewalls were totally infective. As virus scanners are generally reactive, in that they don’t know what to look for until a worm or virus has already spread throughout the Internet, they were also ineffective.

So what can be done? The same rules of religiously applying updates and patches to all software running on the clients is a good start. It is worth noting that the exploits used by Nimda were known for many months, and in some cases over a year, and had been used by previous worms.

Limiting the use of file shares can also be very effective at lessening the exposure of client-to-client and client-to-server infections. It is not at all uncommon for all computers in a Local Area Network (LAN) to have write access to an organization’s file repository and/or the internal web server. While very convenient for users, it’s also equally convenient for worms.

Another security policy which would help lower the exposure of e-mail attacks is the enforced rule of not allowing e-mail attachments. This can be enacted by configuring an organization’s Mail Transport Agent (MTA) to strip away any attachments included with incoming and outgoing e-mail. The users might scream, but the network would be a much safer place.

The last option is to stop using software which has a bad history of compromises. Nimda prompted the Gartner Group to recommend organizations to look for alternatives for IIS for their web-serving needs. I would go a step further, and suggest organizations look into using alternatives to Outlook, Internet Explorer and Office as well, as they all have bad histories of exploitable weaknesses.

Eudora, while not having the scheduling functions of Outlook, has a much better security history. Netscape 6.2 and Opera 6.0 have the same functionality as IE, but without the constant stream of serious bugs. StarOffice/OpenOffice similarly has most of the functionality of MS Office, including file-format compatibility, without the exposure of macro viruses.

MS products are ubiquitous in the marketplace. Rather than being a rational for using them as well, I would argue that this should be an argument for not using them. Much like bio-diversity, there is advantage in not having the exact same infection risks as everyone else.

As mentioned in the last article, there is nothing but the restraint on the part of the worm and virus authors not to do much more damage than simply infecting and spreading themselves. Anyone who’s ever been infected by a worm or virus should think hard about how comfortable they feel relying on the good will of the authors. It’s a matter of when, not if, a truly destructive attack will take place.

Published in the Victoria Business Examiner.

Write a comment