-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 @stake Inc. www.atstake.com Security Advisory Advisory Name: NTFS Hard Links Subvert Auditing (A081602-1) Release Date: 08/16/2002 Application: Windows NT 4.0, Windows 2000 SP2 Platform: Windows NT 4.0, Windows 2000 SP2 Severity: File Auditing can be subverted Author: Chris Wysopal (cwysopal@atstake.com) Vendor Status: Vendor has service pack update (SP3) for Windows 2000 CVE Candidate: CAN-2002-0725 Reference: www.atstake.com/research/advisories/2000/a081602-1.txt Overview: The NTFS filesystem supports hard links. A hard link is another directory entry that points to the same physical file on disk. This allows you to have multiple pathnames to the same file within a partition. Once the hard link is created any file I/O operations on the hard link act as if they were done on the original file. The ACL of the original file are used. The auditng entries for the original file are used. The auditing mechanism of Windows NT and Windows 2000 does not understand hard links so it produces some erroneous results. The results allow an attacker to access files through hard links such that the name of the file being accessed does not appear in the security event log. Instead, the file name of the hard link appears in the event log. The hard link can be deleted after accessing the file thus eliminating any trace of the file I/O activity. Since the ACL on the file is enforced, the hard link does not grant the user any extra privileges. The hardlink does however allow a user to access the file within her privileges without leaving an audit trail. Since this problem has existed for many years all archived audit logs are suspect. Detailed Description: NTFS has always supported hard links in order to support the POSIX subsystem which requires them. They are seldom used by NT users. Windows NT 3.51 and NT 4.0 have the Win32 API function BackupWrite() which can create hardlinks. Windows 2000 introduced a new, simpler Win32 API function CreateHardLink(). The usage of these functions, as well as a sample hard link creation program, ln, were documented by Microsoft in a knowledge base article: Q234727 HOWTO: Create Hard Links in Windows NT and Windows 2000 http://support.microsoft.com/support/kb/articles/Q234/7/27.ASP (Unfortunately this KB article has been deleted.) Note: If you are going to compile and use the Microsoft example you will want to make one small change. The CreateFile function does not need the FILE_WRITE_ATTRIBUTES flag. Elimination of this flag allows you to create hardlinks without creating a WriteAttributes access event. I made this change to the ln.exe I run for my examples below. If full auditing of a file is enabled, one entry will be created in the security event log when the hard link is created. This event is ReadAttributes. This is the same audit event that is generated if a user views the properties of a file. If ReadAttributes auditing is not enabled then no auditing event will be generated when the hard link is created. It is worth noting that since the ReadAttributes Success event is an event that occurs when the properties of a file are read, it is an event that is not often audited. If this event is not audited there is no trace of the hard link creation in the event log. For the example however we will assume the most secure and stringent auditing of all events. Example: Using Windows 2000. 1. Create a file c:\audited\foo.txt 2. Enable auditing of all events for c:\audited\foo.txt 3. Create a hard link named c:\temp\link.txt that links to c:\audited\foo.txt using ln.exe compiled from KB Q234727 ln c:\audited\foo.txt c:\temp\link.txt 4. Security log will show a Success Audit: Object Open: Object Server: Security Object Type: File Object Name: c:\audited\foo.txt New Handle ID: 48 Operation ID: {0,14421507} Process ID: 1148 Primary User Name: user Primary Domain: DOMAIN Primary Logon ID: (0x0,0xA8F7) Client User Name: - Client Domain: - Client Logon ID: - Accesses SYNCHRONIZE ReadAttributes Privileges - To the audit reviewer it looks like the user has read the properties of c:\audited\foo.txt. There is no trace that c:\temp\link.txt is linked to foo.txt. 5. Read the file c:\temp\link.txt Security log will show a Success Audit: Object Open: Object Server: Security Object Type: File Object Name: c:\temp\link.txt New Handle ID: 96 Operation ID: {0,14425896} Process ID: 1364 Primary User Name: user Primary Domain: DOMAIN Primary Logon ID: (0x0,0xA8F7) Client User Name: - Client Domain: - Client Logon ID: - Accesses READ_CONTROL SYNCHRONIZE ReadData (or ListDirectory) ReadEA ReadAttributes Privileges - To the audit reviewer it looks like the user has read the data of c:\temp\link.txt when they have really read the data in foo.txt. An audit event was recorded when the file was read but it contains the *wrong* file name. There is no audit entry for the link creation so there is no correlation in the audit log connecting the new file name with the original file that is being audited. Because of the lack of connection we were able to read the contents of the file c:\audited\foo.txt without a ReadData audit event occuring on that file name. After the file has been read or copied the hard link can be deleted thus eliminating any traces of malfeasance. Vendor Response: The vendor was informed of this issue on 8/15/2000. It was determined that the issue was too risky to fix in a hotfix patch so the fix was scheduled for Windows 2000 SP3. XP and .Net server beta were fixed before they shipped. The solution was to this vulnerability was to create a new "Hard link creation attempt" audit event. This creates a audit entry that connects the new hard link file name to the target file name. The audit entry looks like this: Event Type: Success Audit Event Source: Security Event Category: Object Access Event ID: 568 Date: 8/5/2002 Time: 6:29:32 PM User: DOMAIN\user Computer: COMPUTER Description: Hard link creation attempt: Primary User Name: user Primary Domain: DOMIAN Primary Logon ID: (0x0,0xFF10) File Name: C:\audited\foo.txt Link Name: C:\temp\link.txt A tool has also been created so that you can search for hard links that already exist on your system prior to installing SP3. This is recommended if you are auditing sensitive files on a system that has multiple user access. http://www.microsoft.com/windows2000/techinfo/reskit/tools/new/ hlscan-o.asp note: URL wrapped Recommendations: Apply the fix. There really is no workaround to the problem. All audit logs created before installing the fix are suspect. If you are auditing sensitive files on a system that has multiple user access you should search for all hard links that exist on your system prior to installing the patch. Common Vulnerabilities and Exposures (CVE) Information: The Common Vulnerabilities and Exposures (CVE) project has assigned the following names to these issues. These are candidates for inclusion in the CVE list (http://cve.mitre.org), which standardizes names for security problems. CAN-2002-0725 NTFS Hardlinks Subvert Auditing @stake Vulnerability Reporting Policy: http://www.atstake.com/research/policy/ @stake Advisory Archive: http://www.atstake.com/research/advisories/ PGP Key: http://www.atstake.com/research/pgp_key.asc Copyright 2002 @stake, Inc. All rights reserved. -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.3 iQA/AwUBPVz/cUe9kNIfAm4yEQLpQACgrY1Nj0jrpUS9nzYllcBJJcSNTE4AoJ3L ZqLkXT79NMRqyDVEiv6+fsfP =/C7y -----END PGP SIGNATURE-----