> A number of people have put effort into supposedly providing "proof
> of concept" code or "remote test" code that allows Administrators to
> determine whether or not their IIS 5.0 box is, or isn't, patched
> against this .printer buffer overflow.

I prefer to call it "proof of vulnerability".

> In a conversation I had with Marc Maiffret about exploit code, he
> indicated that they (Eeye) had produced something to demonstrate the
> severity of the issue to Microsoft. Perfectly understandable,
> reproducing an issue and allowing the developers to see the potential
> of a vulnerability are the most important thing a discoverer can do.

It is typically easier to work with the vendor to solve an issue if you are
able to provide code that exploits the problem at hand. This is nothing new
and is done by almost all research groups in one way or another. This was
usually common practice back when I worked for RAZOR.

> However, doing the same for the public-at-large is another thing.

Is it really? What is wrong with giving administrators, who may not have
the skills to manually test their machines the ability to do so? Many do
not simply trust the hot-fixes or patches without actually verifying
vulnerability themselves.

> The HFCHECK.wsf script/tool from Microsoft is perfectly capable of
> determining whether or not a local or remote box is vulnerable to the
> .printer exploit. Using WMI, within an organization, an Administrator
> could easily determine whether some or all of his/her W2K boxen have
> applied the patch. Using the customization to NOTIFY.JS described in
> the documentation supplied with HFCHECK, an Administrator could
> receive an email notification of any box which failed the test.

Cool idea and while someone like yourself could easily script this up, it is
the reality of IT shops today that not all administrators are created equal
and not all posses skills that you and I would consider essential. It could
be argued that if the administrator has the skills to run the C script but
again, just because the hot fix is there, it doesn't mean that the box is
not vulnerable. A good example of this is a client I did a pen test on last
week. I found them to be vulnerable to the Unicode exploit, the client has
documented build procedures that in their minds prove that the Unicode patch
was installed. Yet some other factor made them vulnerable to something that
they installed a hot-fix for. Look at the confusion around Guninski's last
discovery. In my test lab, 1 out of three machines that are all patched
were vulnerable and others reported similar results.

> Moreover, not only will HFCHECK verify whether MS01-023 has been
> patched, it will also ensure that any patches a given W2K box needs
> have been applied, including security patches to other program sets
> like the OS, Exchange, whatever.

I am not disputing the fact that HFCHECK is a valuable tool. It is, but
again, not everyone trusts the fact that the presence of a hot fix
guarantees that the issue does not exist. I have personally seen proof of
this.

> So while IDS Vendors and the curious few might "need" to have sample
> exploit code, to suggest that same code is "needed" to allow
> Administrators to make a determination is, IMO, flawed thinking. With
> advisories from so many sources within 24 hours of the announcement
> of the vulnerability, you would think that everyone who should know
> about the problem does. Folks should also have appreciated, again by
> the sheer volume and speed of advisories, that this one is a big
> problem that needs to be acted on right away.

This activity happens regardless of what guys like you, me Elias, or anyone
for that matter want to do about it. Yes, we are seeing a flood of "proof
of concept" code but the alternative is not seeing it. You have been around
long enough to know that the code is going to be created and distributed
with or without the support of the community. The stuff we have seen across
the various mailing lists is only a fraction of what is already out there to
exploit this particular vulnerability.

> All the exploit code does now is become the basis for actual
> malicious exploits, regardless of disclaimers to the contrary.

Which will happen anyways, even if eEye did not release proof of concept
code. Granted, it might have taken a few days longer but it would have been
done and done quietly among certain groups. To me this is the scary
alternative to everyone sharing.

> Seeing may be believing, but if your security is based on
> vulnerabilities being proven to you (or to yourself) before you patch
> then your machine is likely vulnerable to several exploits right now.

Its not that vulnerability needs to be proven (well, in some cases they do)
it is that the patches need to be confirmed. Typical IT shop today is
running at 150MPH and mistakes get made by very qualified people. Exploit
code gives everyone the chance to check and double check.

> The threat level of this particular vulnerability (MS01-023) was,
> IMNSHO, entirely dictated by the availability and quality of exploit
> code. In the 24 hours since the advisory was published it went from
> Low to Extremely High.

The fact that a remote shell can be gained, regardless of the context of
that shell in my opinion makes this a high threat and should have never been
considered a low threat.

Regards;

Steve Manzuik
Moderator - Win2KSecAdvice

*This email contains my opinion and my opinion only*

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]