Re: Windows NT and account list leak ! A new SID usage

[dleblanc () MINDSPRING COM (David LeBlanc)]

At 02:57 AM 2/1/00 -0000, Pascal Longpre wrote:
> This may not be new but I haven't seen it anywhere else so
> here it is.

No, it's not new.  The ISS Scanner has done exactly this for about 2-3
years now, using the same API call you mention.  I think several other
people, including Tim Newsham, figured it out around the same time.

> - Description -
> It is possible to list the whole user list of a domain by
> querying any workstation on that domain.

You can verify this by trying LookupAccountSid() (or LookupAccountName())
using a fully qualified user name against a given system.  You'll find that
any member server can map SIDs to names and vice-versa for any system in
their trust heirarchy.  If you think about how log ons work, this all makes
sense.

> Even if the domain
> controller is hidden behind a firewall or has IP filtering
> enabled, the list comes out gracefully since the
> workstation forwards the query for you.

It is useful to determine what account domains a border machine is talking
to.  I use this functionality all the time to locate systems that are
dual-homed that ought not be.

> I suspect that this may even work on a workstation
> connected to it's DC through a VPN but I haven't tested it
> yet.

It should.

> - Explanations -
> The idea is to get the workstation to spit it's domain SID
> with the LsaQueryInformationPolicy() function. Normally,
> that fonction would require the "GENERIC_READ |
> GENERIC_EXECUTE" access rights in order to work but I
> discovered that by simply using the "MAXIMUM_ALLOWED"
> access right it works through the good old null session.

If you look in the documentation, and use the rights that are exactly
required to make this function call at this level, and use those, it works
better.  The API is fully documented in terms of what access is required to
get which bits of info.  Please note that you cannot make this function
call on Windows 2000 across a null session.  BTW, the documentation used to
be kept in an obscure .hlp file in the SDK, but is now documented along
with everything else in the most current SDK.

> - Exploitation -
> I wrote a small program called "dom2sid" demonstrating
> this. It should be available shortly on the securityfocus
> free tools list. It returns the computer/domain names and
> SIDs. You can then feed this to the popular sid2user tool
> and get the whole user list.If both SIDs are equal, you
> found a DC.

This is true.  I've been aware of a number of tools that are out there that
have done this same thing for a long time.

> - Fix -
> The "restrict anonymous" solution provided by Microsoft
> doesn't help here. The only way I was able to stop this
> behavior was to use a program called fixpol.exe. Don't ask
> me where I found that one, I don't remember...

Phil Brass, currently with ISS, wrote it.  It sets the DACL on the LSA.  A
very nice piece of code.  You can also stop this particular method from
functioning by upgrading to Windows 2000, and Windows 2000 also has the
capability to set RestrictAnonymous=2, which denies null sessions
completely.  However, it isn't a good idea to do this to a domain
controller in a mixed domain, but I've run with it that way on my
workstations and member servers for some time and haven't noticed any
problems.  Windows 2000 hands out a lot less information to a null session
than NT 4.0.

The real solution is to require strong passwords, with a reasonably short
change interval, so that even if someone does get your user list, it
doesn't get them anywhere.  I'd also use some form of port filtering to
disallow access to 137-139 from the internet (and 445 on Windows 2000), and
several of my friends tell me Black Ice is a nice product (I haven't tried
it, YMMV, <#include std.disclaimer>).

David LeBlanc
dleblanc () mindspring com