[Update: Spiegl Online reports (in German!) that the total may be as high as 50 million infected machines: however, this figure seems to be extrapolated from the number of infections picked up Panda's online scanner. Statistically, I'm not sure it makes any sense at all to try to correlate this self-selecting sample to the total population of online machines, though. (Thanks, Andreas, for drawing my attention to this item!) By the way, our own online scanner is here.]
9.5 million and climbing. PCs infected by Conficker (Downadup), that is, at least according to some sources. Some doubts have been expressed about how accurate F-Secure's calculation is or can be, but as the company have made quite clear, there are many factors that complicate the calculation. Nonetheless, it's clear that there are very high volumes of infected machines out there, though there are signs that the number has started to level off, so it’s unsurprising that it’s attracted so much media attention.
Since its appearance last autumn, our research teams around the globe have been paying close attention to this threat. Before we share a little more information on some of the malware's less widely publicized characteristics, though, let’s stop panicking about the sheer size of the numbers and get back to trying to reduce them. Conficker makes use of a wide range of attack vectors, so here are some approaches to stopping some of the holes.
First of all, of course, use good antimalware programs (we can suggest a particularly good one!), but don't expect them to give you absolute protection, no matter what you do.
Obviously, systems with up-to-date anti-malware are less likely to fall prey to a Conficker variant than systems that are inadequately protected. Like other companies, we've been detecting the many Conficker variants for some time, and regularly have been updating our detections (signatures and heuristic) regularly as more information on new variants come in. The real Conficker story was topical between its discovery in October and the beginning of this year when we were working on more effective ways to detect this threat in memory and to clean it. This is a sophisticated, complex threat, and it was necessary to create specific algorithms to address it fully, but up to now, detection has been pretty effective.
However, Conficker variants have gone way out of their way to hide from antimalware: for instance, by blocking domain names incorporating strings that suggest antimalware resources or companies. So it may be necessary to access updates or a Conficker-specific cleaning tool from a known clean machine.
One of the approaches Conficker takes to infection is to exploit the vulnerability described by Microsoft in their bulletin MS08-067, so patch vulnerable machines. (If they’re already infected, they’ll need to be cleaned first.) Another interesting characteristic is that it may patch infected systems that are vulnerable to the MS08-067 vulnerability. (Since it uses multiple infection vectors, not all infected systems are unpatched.)
The MS08-067 vulnerability is present in the netapi32.NetpwPathCanonicalize function from netapi32.dll. An out-of-band patch was released by Microsoft on October 23rd last year, intended to fix this problem, but a lot of organizations still haven't applied the patch to their systems. This is either because system administrators did not apply the patch in good time, or because home users are afraid to update because they are using pirated versions of their operating system. However, Win32/Conficker patches vulnerable systems by modifying the function containing the vulnerability and adding a jump at its beginning to jump to memory that has been allocated by the worm. (We assume that this is to “spoil” the chances of other malware using the same exploit, rather than a gesture of goodwill by Conficker’s author.) In this memory area, the worm has copied a patched version of the function. Since the vulnerable function is self-contained, meaning that it doesn't need to access any data other than its parameters, this technique is both stable and easy to implement. We recommend that you re-patch once the system is clean, rather than rely on the efficacy and persistence of the worm’s patching routine.
Clearly, not enough people (especially corporate organizations, it appears) have been patching in a timely manner. Where a machine is already infected, automatic updating is likely to be disabled (whether by the system owner/administrator or by malware), so you need to (a) understand the problem (b) take appropriate steps to remove the infection. You can’t fix/clean an infected machine simply by patching it: you need to disinfect it first. If you have machines that are uninfected but don’t have the patch, now would be the time to fix that. For some in-depth information on hot patching the MS08-067 vulnerability, please refer to the following web site: http://www.nynaeve.net/?p=226. You might want to apply MS08-068 and MS09-001 at the same time.
However, there are other factors such as weakly passworded admin shares (see, for instance, http://news.bbc.co.uk/1/hi/technology/7832652.stm). The worm attempts to access local network shares using a dictionary attack to try really basic login passwords/credentials. In a corporate environment, it makes sense to close admin shares and network-mounted drives while disinfecting, so that cleaned machines aren’t immediately reinfected, and ensure that strong passwords are in use before re-opening them.
Martin Overton made some useful suggestions on an AVIEN mailing list for restricting the spread of the infection over a network, including setting up SMBLure (see http://www.utdallas.edu/~pauls/smblure/ and http://momusings.com/papers/VB2003-Worm_Charming.pdf) to track machines broadcasting infected files to open shares, and using a Snort signature to block malcode with a known MD5 value. Martin is rather handy at using Snort signatures as an anti-malware tool, and has made available (along with other resources) one or two very nice papers on the topic. at http://momusings.com.
Conficker also makes heavy use of the Autorun facility in Windows. We’ve been pointing out for years that this is a facility that should be disabled by default (malware that exploits it is one of the most consistent problems flagged by our Threatsense.Net tracking system). It’s certainly a good idea to disable it at least temporarily while cleaning systems, to cut down on the risk of reinfection. We are pleased to note that Microsoft have now revisited the process for disabling it – see http://support.microsoft.com/kb/953252. However, US-CERT have an excellent technical note on the process at http://www.us-cert.gov/cas/techalerts/TA09-020A.html. While The Register is scornful of its high geek content we recommend the SyS:DoesNotExist solution described in the US-CERT’s bulletin rather than Microsoft’s. Martin also remarks that HKCUSoftwareMicrosoftWindowsCurrentVersionExplorerMountPoints2 key needs to be removed, before rebooting the system: otherwise, USB devices used before will still autorun (also addressed in the US-CERT bulletin).
Pierre-Marc Bureau and David Harley
(Tip of the hat to Martin Overton for his input to this blog.)
