Date: Fri, 20 Mar 1998 11:19:26 -0600
From: Aleph One <aleph1@DFW.NET>
To: BUGTRAQ@NETSPACE.ORG
Subject: RAS 'save password' problems...

---------- Forwarded message ----------
Date: Thu, 19 Mar 1998 14:09:44 -0800
From: martin Dolphin <mdolphin@POBOX.COM>
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
Subject: RAS 'save password' problems...

THE PROBLEM:
Windows NT allows users to save their RAS credentials by using the 'Save
Password' checkbox when making a dial-up connection. Credentials saved in
this manner are stored in the
HKEY_LOCAL_MACHINE\SECURITY\Policy\Secrets\RasCredentials!SID#0 registry
key.  These credentials can be enumerated using the LSA secrets code.  (As
identified by Paul Ashton in a prior submission to NTBugtraq)

If a user does not check the 'save password' checkbox to prevent the
password from being stored, RAS will STILL save the successful connection
information, including the password, in the
HKEY_LOCAL_MACHINE\SECURITY\Policy\Secrets\RasDialParams!SID#0 registry
key.  This can be enumerated using the LSA secrets code.

NOTE:  Administrator privileges are needed to execute the LSA secrets code.

OUR REASONING FOR THIS BEHAVIOR:
We think that this behavior exists so that Windows NT can automatically
re-establish a dial-up session that has been unexpectedly terminated.  In
order to "re-dial",  Windows NT needs to maintain the RAS credentials for
automatic re-authentication.

We believe that Windows NT uses the RasDialParams key to maintain the RAS
credentials for just this purpose (instead of maintaining them in temporary
protected memory). Unfortunately, the credentials are not cleared from this
key after the session is properly terminated.

IMPACT:
The following scenarios are some potential areas where we think this
behavior could give access to username and password information that
couldn't
ffb
 be gained from the NT SAM.

1) A user may have a dial-up ISP account with an account name and password
that is separate from their local\domain NT account.

2) Users may have RAS/PPTP access to domains other than the domain that the
user is a member of, also not stored in the SAM. (Vendor connections,
non-trusted domains, etc)

3) If an Administrator attempting to troubleshoot or set-up a users
workstation needs to dial in from the workstation and doesn't click the
'save password'  box, then he/she should be able to assume that his
password will not be saved on that users workstation.

4) Windows NT 'public access' machines, such as the machines available at
training classes, airports, etc..

WORKAROUND:
There does not appear to be any method to prevent this behavior from
occuring.

REPRODUCTION:
Reproduced on three Windows NT 4.0 workstations, and one Windows NT 4.0
Server.

Log on as a user, identify the SID of the user using getsid or any other
means. Use the LSA secrets code to dump the RasDialParams and
RasCredentials for the user.  Create a new dial up networking connection.
DONOT save the password.  After successfully connecting to the remote end,
re-dump the RasDialParams and RasCredentails entries.  The new successful
connection password will be saved in the RasDialParams value even though
you didn't check the 'save password' box.

Microsoft was notified of this one week ago.

Lisa O'Connor
Martin Dolphin
Joe Greene
Eric Schultze
Date: Sun, 22 Mar 1998 18:11:50 +0200
From: Noam Ben-Yochanan <noam@ZSOFT.COM>
To: BUGTRAQ@NETSPACE.ORG
Subject: Re: RAS 'save password' problems...

> ---------- Forwarded message ----------
> Date: Thu, 19 Mar 1998 14:09:44 -0800
> From: martin Dolphin <mdolphin@POBOX.COM>
> To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
> Subject: RAS 'save password' problems...
>
> THE PROBLEM:
> Windows NT allows users to save their RAS credentials by using the 'Save
> Password' checkbox when making a dial-up connection. Credentials saved in
> this manner are stored in the
> HKEY_LOCAL_MACHINE\SECURITY\Policy\Secrets\RasCredentials!SID#0 registry
> key.  These credentials can be enumerated using the LSA secrets code.  (As
> identified by Paul Ashton in a prior submission to NTBugtraq)

  I've written code using the RasGetEntryDialParams() function. Here's
Microsoft's description of this function:

---begin description---
The RasGetEntryDialParams function retrieves the connection information
saved by the last successful call to the RasDial or
RasSetEntryDialParams function for a specified phone-book entry.
---end description---

  Another function which is supposed to supersede this function is
RasGetCredentials(). Here's the description for this function:

---begin description---
The RasGetCredentials function retrieves the user credentials associated
with a specified RAS phone-book entry.
---end description---

  In both cases the clear-text password is a field in the retrieved
record. No need to access the regitry, no need to use the LSA secrets
code. I think Microsoft thought they should provide such a feature for
purposes of automatic dialup connections - to avoid the need for user
input. This might sound a bit funny, but if the password isn't saved, a
human has to enter it manualy, but a program can just use one of the
aformentioned functions. Microsoft seemingly makes a distinction between
the privilages of a user and those of a program (i.e. programmer).

Noam Ben-Yochanan
noam@zsoft.com
Date: Mon, 23 Mar 1998 14:41:29 -0800
From: martin Dolphin <mdolphin@POBOX.COM>
To: BUGTRAQ@NETSPACE.ORG
Subject: Re: RAS 'save password' problems...

At 12:04 AM 3/23/98 -0500, David LeBlanc wrote:
The way to disable this is to use the CachedLogonsCount registry value in
the HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon registry
key.  Default value is 10 if the key doesn't exist.  I keep my set at 1 so
only the first logon is cached.

NT does store the hashes and not clear text.  It store these credentials in
the HKLM\SECURITY\Policy\Secret
9c0
s area of the registry as NL$1 to NL$10  and
it stores the lanman hash followed by the NT hash followed by 3 bytes of
'status'. (as per Paul Aston's posting to NTBUGTRAQ)  I'd bet that these
hashes are not syskeyed.

>
>There are also a number of entries corresponding to previous logins by
>users.  There is a way to turn this behavior off, but I don't recall at the
>moment exactly what it is.
>
>Essentially, it is there to allow you to log on if the domain controller
>can't be reached.  I believe it stores hashes rather than clear-text.
>
>The RAS functionality can often be annoying as well - it tends to prompt me
>for my password even when I'm using a script (which of course contains the
>user-password pair in the clear).  Not sure why it thinks it needs it - I
>just leave it blank, but a less astute user would probably type in their
>actual password.
>
>
>David LeBlanc           |Why would you want to have your desktop user,
>dleblanc@mindspring.com |your mere mortals, messing around with a 32-bit
>                        |minicomputer-class computing environment?
>                        |Scott McNealy
>