COMMAND

	Default files ACL\'s and non exclusive FILE_OPEN may lead  to  log  file
	access

SYSTEMS AFFECTED

	 Windows NT 4.0 with SP6a

	 Windows 2000 Server with SP2

	 Windows 2000 Professional with SP2

	

	 Tested with :

	

	 IIS 4 and 5

	 Norton Internet Security 2001

	

PROBLEM

	Cyberiad     [cyberiad@nmrc.org]     [http://www.nmrc.org]      reported
	vulnerabilities in the follwing systems :
	

	IIS4:

	

	The parameters used by inetinfo.exe to open the daily IIS  extended  log
	file allow shared write access to the log file  by  other  applications.
	This occurs as inetinfo opens the log  file  with  both  FILE_SHARE_READ
	and FILE_SHARE_WRITE share access  parameters.  Other  applications  can
	then use the OpenFile Win32 API call  with  an  (OF_REOPEN|OF_READWRITE)
	action and attributes parameter, to re-open the current day\'s log  file
	and overwrite entries without stopping the  W3SVC.  This  is  especially
	important in those cases where the  attacker  does  not  possess  rights
	afforded by the DACL on the Service Control  Manager  database  to  stop
	the W3SVC service.
	

	As an example, an attacker launching the UNICODE attack against  an  IIS
	4 server is able to wipe the log file without using an access  elevation
	technique to gain SYSTEM privileges to stop the W3SVC service.  Instead,
	all that is required are IUSR privileges, the  rights  obtained  by  the
	UNICODE attack.
	

	Inetinfo\'s file pointer into the log  file  is  not  affected;  logging
	continues from the last point in the file.
	

	IIS5:

	

	Though  inetinfo  opens  the  log   files   with   FILE_SHARE_READ   and
	FILE_SHARE_WRITE share access parameters, the default  file  permissions
	on IIS 5 log files prohibit lower-privilege  users  from  modifying  the
	log files. However, if they are able to elevate their  access  and  gain
	Administrator or SYSTEM privileges they are still  able  to  modify  the
	log files without stopping the W3SVC service.
	

	Inetinfo\'s file pointer into the log  file  is  not  affected;  logging
	continues from the last point in the file.
	

	

	NIS 2001:

	

	Similarly, Symantec\'s Norton Internet Security 2001 opens the files,
	

	  iamfw.rel

	  iamalert.rel

	

	with both FILE_SHARE_READ and FILE_SHARE_WRITE share access  parameters.
	This allows any other application to use the  OpenFile  Win32  API  call
	with  (OF_REOPEN|OF_READWRITE)  action  and  attributes   parameter   to
	re-open the log files and overwrite entries without stopping the  Norton
	Internet Security service. Even though the log file contents  appear  to
	be encrypted, this technique can be used to clear  the  entries  in  the
	log files. This does not clear the alerts in the application\'s  dialogs
	until the Norton Internet Security service is restarted.
	

	Since the default NTFS permissions permit any  member  of  the  Everyone
	group to modify this file, a lower-privilege  user,  who  is  prohibited
	from stopping services due to the DACL on the  Service  Control  Manager
	database, can still open the log files with an  (OF_REOPEN|OF_READWRITE)
	action and attributes parameter and modify the log files  to  clear  any
	alerts or indications of attacks.
	

	Though this has not been confirmed, it  is  expected  that  NIS\'s  file
	pointer into the log files is not affected; logging would continue  from
	the last point in the file.

SOLUTION

	

	Microsoft:

	

	Microsoft was contacted on Jan 07, 2002 and  confirmed  that  the  issue
	affects default installations of IIS 4 but not IIS  5.  In  response  to
	the issue, Microsoft will include a check for log  file  permissions  in
	an upcoming release of the IIS Lockdown Tool.  As  well,  they  recomend
	that administrators  follow  the  practices  in  the  IIS  4.0  Security
	Checklist section, \"Set Appropriate Log File ACLs\", located at,
	

	http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/tools/iis4cl.asp

	

	Microsoft has also published Knowledge Base article Q315986  to  provide
	advice on the issue.
	

	Symantec:

	

	Symantec was contacted on Jan 07, 2002  and  has  issued  the  following
	response,
	

	\"This  issue  is  rated  as  a  low  risk  exposure,  however  Symantec
	appreciates NMRC bringing it to our attention,  we  are  evaluating  the
	impact on our products. We are currently  testing  an  update  to  fully
	secure the firewall logs from any possibility  of  unauthorized  access.
	Product updates will be  available  as  soon  as  they  are  tested  and
	approved.  Additional  information  will  be  posted  to  the   Symantec
	Security Response website,  http://securityresponse.symantec.com/,  when
	available.\"
	

	 

	Solution/Workaround

	-------------------

	

	Open the log files with only FILE_SHARE_READ access parameters.
	

	Use NTFS and ensure that file system permissions prohibit  write  access
	to all but privileged users or groups.  Though  this  will  not  counter
	attacks that provide command execution with permissible  privileges,  it
	will protect the integrity of the log files from  attacks  that  provide
	access with lower privileges.
	

	

	Comments

	--------

	

	This is obviously not a specific attack itself, but a technique used by an

	attacker to help cover their tracks. As two vendors out of two were found

	to be using the FILE_SHARE_READ and FILE_SHARE_WRITE parameters when

	opening sensitive files, it should be obvious that other vendors are

	probably handling things in a similar manner. Hopefully not only vendors

	but forensics personnel and auditors will find this information handy.

	

	This advisory has been released under Information Anarchy -

	http://www.nmrc.org/InfoAnarchy/

	

	Additionally, this advisory *WILL NOT* be posted to NTBugtraq in support

	of w00w00 - Russ get a fucking clue!

	

	

	Greetz

	------

	

	Thanks to Simple Nomad for recommending strace for Win32. This was

	instrumental in identifying the call in inetinfo to open the log files.

	Identification of the issue in Symantec\'s products was accomplished using

	IDA Pro by DataRescue and Soft-Ice by Compuware.

	

	

	Copyright

	---------

	

	This advisory is Copyright (c) 2002 NMRC - feel free to distribute it

	without edits but fear us if you use this advisory in any type of

	commercial endeavour.