Conficker malware ups the ante

Roger A. Grimes explains why keeping up to date with patches can mean the difference between a functional system and a playground for hackers

TAGS: Hacks and breaches, Internet Security, Risk Management

I'm finding many Windows servers without the MS08-067 patch and no specific mitigations applied. There hasn't been a very large malware outbreak (a la Code Red, SQL Slammer, etc.) in a few years, and perhaps this could be leading to a false sense of security.

If you don't patch, the ever-transforming Conficker malware program could end up testing your security perimeter breach responses. Microsoft released the patch on Oct. 23, 2008, nearly two months ago. To remain unpatched at this point and time doesn't seem to be a great idea, but there are still plenty of vulnerable servers out there.

How the Conficker worm still wreaks havoc

The Conficker worm's main exploit vector is by buffer overflowing unpatched versions of Windows Server services, which is represented by the Workstation and Server services, and svchost.exe processes. Initial exploitation normally occurs remotely over NetBIOS/SMB ports 139 or 445 using a malformed RPC request. It can be accomplished with an unauthenticated connection in Windows XP Pro and Windows Server 2003, but requires an authenticated connection in Windows Vista and Windows Server 2008.

[ Take a slideshow tour of InfoWorld's 2009 Technology of the Year Award winners in Applications, Middleware, and Data Management | Application Development | Platforms and Virtualization | Systems and Storage |Networking and Security ]

Once a system is infected, Conficker takes a variety of actions, including exploiting several routes that have nothing to do with the Server services. It disables common anti-malware programs and uses DNS modifications to prevent local end-users from surfing to anti-malware-related Web sites (which might be one of the first clues that you're infected). It spreads to mapped file shares and identified removal drives. Once there, it creates a subdirectory folder called Recycler (emulating the Recycle Bin) and places an Autorun.inf file, which may be auto-launched when visited.

It attempts to connect to remote admin drive mappings using hundreds of common, weak passwords, including multiple versions of numbers and letters. If you find an infection on your network, you probably want to check out the list and see if any of your passwords are located there. Using either exploit vector, Conficker is able to infect computers that are fully patched after first exploiting one unpatched network computer. Conficker isn't the first worm to do any of these things, but the most popular worms rarely do anything new.

How admins are protecting servers from Conficker -- or not

I don't understand why more administrators aren't patching Windows servers. Maybe they think the perimeter firewall will protect them, since they don't allow ports 139 or 445 access from the Internet. But as anyone from the MS-Blaster days can tell you, a perimeter firewall really doesn't provide that much protection in today's world of traveling laptops and remote VPN users.

I'm sure some of the problem is due to the distrust of Microsoft patches. In the past, some Microsoft patches have caused operational issues. Although Microsoft is getting a lot better on this, it's hard to forget if you've been burned in the past. That's understandable, and why any patch management strategy should have acceptable regression testing built into it.

Some of my clients don't have identical test environments to test patches on. That's understandable, although setting up VM environments should make the task easier cost-wise. Many of the biggest VM vendors, certainly VMware and Microsoft, offer free utilities that will snapshot a real, physical box into a test VM image. But even if you have an identical VM, unless it is being thoroughly tested as if it were functional on the production network, it's never a completely thorough test.

Patching best practices

So always have a plan for reversing patches once applied on the production network. Servers should have a complete backup prior to any patch being applied. Microsoft offers free technical support (866-PCSAFETY) for any security update-related issue. For mission-critical servers, consider using clustering or network load-balancing services to allow one server at a time to be patched, instead of trying to patch all at once.

If you don't want to (or can't) apply the patches in a timely manner, implement suggested workarounds and mitigations. Microsoft offers these in every security bulletin. If your environment is so thin on assets and resources that you simply cannot take the time to regression test before applying patches, back up the servers and apply the patches. Today's Internet is too malicious to let unpatched servers hang around on your network. The patches are being code-reversed in minutes and the worms are pouring out into the public in hours.

I do a lot of on-site security reviews. Frequently I'm told that all patches are being applied in a timely manner, but when I audit sample servers, I find out that isn't really the case. If you're an IT manager, do a little spot checking to see if necessary patches are being applied. Use your regular patch management auditing tool or simply use Microsoft's free Baseline Security Analyzer (MBSA).

Many organizations cannot patch quicker than a few weeks because of security policy or oversight boards. If this is the issue, take your case to management and ask that a more timely response be allowed for high-risk scenarios. Your patching strategy must be updated for the times. Waiting weeks to patch servers is no longer a best practice. It's an outlier, and if anyone is ever asked in court to defend how they supported something, the lawyers and the court system always rely on best practices and due diligence as the baseline defense. Make sure you're not the one having to explain why you deviated from best practices in patch management.