RFP2K03: Contemplations on dvwssr.dll and its affects on life

---------------- RFP2K03 -------------------------- rfp.labs -------------

       Contemplations on dvwssr.dll and how it affects life
              RFP2K02 Addendum: further information

------------------------------------- rain forest puppy / [email protected]

This advisory does contain new, technical information. However, it is
structured quite differently, and does contain a wealth of material. It
is your own decision whether you read it or not–I do not force you. I
only give you the option to listen to what I have to say.

A.K.A. don't bitch because it's long. Forewarning served.

---

In the words of Russ Cooper on NTBugtraq[1] on Fri:

    "Ok, so let's deal with this." [1]

Couldn't have expressed it better myself.

So there I was sitting. An individual injecting permanent black dye into
my arm with a small electrical needle device, forming a tribal pattern
that will forever be on my arm. Half way through I started to wonder
'why'? And trust me, half way through a tattoo session is not a good time
to start wondering such things.

Why? Why do such things at all? What would others reactions be to it?
Why do I care what others think? Who else is there really?

Deep breath. A flood of Descartes enters my mind. What is there beyond
myself? How can I be assure of anything beyond me?

Quite simply, I can't. I can't tell anyone what it's like to be in
Microsoft's place, because I haven't been there. I don't know what it's
like to be a Netscape engineer and be called a weenie, because I'm not (a
Netscape engineer that is; the other is debatable).

I can not positively state for certain anything other than my own
perceptions, since I only know what, well, I have personally experienced.
So I can only talk of matters concerning me, as when I involve anything
beyond myself, I am making assumptions on its form, state, and the
perception it offers to me.

So I have observed the results of RFP2K02. Every nuance, every publically
spoken word on the subject I could find, I have considered, contemplated.
What does each contemplation involve? I review them to myself…

–[ The First: Contemplation on origin of the 'hype'

By far, one of the largest writings that has provided me with the most
contemplation was by Ivan Arce, Presidente of CORE-SDI[2]. After
reviewing my advisory, he commented:

    "So these seems to be quite precise WRT possible attackers and
    impact, the hype derived from the media coverage does not seem to
    be part of RFP's agenda." [2]

So, I start to ask myself, where did the actual hype come from? So I
quest, searching, travelling past self doubt, skirting around fear,
stopping only at McDonalds for a #2 extra value meal (super-sized), when I
come across the original Wall Street Journal article by Ted Birdis[3].
Ah, yes, I think this is the place.

I can only guess to the process. My advisory provides a basis for the
problem. But if I was Ted, I would consider that a report from an
unconfirmed party. I am not Ted, but this is what I think he thought. I
would go straight to the source–Microsoft. Which, not surprisingly, he
did.

    "The manager of Microsoft's security-response center, Steve
    Lipner, acknowledged the online-security risk in an interview
    Thursday and described such a backdoor password as "absolutely
    against our policy" and a firing offense for the
    as-yet-unidentified employees." [3]

Straight from the horses mouth. Proceeding to the other end of the
horse…

    "Russ Cooper, who runs the popular NT Bugtraq discussion forum
    on the Internet, estimated that the problem threatened "almost
    every Web-hosting provider."

    "It's a serious flaw,"  Cooper said. "Chances are, you're going
    to find some major sites that still have it enabled."  Lipner of
    Microsoft said the company will warn the nation's largest Web-site
    providers directly." [3]

Well, I found that interesting. While my advisory may have served as the
seed, it was not only confirmed by the direct party responsible, but
supported by a second opinion.

There's no doubt to me where the 'hype' came from. It's right there.
Lipner said "yep", and Russ said "it's widespread". How was anyone to
know they would change their minds later? So this was confirmed. And it
was Russ who hyped up the widespread appeal to this…I remind myself that
my advisory stated it was minimal at best.

Then the thought occured to me…Ted Birdis actually had a lead, took the
time to follow up with the primary party, and include a secondary opinion.
Both were in favor, so he reported it. Considering the quality (or lack
thereof) of other journalists, Ted actually researched this, and went on
admitted facts from primary sources. Kudos for Ted for actually reporting
a story correctly, using concrete journalistic practices. Unfortunately
for Ted, Microsoft and Russ changed their stories…but this is not Ted's
fault.

So, I wonder, where did Ted go wrong? I don't think he did.

–[ The Second: Contemplation on Russ Cooper's mighty morphing story

    "A monk asked Yun Men, 'What are the teachings of a whole
    lifetime?'  Yun Men said, 'An appropriate statement.'"
                            - The Blue Cliff Record

So I sat, contemplating, when I wondered what Russ Cooper's view was on
the subject at hand. Then I asked myself "well, at what point in time?".

I was so confused, I had to make a timeline:

• Date: Fri, 14 Apr 2000 ???

    "Russ Cooper, who runs the popular NT Bugtraq discussion forum
    on the Internet, estimated that the problem threatened "almost
    every Web-hosting provider."
  
    "It's a serious flaw,"  Cooper said. "Chances are, you're going
    to find some major sites that still have it enabled."  Lipner of
    Microsoft said the company will warn the nation's largest Web-site
    providers directly." [3]
  

• Date: Fri, 14 Apr 2000 11:27:09 -0400

    "[T]his is a hole that could allow information to be manipulated
    by "others". However, its limited to "others" who already have web
    authoring permissions on the same box." [4]
  

• Date: Fri, 14 Apr 2000 15:32:52 -0400

    "Latest reports say that there is
    NO VULNERABILITY IN DVWSSR.DLL" [5]
  

• Date: Sun, 16 Apr 2000 10:02:41 -0400

    " >NO VULNERABILITY IN DVWSSR.DLL
    While I felt right at the time, now we know that that statement
    is clearly wrong." [6]
  

Ah, I now understand it much better; or, at least, it's easier to follow.
But my voices say to me, "why did it change?"

Why, indeed, I wonder. My voices are always interesting to listen to. My
mind wanders across the words of Russ…

    "FYI, my comments to Ted Bridis of WSJ yesterday about the issue
    were made with very little info (only the info he was supplied),
    so for example my  comment that this affects "almost every web
    hosting provider" was based on  the info that this was an issue
    on machines with FP installed." [4]

Ah, indeed. Very good reasoning for a switch in stories, I believe. But
that begs another contemplation: why is Russ then serving to provide
comments and opinions on issues of which he as "very little info"? Is it
professional to hypothesize the extent of such problems?

I wonder if that would be considered contributing to the 'hype'?

No, I concluded. If I had said such a thing, then yes, it would be
directly contributing to the hype. But since an authority said such,
well, I would hope that it would help clear the waters, rather than muddy
them.

Yes, muddy. Indeed. I breathe in. I breathe out. I continue to
contemplate.

–[ The Third: Contemplation on demonstration perl code

    "Even when I do things for the sake of others
    No sense of amazement or conceit arises.
    It is just like feeding myself;
    I hope for nothing in return."
                            - Shantideva

Much to think about. Much to ponder. I will, so it seems, not be without
more contemplation. As such, I now ponder on more words of Russ…

    "In my independent tests of a default installation of NT 4.0, IIS 4
    (from the NT 4.0 Option Kit using the "Typical" installation
    options), and SP4 (128-bit) I have been *unable* to reproduce the
    Denial of Service. Every attempt to use the CORE-SDI script, or
    variations of it, have resulted in a 401 - Unauthorized HTTP
    error. The server continues to process requests as if nothing had
    happened. The "Typical" installation installs FP98 extensions,
    enables the default web site as a Front Page Web, and installs
    the DVWSSR.DLL.

    "Please note, I'm either doing something wrong (although several
    different people have confirmed the same inability to exploit a
    default installation) or some other modification to the default
    installation must take place before you become susceptible to the
    attack. I find some reassurance in the fact the script does not
    seem to exploit a default installation, but of course I'm leery
    since both CORE-SDI and Microsoft say its possible. I have so far
    been unable to determine what exactly it takes for a site to be
    vulnerable to this problem." [6]

This makes my head spin. Not work? Why, I wonder, can Russ not get the
exploits to work? Is it his lack of ability to be a script kiddie? Are
the scripts non-functional? Do his servers not love him?

I do not know, as I am not Russ (I can hear a giggle of relief ruffle
through the Hall of the Goddess as I say that). But, a spark of light
envolves within me…grows…grows…enlightenment.

If I wish to test the vulnerabilities using the included perl script,
I need to change the permissions to allow myself to use dvwssr.dll
anonymously.

What? The voices in my head scream "but that is not normal!". Yes, yes,
the included perl script is a demonstration, not an exploit. I recall it
implements the client side of dvwssr.dll, but it does not implement any
web authoring authentication, nor find a way to bypass the default
permissions.

Thus the reason Russ hits 401 'Not Authenticated' is because he is not
providing web authoring authentication. But is there a way around this
roadblock, a way to circumvent the bane of ACLs? I recall my own words…

    "Also, the default permissions don't allow for anonymous users to
    use the .dll--however, anyone with web authoring can, and I've
    seen few sites that have allowed permission (which is more due
    to a misconfiguration on their part)." [8]

So I did not speak in err, but perhaps I did not speak loud enough for
Russ to hear. Or perhaps Russ just failed to read my words at all. I do
not know.

But I do know, that if I wish to make dvwssr.dll anonymously usable, I
need to give 'Read' permissions on /_vti_bin/_vti_aut/ folder and
dvwssr.dll contained within the folder. Once I do that, the script will
work.

Alas, my imperfections surface. There's a bug in my original script that
keeps it from properly encoding filenames greater than 31 characters in
length (I should have made it 'my $kc=length($from)%31'). The fixed code
is below. I must accept and deal with my mistakes, firm in knowing my
imperfections take me farther away from Nirvana.

I sigh.

But I wonder, should I make a new demonstration, one that does implement
web authoring authentication? No, I will not be making a client script
that includes web authoring authentication; therefore, this code will be
of no use to me other than a controlled demonstration. But, demonstration
indeed, as it shows what is possible. But the possibilities in my
imagination are endless. In reality, they are limited. Thus the curse of
being in a mortal vehicle.

–[ The Fourth: Contemplation on passwords and encoding mechanisms

    "[A] talent for speaking differently, rather than for
    arguing well, is the chief instrument of cultural change."
                            - Richard Rorty

I do not understand. The words of Russ ring around my little puppy
head…

    "THIS IS NOT A PASSWORD..." [7]

I'm in over my head. I must consult a master. So I walked over to my
shelf, and pulled the tome of tomes by the master sage himself, Bruce
Schneier [11]. "Ah", I thought, "this will hold the knowledge I need to
understand."

Chapter 1, page 1.

    "The process of disguising a message in such a way as to hide its
    substance is encryption"

Yes, I thought. Microsoft is trying to hide the filename. I recall that
Russ even state this himself:

    "My information says that this string is used to obfuscate file
    names requested via the dvwssr.dll." [1]

So they are using encryption (althought, I like to think it would be
better called 'encoding', but I'm just quoting the verse of the master
sage Schneier right now). I turn the page.

Chapter 1, page 2.

    "Plaintext is denoted by M, for message, or P, for plaintext.
    It can be a stream of bits, a text file, a bitmap, a stream
    of digitized voice, a digital video image...whatever."

I wonder if master sage Schneier would include 'filenames' on his list?
Surely, I think, he meant to. Perhaps in an upcoming edition he could add
it.

I continue reading on the same page.

    "Ciphertext is denoted by C. [...] The encryption function E,
    operates on M to produce C.  Or, in mathmatical notation:
            E(M) = C                        

Wow, add a square (^2) in there and we'll almost have an Einsteinian
property.

    "In the reverse process, the decryption function D operates on C
    to produce M:
            D(C) = M

    Since the whole point of encrypting and then decrypting a message
    is to receive the original plaintext, the following identity must
    hold true:
            D( E(M) ) = M

So I wonder to myself, "does the weenie algorithm hold true, as master
Schneier has stated is required?". I contemplate further:

I have a filename, which in this case would be the P (plaintext) or M
(message) I want to send to the server. I will use M to represent the
filename, because the letter P denotes connotations that are scary and I
don't want to deal with. Yes, much safer to use M.

So I have M. Now, it is apparant to me that the filename is 'disguised'
during transport. The client is responsible for disguising it, and the
server is responsible for dedisguising (is that a word, I wonder?) it.
Dvwssr.dll is the server portion, and they must take the disguised
filename, and produce the original version. So I conclude they must have
the functional equivalent of D(), thereby taking D(C) = M, my original
filename. My perl script take the original filename, and disguises it;
therefore, it implements E(M) = C. C is the gobbalty-gook (an
oft used technical term) ciphertext that is transfered between the
servers.

It is clear to me. The client implements a function E(), such that
E(filename) = encoded-filename; dvwssr.dll implements a function D(),
such that D(encoded-filename) = filename. According to master Schneier,
this is the foundation of encryption. Whew, I'm not barking up the wrong
tree. Even Russ seems to think so…

    "...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." [7]

I continue, Chapter 1, page 3.

    "If the security of an algorithm is based on keeping the way
    that algorithm works a secret, it is a restricted algorithm."

Who else knew about the details of the weenie encoding schema? I failed
to see it published anywhere. I would think that since only Microsoft
knew how it worked, it would be considered secret. But I digress, as this
being a restricted algorithm or not has no direct bearing on my
contemplation. I read.

    "Even more damning, restricted algorithms allow no quality
    control or standarization"

So that's what happened! No wonder this snuck through Microsoft's
QC. I press further.

    "Despite these major drawbacks, restricted algorithms are
    enormously popular for low-security applications.  Users
    either don't realize or don't care abut the security problems
    inherent intheir system.

    Modern cryptography solves this problem with a key, denoted by
    K.  This key might be any one of a large number of values."

While the master sage uses the literal term 'values', I remind my self
that a string, such as 'Netscape engineers are weenies!', being of
letters, is nothing more than values to a computer. But is the weenie
string a key? I must know. Further.

    "Both the encryption and decryption operations use this key
    (i.e. they are dependant on the key and this fact is denoted by
    the K subscript), so the functions now become:
            Ek(M) = C
            Dk(C) = M

    Those functions have the property:
            Dk( Ek(M) ) = M

My neurons race. The value of C that E() produces is dependant on the
value of K (which I have denoted in my ASCII algorithm representation [tm]
as 'k', small, to indicate subscript). The value of M that D() produces
from C is dependant on K. For Dk(Ek(M))=M to work, both values of K must
match.

Let's look at the algorithm itself. I invoke the awesome power that is
perl.

    sub encodefilename {
      my $from=shift;
      my $slide="ABCDEFGHIJKLMNOPQRSTUVWXYZ".
        "abcdefghijklmnopqrstuvwxyz0123456789";
      my $key="Netscape engineers are weenies!";
      my $kc=length($from)%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,