COMMAND

	Doman trust relationship may be fooled to gain elevated priviledge

SYSTEMS AFFECTED

	 Windows NT 4 sp6a

	 Windows 2000 sp2

PROBLEM

	Aelita Software [http://www.aelita.com] and  Michel  Trépanier  reported
	as          published          in           Microsoft           advisory
	[http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/MS02-001.asp]
	:
	

	Trust relationships are created  between  Windows  NT  or  Windows  2000
	domains to allow users in  one  domain  to  access  resources  in  other
	domains without  requiring  them  to  authenticate  separately  to  each
	domain. When a user in a trusted domain requests access  to  a  resource
	in a trusting domain, the trusted domain supplies authorization data  in
	the form of a list of Security  Identifiers  (SIDs)  that  indicate  the
	user\'s identity and group memberships. The trusting  domain  uses  this
	data to determine whether to grant the user\'s request.
	

	A vulnerability exists because the trusting domain does not verify  that
	the trusted domain is actually authoritative for all  the  SIDs  in  the
	authorization data. If one of the SIDs in the list identified a user  or
	security group that is not in the trusted domain,  the  trusting  domain
	would accept the information and use it for  subsequent  access  control
	decisions.  If  an  attacker  inserted  SIDs  of  his  choice  into  the
	authorization  data  at  the  trusted  domain,  he  could  elevate   his
	privileges  to  those  associated  with  any  desired  user  or   group,
	including the Domain Administrators group for the trusting domain.  This
	would enable the attacker to gain full Domain  Administrator  access  on
	computers in the trusting domain.
	

	Exploiting  this  vulnerability  would   be   difficult,   and   require
	administrative  privileges  on  the  trusted  domain,  as  well  as  the
	technical wherewithal to modify  low-level  operating  system  functions
	and data structures.
	

	Windows NT 4.0 provides no mechanism by which additional SIDs  could  be
	added to authorization data. To exploit the vulnerability,  an  attacker
	would need to develop and install custom operating system components  to
	add the SIDs. Windows 2000 does  provide  a  mechanism  for  introducing
	additional SIDs into authorization data, known as  SIDHistory.  However,
	there is no programming interface that would allow an  attacker  –  even
	with administrative rights  –  to  introduce  a  desired  SID  into  the
	SIDHistory information; instead, an attacker would  need  to  perform  a
	binary  edit  of  the  data  structures   that   hold   the   SIDHistory
	information. Microsoft has developed a mechanism  called  SID  Filtering
	that eliminates the vulnerability and adds  further  protection  between
	trusting domains. When installed and enabled on the  domain  controllers
	of a trusting domain, SID Filtering causes the  system  to  inspect  all
	incoming authorization data and remove any SIDs that do not  identify  a
	user or security group that is defined in the trusted domain.
	

	There are, however, tradeoffs associated with using  the  SID  Filtering
	mechanism. These are summarized in the FAQ and Caveats  sections  below,
	and are discussed in detail in Microsoft Knowledge Base article  Q289243
	and  in  a  technical  white  paper  that   Microsoft   strongly   urges
	administrators to read before using SID Filtering.  This  is  especially
	important in the  case  of  administrators  who  are  in  the  midst  of
	migrating their networks from Windows NT 4.0 to Windows 2000.
	

	Mitigating factors:
	

	The attacker would need to have domain administrator privileges  in  the
	trusted domain in order to exploit  the  vulnerability.  The  attacker’s
	domain would need to already be trusted by the  target  domain,  or  the
	target domain’s administrator would need to  approve  the  establishment
	of a new trust relationship. There is no capability for the attacker  to
	unilaterally initiate a trust relationship with another domain or  cause
	it to trust the attacker’s domain. The attacker  would  need  to  modify
	operating system components and data.

SOLUTION

	NT4 :
	

	http://www.microsoft.com/downloads/release.asp?ReleaseID=31240

	

	2000 :
	

	http://www.microsoft.com/windows2000/downloads/critical/q311401/default.asp