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: eEye Digital Security (eeyeEEYE.COM)
Date: Fri Apr 14 2000 - 16:51:22 CDT

Permissions on the "Test" servers do not necessarily have to be applied
wrong but they could be default.

By default on NT4 SP4 IIS4 FP98 it lets Everyone have Web Administrator
permissions to your FrontPage web. So an attacker can drop in with FrontPage
and upload netcat and cmd.exe to the cgi-bin folder and bind a shell to a
port of their choice.

The latest FP extensions fix this all though.

My 2 or so year old article about FrontPage. Webhosting companies should
give it a read.
http://www.eeye.com/html/Databases/Articles/DS19981129.html

C:\Inetpub\wwwroot\_vti_pvt\service.lck <-- behold the master of all things
FP

I think people should just walk away from this seeing how easily, a person
with the means and motive, could backdoor a piece of NT.

Signed,
Marc
eEye Digital Security
http://www.eEye.com

"4C4C20594F555220534545494E4720495320412050524F445543542042454747494E4720464
F5220594F55522046415441535320444952545920444F4C4C4152"
-544F4F4C

| -----Original Message-----
| From: Russ [mailto:Russ.CooperRC.ON.CA]
| Sent: Friday, April 14, 2000 12:45 PM
| To: win2ksecadviceLISTSERV.NTSECURITY.NET
| Subject: FW: DVWSSR.dll Vulnerability in Microsoft IIS 4.0 Web Servers
|
|
| Howdy all, my first post...;-]
|
| -----Original Message-----
| From: Russ
| Sent: Friday, April 14, 2000 3:33 PM
| To: NTBugtraq (E-mail)
| Subject: RE: DVWSSR.dll Vulnerability in Microsoft IIS 4.0 Web Servers
|
|
| 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)
|
| _____________________________________________________________________
| ** TO UNSUBSCRIBE, send the command "UNSUBSCRIBE win2ksecadvice"
| ** FOR A WEEKLY DIGEST, send the command "SET win2ksecadvice DIGEST"
| SEND ALL COMMANDS TO: listservlistserv.ntsecurity.net
|

_____________________________________________________________________
** TO UNSUBSCRIBE, send the command "UNSUBSCRIBE win2ksecadvice"
** FOR A WEEKLY DIGEST, send the command "SET win2ksecadvice DIGEST"
SEND ALL COMMANDS TO: listservlistserv.ntsecurity.net