mailing list archives
Re: Windows NT and account list leak ! A new SID usage
From: dleblanc () MINDSPRING COM (David LeBlanc)
Date: Tue, 1 Feb 2000 13:44:10 -0800
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
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
- 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>).
dleblanc () mindspring com