ChkLock: Why It's Interesting

ChkLock: Why It's Interesting


ChkLock is interesting in two ways: it does something other tools do not, and it does so in apparent violation of the rules set forth in the platform SDK documentation.

Why don't other tools do this?

This is a fair question, especially since ChkLock's workings aren't rocket science. I expect that nobody has done this simply because the API documentation is misleading. In fact, it specifically says you can't do what ChkLock does.

In my edition of the SDK (MSDN Library Visual Studio 6.0 release, which came with my copy of Visual C++ 6.0), the documentation for NetUserModalsGet() says, "Only members of the Administrators or Account Operators local group can successfully execute NetUserModalsGet." To say the least, this seems to indicate that there are security controls on who can do what with this API call. I was surprised to find that this was not the case. It turns out that this is not a new issue. As early as April 1999, the Microsoft Knowledge Base contained an article (Q129457) entitled, "RestrictAnonymous Access Enabled Lets Anonymous Connections Obtain the Password Policy."

This article makes reference to the fact that "anonymous access to the password policy information is used by Windows NT to provide end-users detailed error information under specific circumstances." In particular when a user attemps to change the password on his or her account, a message containing details of the password policy appears. The message is of the form "your password must be at least X characters long. Your new password cannot be the same as any of your previous Y passwords." Ironically, Microsoft's resolution to the problem was to issue a patch (included in Service Pack 4 and greater) which fixed the error message, but not the problem itself.

While it's easy to criticise Microsoft for failing to address the problem, changing the API so that access to it is indeed restricted to administrators would probably interfere with other critical operations. Nonetheless, I thought the documentation should be fixed so that it corresponds with what I have observed. Here is a copy of the note I submitted to Microsoft (on August 15th) through their web form for comments and bug reports:

I was working with the Windows networking API, and I
discovered that I was able to get valid responses at
all four levels of NetUserModalsGet() from remote
machines, having authenticated only with a NULL
NetBIOS session.  This seemed contrary to the documentation
for that API, which states, "only members of the
Administrators or Account Operators local group can
successfully execute NetUserModalsGet."
 
So I built a little utility to test this, and I am
able to reproduce the results on NT and Win2K machines
which have anonymous connections enabled.
 
I've done some research, and I haven't found another
tool that does this.  AccountPolicy by Darren Tucker
( http://www.zipworld.com.au/~dtucker/accountpolicy.html )
makes the same API call, but doesn't implement passing
a server name as a parameter, and so he hasn't got results
relating to anonymous NetBIOS sessions.  I've included
the source to my utility (just pop the five short files
into a single Win32 console app workspace, link with
NETAPI32.LIB, and build).  Other Windows auditing tools
(Cerberus Internet Scanner, for example) don't provide
this functionality.
 
I plan to share my results, since they're interesting,
but I don't regard this as a security worry.  Prudently
administered machines are immune to this sort of
information-gathering, it doesn't give anyone access
to anything they couldn't already have gotten, and
the information isn't that critical anyway.

It is counterintuitive, however, that I should be able
to get this information, given the excerpt from the docs
that I cited above, and I thought I should mention it.

I'd be interested to know if others have called this to
your attention before, or if you feel I am misreading the
documentation.  I have been able to use this from Windows
NT and Windows 2000 machines to gather information
from Windows NT and Windows 2000 machines.
 
Thanks in advance for your time.
 
Peyton Engel

Berbee
5520 Research Park Drive
Madison, WI 53711
pengel@berbee.com
608.298.1032
Fax 608.288.3007
 
Berbee...putting the E in business

Since that time, there has been a reorganization of some of the technical materials on Microsoft's web site. Among the changes is a revision to the wording of the documentation for NetUserModalsGet(). I have never heard from Microsoft in response to my report-- I didn't really expect to, just because it's not that big a deal-- and I don't think I had anything to do with inspiring the change. The NetUserModalsGet() page (available at http://msdn.microsoft.com/library/psdk/network/ntlmapi2_42es.htm now reads:

This is still somewhat misleading, at least as far as NT goes. No authentication whatsoever is required, as long as anonymous access is not restricted through other means. So authenticated users can successfully execute the call, but unauthenticated ones can also, unless specific precautions are taken.

But isn't it amoral to be releasing new exploits?

There has always been controversy about releasing information concerning security vulnerabilities. On the one hand, if they are not publicised, vendors have little incentive to fix their products. At the same time, unleashing information about serious problems in products on which people rely is itself a risk.

I don't think this is much of a vulnerability. In the first place, it doesn't give anyone unauthorized access to anything the operating system doesn't allow. Moreover, that functionality has always been available to anyone willing to make the proper library calls. True, there aren't tools that I know of for getting this information, but that doesn't mean unequivocally that none exist, and the fact remains that the API and the operating system permit the disclosure of the password policy. Not only that, but I have notified the vendor about the issue, and the fact that I intend to share my findings, and they haven't expressed any concern about it. Presumably this is because they also feel it isn't anything to worry about: if you are following their recommendations, ChkLock won't divulge anything whatsoever about your system.

It is true that ChkLock could help a potential intruder in planning a password-guessing attack, or at least in determining how vulnerable a given system is to such an attack. At the same time, however, if a host is accessible to ChkLock, it is also "vulnerable" to a large number of other information-gathering and password-guessing attacks; ChkLock is the least of the administrator's worries. Microsoft has long recommended disabling anonymous connections, and in any case, most people put their NT servers behind some sort of firewall or packet filter to protect them from Internet-based intrusions. So a prudently administered server is not exposed at all by ChkLock.

Finally, ChkLock is an information-gathering tool, not an exploit. It should be most helpful to network administrators who want to compile information about how password policies are implemented on their networks. It doesn't do anything that Windows NT isn't specifically designed to do. If there's a weakness here, I view it as a problem in the Platform SDK documentation, not in the security of Windows.

Back to the main ChkLock page


This page is maintained by Peyton Engel.
Last updated 13 October 2000