OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: DVWSSR.dll Vulnerability in Microsoft IIS 4.0 Web Servers
From: Russ (Russ.CooperRC.ON.CA)
Date: Fri Apr 14 2000 - 14:32:52 CDT


Ok, here's a breaking update.

Latest reports say that there is

NO VULNERABILITY IN DVWSSR.DLL

Yup, that's right, different again from what I said earlier, and even more
different than what I said yesterday to WSJ.

Please accept that I have followed the story published elsewhere and tried
to keep you abreast of everything I knew. Also appreciate that the amount of
time given to verify and research the claims made by others has been
extremely short. I've had probably 30 interviews today by orgs pressing for
information on the story as the feeding frenzy occurs after the first one
goes to press (WSJ in this case).

MS have had people working on this thing like madmen, trying to verify the
claims and investigate all of the possible pieces of code that may be
affected. As that research progressed, different observations were made and
so the story came out in various stages (with varying levels of
"correctness"). Had they been given a reasonable amount of time to respond,
nobody would have been in a tizzy about anything (i.e. the press would not
have cared to run this story anywhere).

Decide for yourself whether we were better served by (more) immediate
disclosure or not. I've stood where I stand for a reason, despite the
loathing of others for my stance...

In the end, it turns out that unless you actually have permissions for the
file you are requesting, you'll get an error message when you follow the
procedures outlined by RFP in his RFP2K02 advisory.

That said, understand that sites that allow connections by Front Page may
very well provide you with source asp if you request it. BUT THAT WILL
HAPPEN with or without the .dll. Without proper and full permissions applied
across virtual servers on a given box, site leakage or manipulation by
others will always be possible in myriad ways.

From what I've heard/seen/been told, permissions on the test servers must
have either been non-existent, incorrectly applied, or permissioned the user
across multiple virtual sites (i.e. incorrectly applied).

I had someone claim that they could get into an FP98 site using
"Netscapeengineersareweenies!" as a userID and no password...making them
think it was a backdoor userID. Fact is they could get into the same sites
using "TomDickandHarry" as a userID too. If the permissions aren't set
correctly, anything is possible.

This info may change again before its finalized. It may well be that there
is some way to use this .dll in a way that's not intended...it just doesn't
appear to be this one. On a box where multiple sites have not been
individually permissions, or permissions are lax or non-existent...anyone
permissioned to execute the .dll in the first place would have the ability
to simply open the other sites and manipulate them directly (i.e. no need to
do this junk with the dvwssr.dll)

Finally, to my point out the string not being a password. Elias Levy of
SecurityFocus.com and Mark Edwards of NTSecurity.net have both correctly
pointed out that using the term password to apply to that string is not
beyond the realm of understanding. The client component mtd2lv.dll and the
server component dvwssr.dll both need to know this value, and use it
correctly, for communications to work. If you try and talk directly to
dvwssr.dll and don't obfuscate your communication with the correct "key", it
won't understand you. Of course if you don't already have permissions,
knowing this value gets you nothing...hence my observation that its not a
password. Whatever it is, it appears to be meaningless junk text used as
data.

Cheers,
Russ - NTBugtraq Editor
"dot-age" (as in "we're in the dot-age") = senility (source Webster's)