From advisories@nmrc.org Wed Jan 16 01:09:14 2002 From: Information Anarchy 2K01 To: bugtraq@securityfocus.com, vulnwatch@vulnwatch.org Date: Mon, 14 Jan 2002 21:08:33 -0500 (EST) Subject: NMRC Advisory: OpenFile Win32 API Log Overwriting/Rewriting _______________________________________________________________________________ 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 [cyberiad@nmrc.org] 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. _______________________________________________________________________________