COMMAND

    UserId and Password available in memory

SYSTEMS AFFECTED

    Win NT 4.0 WKS

PROBLEM

    Following should be taken as security flaw if you had admin  who's
    doing what it shouldn't.

    Russell Osterlund found following.   It seems that the userid  and
    password remain  in memory  after a  user has  successfully logged
    on.  Specifically, the  memory space associated with  WINLOGON.EXE
    memory  (the  memory  block  containing  the  environment   space)
    contains     the     values     "lMprNotifyUserName=xxxx"      and
    "lMprNotifyPassword=yyyy",  where  "xxxx"  is  the  userid used to
    issue the logon to the workstation and "yyyy" is the password.

    The algorithm  used to  discover the  password and  userid is  the
    following:

        1) Locate and determine WINLOGON's process id.
        2) Open  up  this  process  for PROCESS_QUERY_INFORMATION  and
           PROCESS_VM_READ access.
        3) Issue a ReadProcessMemory on the address 0x00010000 for one
           page.
        4) Scan   the   copied   memory    area   for   the    strings
           "lMprNotifyPassword=" and "lMprNotifyUserName" and  display
           what comes after.

    Dave Mills added how implications  of this are actually much  more
    severe than what they appear to be on the surface, and here's why.
    First,  this  password  is  used  to  authenticate  against  other
    machines that you try and access resources on rather than  relying
    on your token that you receive whon you log on.  This fact can  be
    illustrated by  creating an  account with  the same  user name and
    password on a machine that is not a member of your domain and then
    trying to access a resource on that machine that only that account
    has  access  to.   This  was  alse  the  source  of the discussion
    sometime ago about IE  automatically responding to a  NT challenge
    from an  external web  server.   Second, it  seems that  with some
    initial testing he did some  time ago, this password is  also used
    to authenticate against machines within your domain.  The test  he
    did to illustrate this  is as follows:   Build a BDC, put  it on a
    isolated network and  promote it to  PDC.  Change  the password of
    your account  on the  isolated PDC.   Attach a  workstation to the
    isolated network and log on using the changed password.  Move  the
    workstation to  the main  network.   Try to  access a machine that
    your token  should give  you access  to.   The attempt  will fail.
    This test  was run  on machines  running SP3  (most current at the
    time) with no hotfixes.   There may be other factors  that account
    for this behavior, but the  initial impression is that the  cached
    password is used rather than the token for authentication  against
    other machines.

    You can see  the cleartext password  in LSASS also.  It is also  a
    system process.

SOLUTION

    Well, you have to  be admin to do  that.  The only  way hacker may
    use this is to gain info  about password and gain access to  other
    accounts if you  follow politics most  people do -  same passwords
    everywhere.  BUT REMEMBER, you have to be admin...