[NT] OpenFile Win32 API Log Overwriting/Rewriting

From: support@securiteam.com
Date: 01/16/02 

From: support@securiteam.com
To: list@securiteam.com
Date: Wed, 16 Jan 2002 20:20:53 +0100 (CET)

The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

When was the last time you checked your server's security?
How about a monthly report?
http://www.AutomatedScanning.com - Know that you're safe.
- - - - - - - - -

  OpenFile Win32 API Log Overwriting/Rewriting
------------------------------------------------------------------------

SUMMARY

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 that Norton Personal Firewall 2001 behaves
in the same. 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.

DETAILS

Vulnerable systems:
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

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. In addition, 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

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.

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.

Vendors responses:
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 recommend 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> http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/tools/iis4cl.asp

Microsoft has also published Knowledge Base article
<http://www.microsoft.com/technet/support/kb.asp?ID=315986> 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/>
http://securityresponse.symantec.com/, when available."

 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. We hope that not only
vendors but also forensics personnel and auditors will find this
information handy.

ADDITIONAL INFORMATION

The information has been provided by <mailto:advisories@nmrc.org>
Information Anarchy 2K01.

========================================

This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

====================
====================

DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.

Relevant Pages