BindView Security Advisory -------- Local Promotion Vulnerability in Windows NT 4 Issue Date: January 13, 2000 Contact: Todd Sabin <tsabinat_private> Topic: Problem in NtImpersonateClientOfPort system call on NT 4 Overview: Due to a flaw in the NtImpersonateClientOfPort Windows NT 4 system call, any local user on a machine is able to impersonate any other user on the machine, including LocalSystem. We have written a demonstration exploit which allows any user to spawn a cmd.exe window as LocalSystem. Affected Systems: All Windows NT 4.0 systems up to and including SP6a. We tested our exploit on W2K RC2, and it was not vulnerable. Impact: All Windows NT 4.0 machines are subject to compromise by any user who can log in locally and run arbitrary programs. This may lead to Domain Admin access, if Domain Admin credentials are on the machine. In the case of Terminal Server, it should also be possible to use the credentials of other users on the compromised machine to take actions across the network as those other users. This has not been tested, however. Details: Windows NT includes a mostly undocumented feature called Lpc ports, which are used for making Local Procedure Calls on a machine. One of the system apis used with Lpc ports is NtImpersonateClientOfPort, which allows a server to act in the security context of the client who is calling it. However, the interface to the call lets the server specify which client to impersonate based on process and thread IDs. The kernel does do some sanity checking of the parameters to verify that the call is legitimate, but it's possible to fake it. First it verifies that the port you're trying to impersonate on actually has an outstanding request. This is easy to satify by making a request to it ourselves. Next, it checks that the message ID in the request matches the outstanding message ID in the thread you're asking to impersonate. This is also easy to satisfy, because if a thread is _not_ making a request, it's outstanding message ID will be zero. So, as the server, when the request comes in, we just change the pid and tid to the ones we want, and change the Message ID to 0. Once we're impersonating we can do whatever we want as that user. The pseudo-code for our exploit works like this. There are two threads. Server thread Client thread NtCreatePort NtReplyWaitReceivePort... NtConnectPort... (returns) NtAcceptConnectPort NtCompleteConnectPort NtReplyWaitReceivePort... (returns) NtRequestWaitReplyPort... (returns) modify the LpcMessage received in the request so that the process and thread ids point to the thread we want, and change the message id to 0. NtImpersonateClientOfPort At this point, we're running under the token of the thread we specified above. For our exploit, we choose to impersonate a thread of lsass. The reason has to do with the privileges that lsass has enabled. When impersonating, it seems that the impersonation token only gets those privileges that are _enabled_ in the client at the time of impersonation. Privileges that are disabled in the client, are not put into the impersonation token, even in a disabled state. Now, lsass happens to have the CREATE_TOKEN privilege enabled, so we can impersonate lsass, and use that privilege to create a new token for ourselves based on the lsass impersonation token, but with _all_ privileges enabled. We can then launch another process under that token. So to continue: // get the information about the current token. // TOKEN_USER, TOKEN_GROUP, etc. (esp. TOKEN_PRIVILEGES) NtOpenThreadToken GetTokenInformation // (several times) // Add _all_ privileges to our TOKEN_PRIVILEGES struct // all user space, preparing for NtCreateToken NtCreateToken // with info from the lsass token, except that // all privileges are enabled Finally. We have our token. Now, we can CreateProcessAsUser with that, except that there are a couple more hoops to jump through. CreateProcessAsUser requires more privileges than lsass had enabled, so we don't currently have them, however, our new token does! So, we can just impersonate the new token. But again, that's not enough. CreateProcessAsUser checks for the privileges in the _process_ token, ignoring any impersonation token. So as a final step, we change the new token to be our primary process token. ImpersonateLoggedOnUser NtSetInformationProcess (... ProcessAccessToken ...) CreateProcessAsUser and we're finally there. Recommendations: Install the hotfix from Microsoft. Limit local logon privileges, if possible. References: Microsoft's security bulletin: http://www.microsoft.com/Security/Bulletins/ms00-003.asp Microsoft's Hotfix: Intel: http://www.microsoft.com/Downloads/Release.asp?ReleaseID=17382 Alpha: http://www.microsoft.com/Downloads/Release.asp?ReleaseID=17383 Microsoft's Knowledge Base article: http://support.microsoft.com/support/kb/articles/q247/8/69.asp (may take a couple days to appear) For more information on the LPC ports APIs, see Undocumented Windows NT, ISBN# 0-7645-4569-8, Chapter 8. The rest of the book isn't bad either.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:28:02 PDT