News Stay informed about the latest enterprise technology news and product updates.

Nimda: still on the prowl?

Find out how Nimda may have created security holes in your operating system configuration. The virus can easily make a return appearance that way, so beware.

Could a flaw in your configuration make your operating system susceptible to security breaches? You bet. The Nimda virus seeks those defects and feasts away. In this first part of a searchWindowsManageability series on system configuration, Dennis Moreau, CTO of Woodland Park, CO-based Configuresoft Inc., and Alex Goldstein, Configuresoft CEO, discuss Nimda's attack pattern and how it creates even more operating system vulnerabilities. Configuresoft makes Enterprise Configuration Manager, a system configurations monitoring and management tool. Look out for part two in this series, which addresses configuration management and monitoring in Windows environments.

sWM: How exactly does Nimda take advantage of security mis-configurations?

It aims at the vulnerabilities that were discovered and exploited to give control to the virus from the outside, usually through either mail message forwarding or through Web browsing of already compromised Web sites. In a mail message, the virus is an attachment and you do nothing more than select the message and that transfers control to the virus code. The code then begins infecting files and creating back doors that are a security hole into a system. Or, you go to a Web site that's been comprised. That executes some Java script code that then transfers and executes the virus, giving you the contamination.

sWM: Why is this a configuration problem?

The reason this is a configuration problem is because these vulnerabilities were discovered months ago by Microsoft. Patches were engineered to fix the problem, and people didn't deploy them. Or they deployed them, and they were subsequently undone by other maintenance operations within the IT organizations. So, they weren't able to either get these patches out or know they needed to get them out. Separately, they weren't able to maintain the configuration of the system so that those patches were consistently applied when other changes were made to those systems.

sWM: And that's why we're still feeling the affects of Nimda today?

Yes, because some organizations aren't up-to-date on patches and hot fixes. In fairness, that's a very tough problem for IT organizations to solve because they have thousands and tens of thousands, and in some cases, hundreds of thousands machines all undergoing change on a daily basis. They would have to know what is the configuration of those machines to know the enterprise is secure, and that's where configuration management tools come into play.

sWM: How long will Nimda be around, and how long until its new version strikes?

It really depends upon what the people who created Nimda want to do. The unusual thing about Nimda is that it was not designed to create huge damage to the networks. It was predominantly focused on replicating itself and creating more vulnerabilities. If people don't fix these vulnerabilities then the exposure in the IT community is large. We aren't saying that there will necessarily be a follow up to it, but what they have done is created potential to follow up if people don't fix these vulnerabilities. That follow up could be far more damaging.


Nimda did a lot of things to a lot of different parts to the operating system, including overwriting files, removing and adding privileges of various sorts, being able to replace DLLs and executables and embed things in Web pages. All of that is still lurking on a system where the virus has essentially been stopped. Those things need to be sniffed out and corrected otherwise they represent exposures into the future.

There are two phases to reacting to the virus. The first is stopping it to repair the damage. The second is keeping it from re-infecting the system by closing the loopholes that it used in the first place.

sWM: Was Nimda worse than Code Red?

Nimda's impact was far less significant than Code Red's, but the complexity and the sophistication on Nimda was far greater. If Nimda had been the first virus, rather than the second, it probably would have been more damaging than Code Red. The things that people did to protect themselves against Code Red helped to minimize the impact Nimda had. Nimda was really scary because it had so many attack paths that it used. Code Red was a far more focused worm.


Lots of the organizations that took the biggest hit were using virus scanners and intrusion detection systems and firewalls, and this worm snuck in under operating system vulnerabilities. Its signature was not known. So, despite the fact that Microsoft had patches out to plug those holes, the virus scanning software didn't have signatures to recognize that systems had been infected until after this largest outbreak. That's a three-month gap. So, traditional security tools, while they're effective in focused, more recognized ways, aren't very effective when you get these very novel, very out-of-the-blue kinds of attacks.


The second part in this searchWindowsManageability series: Strong configurations can defeat viruses

How to repair and repel Code Red attacks

Get your questions on security answered in the searchWindowsManageability Discussion Forums

For more information on Microsoft IIS vulnerabilities, visit searchWebManagement.

Dig Deeper on Windows Server troubleshooting

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.