Once again, I spent most of my week dealing with an outbreak of malicious code, and I'm now taking steps to avoid a similar problem in the future. This time, we were hit with the W32.Mytob.HH@mm worm. We had been hit with a similar worm a few weeks earlier; the main difference is that this version uses different ports to connect back to the Internet Relay Chat (IRC) channel.
Our intrusion-detection guru traced the infestation to a user connecting to the corporate network via the VPN from a local airport. I talked to the user, and he told me that he bypassed the recommended method of gaining remote access when he associated to a wireless access point at the airport. When he booted up his laptop, the access point showed up in his task bar, and he was automatically connected without any authentication.
The user said he did some work on the Internet before launching the VPN client, and that "work" included executing an .exe file from an e-mail he got stating that his account had been terminated. He had assumed the e-mail was from our human resources system; he had previously gotten a message directing him to change his password for the system, but he hadn't gotten around to doing that. When he clicked on the link called "account-details.exe," nothing seemed to happen.
Well, we now know exactly what happened. His laptop was infected, and when he connected to the corporate VPN, the worm propagated to our internal network.
We tell users that the proper method for remote access, especially when traveling, is to use iPassConnect Universal Client from Redwood City, Calif.-based iPass Inc. We have configured iPassConnect so that after a user authenticates, it checks the system to ensure that both a desktop firewall and our virus-checking client are installed and running.
We also have the iPass client time out if the user doesn't authenticate to our corporate VPN within two minutes.
In addition, our VPN client forces the user to input his username and RSA SecurID token for authentication. Chances are good that if the user had followed these procedures at the airport, the malicious code he executed would have been spotted.
To enhance the security of our VPN infrastructure, we are installing Sunnyvale, Calif.-based Fortinet Inc.'s FortiGate appliance. We're already using these devices to protect our development lab environment, or rather to protect the corporate environment from the lab environment. At the insistence of the lab managers, our development labs don't conform to our corporate policies regarding host and network security, and things such as virus protection, patches, configuration management and secure baselines aren't used. The lab managers feel that they must be free to set up their environment as needed to properly test products.
Containment
Instead of fighting with them to conform, we decided it would be best to position one of the FortiGate appliances between the corporate network and the lab. Our hope is that if lab resources become infected, we can contain the infestation to the lab network.
This same reasoning is now being applied to the VPN segment. We can't vouch for the security of systems accessing the VPN. Employees don't follow the rules. We know that some of them have installed VPN software on their home systems. We've even seen cases of employees installing VPN software on systems in kiosks, libraries and customer sites. It's pretty ugly.
We're working on a method to ensure that only authorized company assets are permitted VPN access, but until we do some testing, we have to live with the current configuration.
Although the FortiGate appliance is ideal for detecting viruses, worms and Trojan horses, it can detect only what it knows about. It monitors all the network traffic that passes through it and looks for patterns or signatures that match what it knows to be "bad."
The problem is that some malicious code can be delivered in what is termed a "zero-day" attack, meaning that the code is written as soon as a vulnerability is identified, and it's sent out into the world before there are any antivirus signatures for it. Such malcode is easily propagated until the antivirus companies can get a hold of the code and write a signature.
With this problem in mind, I'm considering using a host-based intrusion-detection system, or HIDS. Almost all HIDS products "learn" the normal activity of a system. System calls, key-file manipulation, services, activity in the registry (if Windows NT), applications, network activity and several other areas are monitored for a period of time.
Once you put the HIDS into action, departures from normal activity are detected and action can be taken. So, for example, in the case of a zero-day worm, if the worm installs a new service, modifies the host file or opens a back channel to some obscure IRC server on the Internet, the HIDS will detect that activity, regardless of whether a signature has been written.
I haven't deployed a HIDS yet. The last time I tested these products, the HIDS agents caused an excessive amount of CPU utilization and our desktop firewalls had to be disabled. I decided at the time that deploying this technology to thousands of workstations wouldn't be in the best interest of the company. But I'll take a look at the HIDS product landscape within the next couple of weeks to see how the market has changed.