[6626] in bugtraq
Re: name of built-in administrator
daemon@ATHENA.MIT.EDU (David LeBlanc)
Tue Apr 28 23:55:45 1998
Date: Tue, 28 Apr 1998 23:06:03 -0400
Reply-To: David LeBlanc <dleblanc@MINDSPRING.COM>
From: David LeBlanc <dleblanc@MINDSPRING.COM>
X-To: Vic Anderson <Vic.Anderson@itls.com>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <0142F8C1333BD111BCEC00A0C93EE957055FAD@logan.itls.com>
Not true. SP3 merely fixed the ability to enumerate users with the
NetUserEnum() call via a null session. This technique requires knowing the
name of at least one valid user, and is a little less straightforward. In
fact, the KB article which covers the RestrictAnonymous setting obliquely
mentions this capability.
At 02:10 PM 4/28/98 -0400, Vic Anderson wrote:
>This was supposedly fixed in service pack 3, check out the release notes
>for Service Pack 3, also check out KB article Q143474 concerning
>limiting NULL session connections.
>
>-----Original Message-----
>From: David LeBlanc [mailto:dleblanc@MINDSPRING.COM]
>Sent: Tuesday, April 28, 1998 1:12 PM
>To: BUGTRAQ@NETSPACE.ORG
>Subject: Re: name of built-in administrator
>
>
>At 10:21 AM 4/28/98 +0400, Evgenii Borisovich Rudnyi wrote in NTBUGTRAQ:
>>While learning what SID is, I have written two utilities, user2sid and
>>sid2user, which are actually command line interfaces to WIN32
>functions,
>>LookupAccountName and LookupAccountSid. So, no hacking, just what is
>>permitted by MS.
>
>[which allows users to be extracted]
>
>This is documented (to some extent) in a knowledge base article. I
>wrote
>an app which grabs all the users (and accounts for why the ISS NT
>scanner
>5.0 always gets the admin user, no matter what), and advised Microsoft
>that
>I thought this was something that should be fixed.
>
>At this time, there is no fix for this, except to filter connections to
>port 139. I've tried a couple of things I thought would fix it, but
>found
>that it caused severe problems. So, at the moment, if you can get a null
>session, you can dump all the users, groups, and machine accounts. You
>can
>also cause some other problems, but they are a little arcane, and MS has
>been advised (I only found it this morning, trying to make a fix for
>this).
> There isn't anything you can do to stop the other problems, except
>filter
>139, so...
>
>IMHO, we should be able to control whether or not NT accepts null
>sessions.
>
>It is possible they are doing something about this in SP4 - they didn't
>tell me whether, how or when they planned to fix it.
>
>
>David LeBlanc
>dleblanc@mindspring.com
>
David LeBlanc
dleblanc@mindspring.com
