Conficker Clarified

Conficker Clarified

I just happened upon a blog that made an interesting point about the information that’s been made about Conficker. Essentially, the writer was fulsome in her praise of an article by Gary Hinson here, which gave some simple advice on dealing with Conficker/Downadup. As it happens, I’m familiar with the name Gary Hinson: he also contributes

I just happened upon a blog that made an interesting point about the information that’s been made about Conficker. Essentially, the writer was fulsome in her praise of an article by Gary Hinson here, which gave some simple advice on dealing with Conficker/Downadup. As it happens, I’m familiar with the name Gary Hinson: he also contributes

I just happened upon a blog that made an interesting point about the information that’s been made about Conficker. Essentially, the writer was fulsome in her praise of an article by Gary Hinson here, which gave some simple advice on dealing with Conficker/Downadup. As it happens, I’m familiar with the name Gary Hinson: he also contributes to a blog here to which I also contribute occasionally, and has posted some excellent stuff there. In fact, Randy and I wrote a paper for AVAR last year that cites one of those posts (it should be available on our white papers page here soon).

I have to agree that the simpler the better in a case like this. and most people are probably more interested in how to avoid or remove the thing than they are in the complexities of estimating how many infected machines there really are.

(Not that I mean to criticize F-Secure in any way for making that information available: after all, I belong to a community that finds that stuff fascinating. And they’ve certainly provided provided plenty of information more immediately relevant to the man-in-the-street, or perhaps I should say the end-user-on-the-information-superhighway.)

I felt that in this case, Gary had missed one or two essential points and perhaps had slightly oversimplified the issues. So here’s an attempt to be a little less geeky than Pierre-Marc and I were in an earlier post on the topic and boil it down to a more accessible form.

As there’s a great deal of malware around that exploits the autorun facility (autoinfect, as we sometimes rather harshly refer to it round here), it’s an excellent idea to disable it, but to do so effectively is a lot less straightforward than the procedure in Gary’s blog (though even that will lower the risk). Microsoft have revised their procedure for doing so at http://support.microsoft.com/kb/953252, but US CERT’s note at http://www.us-cert.gov/cas/techalerts/TA09-020A.html addresses some weaknesses in the procedure. I agree, though, that if looking at these procedures makes you nervous, you probably need support from someone more confident with PC maintenance.

But there’s a lot more to Conficker than autorun. The main reason that so many -corporate- systems are infected is that they haven’t patched the vulnerability described here, www.microsoft.com/technet/security/Bulletin/MS08-067.mspx  and they ought to be patching MS08-068  and  MS09-001 at the same time. (See the earlier blog for more details.)

There’s also an issue with weakly passworded network shares that will certainly affect many corporate networks, though few home users, I’d guess. Like so much modern malware, Conficker will slip onto your system by any route it can find.

And because many home users will be using free but unsupported AV software, and in any case Conficker tries to stop infected systems from accessing vendor web sites, contacting the vendor may not be so simple. For cleaning purposes, the best option for many will be to get one of the Conficker-specific tools some vendors have made available, which will probably require access to an uninfected machine. Ours is here, but other vendors have similar tools. 

David Harley
Director of Malware Intelligence

Discussion