_______________________________________________________________________________
I N F O R M A T I O N A N A R C H Y 2 K 0 1
www.nmrc.org/InfoAnarchy
Nomad Mobile Research Centre
A D V I S O R Y
www.nmrc.org
Cyberiad [cyberiadat_private]
14Jan2002
_______________________________________________________________________________
Platforms : Windows NT 4.0 with SP6a
Windows 2000 Server with SP2
Windows 2000 Professional with SP2
Application: IIS 4 and 5
Norton Internet Security 2001
Severity : Low
Synopsis
--------
This advisory documents the use of file sharing parameters used when
opening application security log files. When combined with some
application's default file system permissions, their use allows a
lower-privilege attacker, who is unable to stop services that have locked
the files, to modify log files and obfuscate attacks. This behavior is in
use by Microsoft's IIS 4 and Symantec's Norton Internet Security 2001 and
preliminary testing indicates also Norton Personal Firewall 2001. Though
Microsoft's IIS 5 opens its log files with the same sharing parameters,
default permissions prohibit lower-privilege accounts from modifying the
logs while the service is running.
Other products may also follow these practices but have not been tested.
Details
-------
By default, Microsoft's Internet Information Server 4 and 5 log all HTTP
requests to text files in W3C Extended Log File Format in the directory,
%WinDir%\System32\LogFiles\W3SVC1
The log filenames follow the format,
exyymmdd.log
where yy = year
mm = month
dd = day
where a file is created for each day.
While the web server is running, a user is unable to delete the current
day's log file as it is locked by the service (W3SVC). Instead, the
service must be stopped before the current day's log file may be deleted.
For IIS 4 running on Windows NT4 SP6a, permissions on the log files allow
for members of the Everyone group to read, write, execute and delete the
files. As well, default file system permissions permit the Internet Guest
account full control over the log files. However, the DACL associated with
the Service Control Manager database prohibits members of the Everyone group
from stopping services, in particular, the W3SVC service.
The permissions on IIS 5 log files prohibit modification by all except
Administrators, Power Users and SYSTEM. Similarly, the DACL associated
with the Service Control Manager database prohibits members of the Everyone
group from stopping services.
Norton Internet Security 2001 logs attacks and alerts to the files,
\Program Files\Norton Internet Security\iamfw.rel
\Program Files\Norton Internet Security\iamalert.rel
respectively. While the Norton Internet Security service is running,
neither log file can be deleted. If this service is stopped, the log files
can be deleted and upon service restart, the files are re-created. When
installed on an NTFS volume, default permissions on these files permit
members of the Everyone to have Full Control.
Tested configurations
---------------------
Testing was performed with the following configurations:
IIS 4 on Microsoft Windows NT Server 4.0
Microsoft Windows NT Service Pack 6a
IIS 5 on Microsoft Windows 2000 Server
Microsoft Windows 2000 Server Service Pack 2
NIS 2001 on Microsoft Windows 2000 Professional
Microsoft Windows 2000 Service Pack 2
Problems(s) Reported
--------------------
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.
Vendor Response
---------------
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.
_______________________________________________________________________________
This archive was generated by hypermail 2b30 : Tue Jan 15 2002 - 23:36:41 PST