-----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-----