Everhart,Glenn From: Luke Kenneth Casson Leighton [lkcl@REGENT.PUSH.NET] Sent: Thursday, April 30, 1998 8:41 AM To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM Subject: Re: name of built-in administrator On Tue, 28 Apr 1998, David LeBlanc wrote: > 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. the reason that null sessions [to IPC$] are allowed is so that non-critical information can be made available (such as browsing information). there are info levels to all IPC$ (and dce/rpc \PIPE\some_service calls). certain levels require no user/pass/domain identification (usually info levels 0 and 1 or 100 and 101) which implies that an anonymous (null session) connection is accepted; some levels require user/pass/domain identification (levels around 1-2, or 101 to 102); some require administrator rights (usually levels 3, 103 and above and 1001 and above). unfortunately, something went wrong somewhere with the permissions for the above accounts. i therefore suspect this to be another manifestation of the "red button" bug, which means that it would be useful for someone to confirm this by setting the "RestrictAnonymous" registry entry. > 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. obviously, setting "RestrictAnonymous" doesn't help you against malicious users with an account: that would require something like "RestrictUser", but at what point do you draw the line? do you cover the SamrQueryDisplayInfo call (which is another security hole as far as malicious users are concerned), too? i think microsoft have their work cut out on this one...