Message-ID: <096A04F511B7FD4995AE55F13824B8332127F5@banneretcs1.local.banneretcs.com>
Date: Thu, 8 Mar 2007 23:31:54 -0500
From: "Roger A. Grimes" <roger@...neretcs.com>
To: "3APA3A" <3APA3A@...URITY.NNOV.RU>, <bugtraq@...urityfocus.com>,
	<full-disclosure@...ts.grok.org.uk>
Subject: RE: Microsoft Windows Vista/2003/XP/2000 file management security issues

I'm missing something here.

In order for Alice to Take Ownership of Bob's private folder she would
have to have Full Control in the parent Public folder or Bob's child
folder, not just the Write/Modify permission. If Alice deletes Bob's
folder (which she could do in some scenarios because she has the
write/modify permission) and re-creates it, she becomes the Creator
Owner and now Bob no longer has the ability to set permissions on it.

If I take your strange assumptions, Bob could re-discover the newly
created folder that Alice made, just like she did (I mean if you make up
crap scenarios, why can't I), and do the same trick back to her.

And Windows does have a umask-like function. It's called Creator Owner.
It's a well known SID, and the default permissions for it can be set so
that any granular permission you want can be set to be default. 

Vista does have symbolic links, and Windows has supported Junction
Points (similar to symbolic links) since Windows 2000. The main
difference is that Junction Points could only point to local resources
and symbolic links can do remote resources as well.

You've come up with some strange scenarios below, and in all cases I
could easily defeat the problem you are suggesting by using basic,
recommended, security settings. 

Why do you spend your time coming up with such weird scenarios to focus
on? You're obviously a creative guy with some Windows security smarts.
Why not focus on more realistic scenarios with more real-world use?
There's plenty of them for us to focus on and to try and solve.

Roger

*****************************************************************
*Roger A. Grimes, InfoWorld, Security Columnist 
*CPA, CISSP, MCSE: Security (2000/2003/MVP), CEH, yada...yada...
*email: roger_grimes@...oworld.com or roger@...neretcs.com
*Author of Professional Windows Desktop and Server Hardening (Wrox)
*http://www.amazon.com/gp/product/0764599909
*****************************************************************


-----Original Message-----
From: 3APA3A [mailto:3APA3A@...URITY.NNOV.RU] 
Sent: Thursday, March 08, 2007 2:59 PM
To: bugtraq@...urityfocus.com; full-disclosure@...ts.grok.org.uk
Subject: Microsoft Windows Vista/2003/XP/2000 file management security
issues


This   is   an   article   I   promised   to   publish   after  Windows
ReadDirectoryChangesW  (CVE-2007-0843)  [1] issue. It should explain why
you must never place secure data inside insecure directory.



Title: Microsoft Windows Vista/2003/XP/2000 file management security
issues
Author: 3APA3A, http://securityvulns.com/
Vendor: Microsoft (and potentially another vendors)
Products:  Microsoft  Windows Vista/2003/XP/2000, Microsoft resource kit
           for Windows 2000 and different utilities.
Access Vector: Local
Type: multiple/complex (weak design, insecure file operations, etc)
Original advisory: http://securityvulns.com/advisories/winfiles.asp
Securityvulns.com news:
http://security.nnov.ru/news/Microsoft/Windows/files.html

0. Intro

This  article contains a set of attack scenarios to demonstrate security
weakness in few very common Windows management practices. Neither of the
problem  explained  is critical, yet combined together they should force
you   to   review   your   security   practices.   I   can't   even  say
"vulnerabilities"   because   there   is   no  something  you  can  call
"vulnerability". It's just something you believe is secure and it's not.

1.1 Problem: inability to create secured file / folder in public one.
    Attack: folder hijack attack

First,  it's simply impossible with standard Windows interface to create
something secured in insecure folder.

 Scenario  1.1:

 Bob  wishes  to  create "Bob private data" folder in "Public" folder to
place  few private files. "Public" has at least "Write" permissions for
"User" group. Bob:

     I   Creates "Bob private data" folder
     II  Sets permission for folder to only allow access to folder
himself
     III Copies private files into folder

  Alice wants to get access to folder Bob created. She

     Ia  Immediately  after  folder  is  created,  deletes "Bob private
         data"  folder  and creates "Bob private data" folder again (or
         simply  takes  ownership  under  "Bob  private data" folder if
         permissions allow). It makes Alice folder owner.
     IIa Immediately  after  Bob  sets permissions, she grants herself
         full control under folder. She can do it as a folder owner.
     IIIa  Reads  Bob's  private  files,  because  files permissions are
         inherited from folder

  Alice   can  use  "Spydir"  (http://securityvulns.com/soft/)  tool  to
  monitor  files  access  and automate this process. As you can see, [1]
  elevates this problem significantly.
     
  This   is  not  new  attack.  Unix  has  "umask"  command  to  protect
  administrators and users. Currently, Windows has nothing similar.

  CreateFile() API supports setting file ACL on file creation (just like
  open()  allows  to set mode on POSIX systems). ACL can be securely set
  only  on  newly  created  files.  This raises a problem of secure file
  creation.

1.2  Problem: Inability to lock / securely change permissions of already
     created file
     Attack: pre-open file/directory attack.

  There  are  few  classes  of insecure file creation attack (attempt to
  open   existing  file),  exploitable  under  Unix  with  hardlinks  or
  symlinks.  It's  believed  Windows  is  not vulnerable to this attacks
  because

    I.  There  is  no  symlinks  under Windows. Symlink attacks are not
        possible.
    II. Security  information  in  NTFS  is  not  stored  as  a part of
        directory entry, it's a part of file data. Hard link attacks are
        not possible.
    III. File  locks  in  Windows  are  mandatory.  It  means,  if  one
         application  locks  the file, another application can not open
         this  file, if user doesn't have backup privileges. It mitigate
         different file-based attacks.

  There  is at least one scenario, attacker can succeed without symbolic
  link:  to  steal  data  written to file created without check for file
  existence regardless of file locks and permissions.

  Attack description: if attacker can predict filename to be written, he
  can  create file, open it and share this file for all types of access.
  Because  locking  and  permissions  are  only  checked  on  file open,
  attacker  retain  access  to  the  file  even  if it's locked and it's
  permissions are changed to deny file access to attacker.

  Exploit (or useful tool): http://securityvulns.com/files/spyfile.c

  Opens  file, shares it for different types of access and logs changes,
  keeping the file open.

  Compiled version is available from http://securityvulns.com/soft/

  Scenario 1.2.1:

   Bob is now aware about folder hijack attack. He use xcopy /O /U /S to
   synchronize  his  files  to  newly  created  folder.  xcopy /O copies
   security  information (ownership and permissions) before writing data
   to file.

   Alice  use  "Spydir"  to  monitor  newly created folders and files in
   Bob's  directory.  She  use Spyfile to create spoofed files in target
   directory  and  waits for Bob to run xcopy. Now, she has full control
   under  content of Bob's files despite the fact she has no permissions
   to access these files.

   In  a  same  way  directory  content  may be monitored by pre-opening
   directory.

  Scenario 1.2.2:

   Enterprise  directory  structure  is  replicated every day to another
   user-writable  location  in  order  to alow users to recover suddenly
   deleted  or  modified files. xcopy or robocopy (from resource kit) is
   used  for  replication.  Attacker can hijack content of newly created
   files in newly created folders.

  Same problem may happen on archive extraction or backup restoration.

  Vulnerable  applications:
    xcopy (from all Windows versions),
    robocopy (Windows  2000  Resource Kit),
    different archivers
    backup restoration utilities

  By  default,  xcopy warns user the file exists, unless /Y or /U key is
  specified.  But
    I.  /Y  is  always  specified  for replication
    II. /Y  can  be specified via COPYCMD environment variable. COPYCMD
    environment    variable   can  be  created  in  autoexec.bat  file.
    Different situations are possible, where autoexec.bat is writable by
    attacker, if:
     - Default Windows 2000 permissions are used or applied with domain
     policy [2].
     - One can try to re-create autoexec.bat using POSIX subsystem
    III.  Neither  xcopy  nor  other  utilities  warn user on existing
    directory. Pre-open directory attack will always succeed.

  As you can see, [1] again dramatically elevates this problem.

1.3 Problem: user can completely block access to the files
    Attack: open file deletion
    (including Windows file replication service DoS)

    If files is deleted while it's open, it still present in file system
    under  it's  old  name  until  close.  Any  operation  on  this file
    (including  attributes  requests)  fails,  regardless of application
    rights and permissions (including backup ones).

    Exploit:  use  spyfile,  delete  file while it's spied. Now, without
    closing  spyfile,  attempt  any  operation on this file (e.g. try to
    find it's ownership).

    Scenario 1.3.1

    Now Bob found an copy application to securely copy files. It deletes
    old file before creating new one. But it fails if Alice tries to spy
    on  Bob  files,  because  attempt  to delete file succeeds, but file
    still present and is unmanageable.

    Scenario 1.3.2

    Windows  file  replication  service  (FRS) is used to replicate data
    between  2  public  DFS  folders  to  distribute  load.  Folder  has
    permissions:
     Everyone: Add & read
     Creator Owner: Full Control
    Thouse, Alice has no permissions to delete files created by Bob.

    Replicated  folder  is  available as a share on 2 different servers:
    \\SERVER1\Share    and    \\SERVER2\Share.    Bob    is    connected
    to \\SERVER1\Share.

    Alice uses "Spydir" to monitor files creation by Bob. Every time Bob
    creates  new  file  on  \\SERVER1\Share, Alice use spyfile to create
    file  with same name on \\SERVER2\Share. It effectively leads to FRS
    collision.  While  trying  to resolve collision, FRS fails to delete
    file  created  by  Alice  and  Bob file is deleted (original file is
    moved to special hidden folder only accessible by administrator).

    Workaround:  never  try  to  use  creator-owner based permissions in
    replicated folders.

    Again, [1] seriously escalates this problem.
    
2. Conclusion:

  It's  simply impossible to securely create something in public folder.
  At least DoS conditions are always possible.
  Developers should  not  consider mandatory file locking as a security
  feature.
  Developers  should  care about secure file creation to store sensitive
  information.  CREATE_NEW  should  always be used and ACL should be set
  with  lpSecurityAttributes  of CreateFile. No attempt to open existing
  file should be made.
  Never  try  to  create secure folder in public one. If you are forced,
  disconnect     all   users   before   this   operation.
  Never  use  replication,  archive  extraction  or  backup  restore  to
  user-accessible folder.
  Bob and Alice should finally marry.
    
3. Vendor:

  All timelines are same with [1].


[1]. Microsoft Windows ReadDirectoryChangesW information leak
(CVE-2007-0843)
http://security.nnov.ru/news/Microsoft/Windows/ReadDirector.html
[2]. Windows 2000 system partition weak default permissions
http://securityvulns.ru/news2205.html

--
http://securityvulns.com/
         /\_/\
        { , . }     |\
+--oQQo->{ ^ }<-----+ \
|  ZARAZA  U  3APA3A   } You know my name - look up my number (The
Beatles)
+-------------o66o--+ /
                    |/

Powered by blists - more mailing lists