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 dleblancat_private
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:32:52 PDT