PSA: Conficker SCANNER released

[unixronin]

I remind you that the Conficker worm is scheduled to activate on Wednesday.  That event is now less than 48 hours away.

In a very timely move, the Honeynet Project has managed to find and exploit a flaw in Conficker, which they have used to develop a network scanner that can detect Conficker-infected Windows machines.

The Honeynet Project is very excited to announce a new scanning tool for detecting Conficker and an upcoming Know Your Enemy paper detailing how to contain Conficker.  Both the paper and the tool have been developed by Honeynet Project members Tillmann Werner and Felix Leder.  The tool was developed over the weekend, in co-ordination with Dan Kamisnky, and this tool is now publicly available and is in the process of being integrated into most major vulnerability scanning tools, including Nmap.  The Know Your Enemy paper describing in far greater detail how to contain Conficker and the tool itself, will be released in the next forty-eight hours.  Both the scanning tool and the paper have been developed and coordinated with the efforts of the Conficker Working Group.  We would like to thank them for their tremendous support, guidance and input on this research.

From the referenced Doxpara page:

We may not know what the Conficker authors have in store for us on April 1st, but I doubt many network administrators want to find out.  Maybe they don’t have to:  I’ve been working with the Honeynet Project‘s Tillmann Werner and Felix Leder, who have been digging into Conficker’s profile on the network.  What we’ve found is pretty cool:  Conficker actually changes what Windows looks like on the network, and this change can be detected remotely, anonymously, and very, very quickly.  You can literally ask a server if it’s infected with Conficker, and it will tell you.  Tillmann and Felix have their own proof of concept scanner, and with the help of Securosis’ Rich Mogull and the multivendor Conficker Working Group, enterprise-class scanners should already be out from Tenable (Nessus), McAfee/Foundstone, nmap, ncircle, and Qualys.

We figured this out on Friday, and got code put together for Monday. It’s been one heck of a weekend.

The technical details are not complicated -- Conficker, in all its variants, makes NetpwPathCanonicalize() work quite a bit differently than either the unpatched or the patched MS08-067 version -- but I’ll let Tillmann and Felix describe this in full in their “Know Your Enemy” paper, due out any day now with all sorts of interesting observations about this annoying piece of code.  (We didn’t think it made sense to hold up the scanner while finishing up a few final edits on the paper.)

Every non-trivial body of code has vulnerabilities.¹  Think about that.  Every one.  Including malware.  No matter how carefully you audit a body of code, you can never be certain that you have found and corrected every potential vulnerability; so make that your basic underlying assumption:  “Every non-trivial body of code has vulnerabilities.”  It’s just a question of finding them — for good or ill.

In this case, Conficker exploits a flaw in Microsoft code to infect Windows systems; and now the Honeypot Project and friends are exploiting a flaw in Conficker’s code to remotely detect its presence.  The wheel turns.

[1]  I’ll grant it is hypothetically possible to have a body of code that you know contains no vulnerabilities.  To have that knowledge, though, you have to be able to mathematically prove that the complete design of the code itself, every other piece of code that it relies upon, and the entire hardware system that they all run on are all completely correct.  If you are unable to prove the correctness of any one of those elements, you cannot be completely certain that you have eliminated all potential vulnerabilities.

Comments

[rbos.livejournal.com]

I've been messing around with this on and off all morning, no hits so far. Looks like the precautions I took a few months ago have been paying off.

[rbos.livejournal.com]

Far as I can tell, all the machines in my care are clean. That's about 600 at a university library, bookstore, and a few other assorted departments that we've accrued over the last couple of years.

[unixronin.livejournal.com]

Did you have any problems getting the Impacket package to install properly? It appears to install here, but the scanner fails to load it.

[glitch25.livejournal.com]

Gotta love it. :-)

Spot the defect!

[mrmeval.livejournal.com]

10 print "hello world"
20 goto 10

Re: Spot the defect!

[unixronin.livejournal.com]

"GOTO considered harmful." :)

Seriously, are you suggesting the above constitutes a non-trivial body of code?

Re: Spot the defect!

[mrmeval.livejournal.com]

It's not trivial the first time someone writes it. It's an example of code that probably has no defects.

Above a certain level of complexity any human created system will be flawed that includes computer software.

Developers need stable libraries, compilers and tools that are intended to write secure code. Effective automated tools to detect flaws would be good. Developers also need an attitude that supports secure coding practices.

Re: Spot the defect!

[unixronin.livejournal.com]

Amen to that.

Re: Spot the defect!

[janetmiles.livejournal.com]

I would say the defect is that the program will never end, but I may be missing something here.

Re: Spot the defect!

[unixronin.livejournal.com]

Indeed. We call'em infinite loops in the trade.

Re: Spot the defect!

[mrmeval.livejournal.com]

It's the simplest program a new coder would write. Yes it never ends and repeatedly prints "hello world". In most basic interpreters you can break out with ctrl-c.

I used it as an example of code that is probably flawless. Beyond that we don't do well with the complexity of code and need automated tools, better support tools and eventually we will have to have artificial intelligence systems to manage our networks and code.

James P. Hogan worked in the industry and he's a good hard SF author. He wrote "Two Faces of Tomorrow" in 1979. He'd predicted we'd have problems as the complexity of software and our network reached a certain point.
http://www.amazon.com/Two-Faces-Tomorrow-James-Hogan/dp/0671878484

[ithildae.livejournal.com]

Indeed. Often times the trick is to get a non-trivial body of code to run correctly, at all. Making it robust enough to run correctly in most expected environment is about as far as most programmers will take it. (It seems to be beyond many programmers.) Writing code that will survive malicious attack in hostile environments is something that only a rare few programmers have the capacity to even attempt. (Ever play "Core Wars"?)

It is often sufficient to have robustness in controlled environments. It is hard to justify paying for more. It generally takes a true savant, or a CMM level 5 shop, to achieve what the Conficker writers have been able to achieve. It is ironic that they fail because of the same limitations of the environment that they choose to run in. They exploit the system because it is not remotely considered secure. They are caught because their platform is not secure. Nice!