RE: Re[2]: Microsoft Windows Vista/2003/XP/2000 file management security issues
> But we'll have to agree to disagree. Your security scenarios are just
> bizarre. It's a lot easier to hack people then going through all the
> interations you suggest.
Roger, don't be so hard on 3APA3A for this. You can't judge a vulnerability
based on current scenarios because we really can't begin to imagine how
these things might be exploited in future attacks. For example, the attack
of deleting someone's folder and re-creating it before they set permissions
sounds bizarre until someone makes a tool that does that automatically to
all new folders. It changes everything when even the front desk secretary
can pull off the attack.
And even if it would be lame for someone to set up a folder where this would
be possible, people will still set up folders where this is possible. It's
important for us to be aware of the risks of these configurations. And you
have to admit, it is pretty amazing he found something we all missed for the
last ten years, despite how simple it is.
Finally, I don't think 3APA3A is over hyping this issue beyond what it
really is. He acknowledges that it isn't really a vulnerability and he's not
submitting press releases to all the mainstream media. He gave Microsoft
fair notice and awaited their decision and he's not screaming that everyone
must abandon Windows. But he is informing the security community of
something that we certainly should be aware of.
Mark Burnett
http://xato.net
> For one, I've been a sys admin for 20 years and NEVER created a private
> folder under a public folder. Not in my Novell days, not in my Windows
> days. The only time I've seen a private folder created under a public
> folder is the \Users folder, and in that case, the users only have Read
> and List access to the parent \Users folder, and then Full Control to
> their own folders.
>
> I mean let's debate why users get Full Control to their own folders in
> the first place. That's a common scenario (it's on nearly every
> network) and its almost always too many permissions. Do I want my
> regular end-users changing their folder's security permissions? No.
> Should any regular end-user have Full Control to any share? No, for the
> same reason. These are valid, common, security points that really do
> beg further discussion.
>
> You're just making up crap up that isn't overly realistic in the world,
> then going further to assume that a bonehead administrator compounds
> the problem by making further insecure decisions.
>
> You are essentially say, "If you misconfigure your system and make
> further insecure choices, someone can hack you." Duh.
>
> There's a reason why your "announcements" aren't making the news
> media...because it isn't news.
>
> With that said, you have something valid to say, but so far it just
> isn't a "security vulnerability" that people need to be aware of.
>
> You're a smart person, concentrate on issues that will really give us
> bang for the buck discussions and issues.
>
> Roger
>
> *****************************************************************
> *Roger A. Grimes, InfoWorld, Security Columnist
> *CPA, CISSP, MCSE: Security (2000/2003/MVP), CEH, yada...yada...
> *email: roger_grimes@xxxxxxxxxxxxx or roger@xxxxxxxxxxxxxx
> *Author of Professional Windows Desktop and Server Hardening (Wrox)
> *http://www.amazon.com/gp/product/0764599909
> *****************************************************************
> http://winblogs.security-feed.com
> Server Hardening, NTFS
> -----Original Message-----
> From: 3APA3A [mailto:3APA3A@xxxxxxxxxxxxxxxx]
> Sent: Friday, March 09, 2007 7:09 AM
> To: Roger A. Grimes
> Cc: bugtraq@xxxxxxxxxxxxxxxxx; full-disclosure@xxxxxxxxxxxxxxxxx
> Subject: Re[2]: Microsoft Windows Vista/2003/XP/2000 file management
> security issues
>
> Dear Roger A. Grimes,
>
> --Friday, March 9, 2007, 7:31:54 AM, you wrote to
> 3APA3A@xxxxxxxxxxxxxxxx:
>
> RAG> If Alice deletes Bob's folder (which she could do in some
> scenarios
> RAG> because she has the write/modify permission) and re-creates it,
> she
> RAG> becomes the Creator Owner and now Bob no longer has the ability
> to
> RAG> set permissions on it.
>
> As a folder owner Alice can give any permissions to Bob she wants.
>
> RAG> If I take your strange assumptions, Bob could re-discover the
> newly
> RAG> created folder that Alice made, just like she did (I mean if you
> RAG> make up crap scenarios, why can't I), and do the same trick back
> to her.
>
> He can, if he knows he must.
>
> RAG> And Windows does have a umask-like function. It's called Creator
> Owner.
> RAG> It's a well known SID, and the default permissions for it can be
> RAG> set so that any granular permission you want can be set to be
> default.
>
> I see nothing similar between Creator Owner and umask. BTW, the
> same article explains why Creator Owner is not 100% solution and
> why you should not rely on Creator Owner in case of DFS replication.
>
> RAG> Vista does have symbolic links, and Windows has supported Junction
> RAG> Points (similar to symbolic links) since Windows 2000. The main
> RAG> difference is that Junction Points could only point to local
> RAG> resources and symbolic links can do remote resources as well.
>
> Junction points are very close to Unix mounts, I see no any likeness
> to symbolic links. Junctions points (and by default, symbolic
> links in
> Vista) can only be created by administrators, it prevents
> symlink attack. And it's right choice.
>
> RAG> You've come up with some strange scenarios below, and in all cases
> RAG> I could easily defeat the problem you are suggesting by using
> RAG> basic, recommended, security settings.
>
>
> "You never know what is enough unless you know more than enough."
> William Blake
>
> It's quite hard to defeat the threat without knowing it. I'm
> disagree with you about "recommended security settings". I never saw
> "disconnect all users and close access to the share" or "check you are
> still folder owner before copy the data" in instructions on how to
> create file/folder with restricted access inside public one. Or "xcopy
> /O doesn't guarantee file can not be accessed during copy
> operation" or "Do not rely on Creator Owner in case of replication".
>
> RAG> Why do you spend your time coming up with such weird scenarios
> to
> RAG> focus on?
>
> Roger, have you ever used robocopy or xcopy /O? I'm not
> security columnist, I am system administrator/engineer. For last
> 10 years I
> develop and implement a lot of corporate directory
> structures,
> replications, and backup/restore policies for many very
> different organizations. I explain mistakes I can personally make and
> sometimes I personally did (mixing secure and insecure data,
> implementing automatic replication to unprotected folders,
> implementing data restore policies where user can ask system
> administrator to restore some directory structure to user
> accessible folder, etc). May be I'm only dumb person who does
> mistakes like that, most probably not. I call it "properly placed
> rakes to step on".
>
> RAG> You're obviously a creative guy with some Windows security
> RAG> smarts.
>
> Thanks.
>
> RAG> Why not focus on more realistic scenarios with more real-world
> RAG> use? There's plenty of them for us to focus on and to try and
> RAG> solve.
>
> Roger, of cause next time I should concentrate on a single-
> packet exploitable overflow in IPv6 stack to interest InfoWorld
> readers. I will not, because it's nothing interesting for me in
> searching yet another buffer overflow. Let another creative guys
> who are professional in vulnerability researching to dig it. They
> have tools, time and money.
> For me, most valuable vulnerability is one simple enough to be
> exploited with notepad, because it can be noted by everyone, but was
> unnoticed for 10 years.
>
> RAG> Roger
>
> RAG> *****************************************************************
> RAG> *Roger A. Grimes, InfoWorld, Security Columnist *CPA, CISSP, MCSE:
> RAG> Security (2000/2003/MVP), CEH, yada...yada...
>
> 3APA3A. MCSE/MCT since Windows NT 4.0.
>
> RAG> *email: roger_grimes@xxxxxxxxxxxxx or roger@xxxxxxxxxxxxxx *Author
> RAG> of Professional Windows Desktop and Server Hardening (Wrox)
> RAG> *http://www.amazon.com/gp/product/0764599909
> RAG> *****************************************************************
>
>
> RAG> -----Original Message-----
> RAG> From: 3APA3A [mailto:3APA3A@xxxxxxxxxxxxxxxx]
> RAG> Sent: Thursday, March 08, 2007 2:59 PM
> RAG> To: bugtraq@xxxxxxxxxxxxxxxxx; full-disclosure@xxxxxxxxxxxxxxxxx
> RAG> Subject: Microsoft Windows Vista/2003/XP/2000 file management
> RAG> security issues
>
>
> RAG> This is an article I promised to publish after
> Windows
> RAG> ReadDirectoryChangesW (CVE-2007-0843) [1] issue. It should
> RAG> explain why you must never place secure data inside insecure
> directory.
>
>
>
> RAG> Title: Microsoft Windows Vista/2003/XP/2000 file management
> RAG> security issues
> RAG> Author: 3APA3A, http://securityvulns.com/
> RAG> Vendor: Microsoft (and potentially another vendors)
> RAG> Products: Microsoft Windows Vista/2003/XP/2000, Microsoft
> resource kit
> RAG> for Windows 2000 and different utilities.
> RAG> Access Vector: Local
> RAG> Type: multiple/complex (weak design, insecure file operations,
> etc)
> RAG> Original advisory:
> http://securityvulns.com/advisories/winfiles.asp
> RAG> Securityvulns.com news:
> RAG> http://security.nnov.ru/news/Microsoft/Windows/files.html
>
> RAG> 0. Intro
>
> RAG> This article contains a set of attack scenarios to demonstrate
> RAG> security weakness in few very common Windows management practices.
> RAG> Neither of the problem explained is critical, yet combined
> together they should force
> RAG> you to review your security practices. I can't even
> say
> RAG> "vulnerabilities" because there is no something you can
> call
> RAG> "vulnerability". It's just something you believe is secure and
> it's not.
>
> RAG> 1.1 Problem: inability to create secured file / folder in public
> one.
> RAG> Attack: folder hijack attack
>
> RAG> First, it's simply impossible with standard Windows interface to
> RAG> create something secured in insecure folder.
>
> RAG> Scenario 1.1:
>
> RAG> Bob wishes to create "Bob private data" folder in "Public"
> RAG> folder to place few private files. "Public" has at least "Write"
> RAG> permissions for "User" group. Bob:
>
> RAG> I Creates "Bob private data" folder
> RAG> II Sets permission for folder to only allow access to folder
> RAG> himself
> RAG> III Copies private files into folder
>
> RAG> Alice wants to get access to folder Bob created. She
>
> RAG> Ia Immediately after folder is created, deletes "Bob
> private
> RAG> data" folder and creates "Bob private data" folder
> again (or
> RAG> simply takes ownership under "Bob private data"
> folder if
> RAG> permissions allow). It makes Alice folder owner.
> RAG> IIa Immediately after Bob sets permissions, she grants
> herself
> RAG> full control under folder. She can do it as a folder
> owner.
> RAG> IIIa Reads Bob's private files, because files
> permissions are
> RAG> inherited from folder
>
> RAG> Alice can use "Spydir"
> RAG> (http://securityvulns.com/soft/) tool to
> RAG> monitor files access and automate this process. As you can
> see, [1]
> RAG> elevates this problem significantly.
>
> RAG> This is not new attack. Unix has "umask" command to
> protect
> RAG> administrators and users. Currently, Windows has nothing
> similar.
>
> RAG> CreateFile() API supports setting file ACL on file creation
> (just like
> RAG> open() allows to set mode on POSIX systems). ACL can be
> securely set
> RAG> only on newly created files. This raises a problem of
> secure file
> RAG> creation.
>
> RAG> 1.2 Problem: Inability to lock / securely change permissions of
> already
> RAG> created file
> RAG> Attack: pre-open file/directory attack.
>
> RAG> There are few classes of insecure file creation attack
> (attempt to
> RAG> open existing file), exploitable under Unix with
> hardlinks or
> RAG> symlinks. It's believed Windows is not vulnerable to this
> attacks
> RAG> because
>
> RAG> I. There is no symlinks under Windows. Symlink attacks
> are not
> RAG> possible.
> RAG> II. Security information in NTFS is not stored as a
> part of
> RAG> directory entry, it's a part of file data. Hard link
> attacks are
> RAG> not possible.
> RAG> III. File locks in Windows are mandatory. It means, if
> one
> RAG> application locks the file, another application can not
> open
> RAG> this file, if user doesn't have backup privileges. It
> mitigate
> RAG> different file-based attacks.
>
> RAG> There is at least one scenario, attacker can succeed without
> symbolic
> RAG> link: to steal data written to file created without check
> for file
> RAG> existence regardless of file locks and permissions.
>
> RAG> Attack description: if attacker can predict filename to be
> written, he
> RAG> can create file, open it and share this file for all types of
> access.
> RAG> Because locking and permissions are only checked on file
> open,
> RAG> attacker retain access to the file even if it's locked
> and it's
> RAG> permissions are changed to deny file access to attacker.
>
> RAG> Exploit (or useful tool):
> RAG> http://securityvulns.com/files/spyfile.c
>
> RAG> Opens file, shares it for different types of access and logs
> changes,
> RAG> keeping the file open.
>
> RAG> Compiled version is available from
> http://securityvulns.com/soft/
>
> RAG> Scenario 1.2.1:
>
> RAG> Bob is now aware about folder hijack attack. He use xcopy /O /U
> /S to
> RAG> synchronize his files to newly created folder. xcopy /O
> copies
> RAG> security information (ownership and permissions) before
> writing data
> RAG> to file.
>
> RAG> Alice use "Spydir" to monitor newly created folders and
> files in
> RAG> Bob's directory. She use Spyfile to create spoofed files in
> target
> RAG> directory and waits for Bob to run xcopy. Now, she has full
> control
> RAG> under content of Bob's files despite the fact she has no
> permissions
> RAG> to access these files.
>
> RAG> In a same way directory content may be monitored by pre-
> opening
> RAG> directory.
>
> RAG> Scenario 1.2.2:
>
> RAG> Enterprise directory structure is replicated every day to
> another
> RAG> user-writable location in order to alow users to recover
> suddenly
> RAG> deleted or modified files. xcopy or robocopy (from resource
> kit) is
> RAG> used for replication. Attacker can hijack content of newly
> created
> RAG> files in newly created folders.
>
> RAG> Same problem may happen on archive extraction or backup
> restoration.
>
> RAG> Vulnerable applications:
> RAG> xcopy (from all Windows versions),
> RAG> robocopy (Windows 2000 Resource Kit),
> RAG> different archivers
> RAG> backup restoration utilities
>
> RAG> By default, xcopy warns user the file exists, unless /Y or /U
> key is
> RAG> specified. But
> RAG> I. /Y is always specified for replication
> RAG> II. /Y can be specified via COPYCMD environment variable.
> COPYCMD
> RAG> environment variable can be created in autoexec.bat
> file.
> RAG> Different situations are possible, where autoexec.bat is
> writable by
> RAG> attacker, if:
> RAG> - Default Windows 2000 permissions are used or applied with
> domain
> RAG> policy [2].
> RAG> - One can try to re-create autoexec.bat using POSIX subsystem
> RAG> III. Neither xcopy nor other utilities warn user on
> existing
> RAG> directory. Pre-open directory attack will always succeed.
>
> RAG> As you can see, [1] again dramatically elevates this problem.
>
> RAG> 1.3 Problem: user can completely block access to the files
> RAG> Attack: open file deletion
> RAG> (including Windows file replication service DoS)
>
> RAG> If files is deleted while it's open, it still present in file
> system
> RAG> under it's old name until close. Any operation on this
> file
> RAG> (including attributes requests) fails, regardless of
> application
> RAG> rights and permissions (including backup ones).
>
> RAG> Exploit: use spyfile, delete file while it's spied. Now,
> without
> RAG> closing spyfile, attempt any operation on this file (e.g.
> try to
> RAG> find it's ownership).
>
> RAG> Scenario 1.3.1
>
> RAG> Now Bob found an copy application to securely copy files. It
> deletes
> RAG> old file before creating new one. But it fails if Alice tries
> to spy
> RAG> on Bob files, because attempt to delete file succeeds,
> but file
> RAG> still present and is unmanageable.
>
> RAG> Scenario 1.3.2
>
> RAG> Windows file replication service (FRS) is used to
> replicate data
> RAG> between 2 public DFS folders to distribute load.
> Folder has
> RAG> permissions:
> RAG> Everyone: Add & read
> RAG> Creator Owner: Full Control
> RAG> Thouse, Alice has no permissions to delete files created by
> Bob.
>
> RAG> Replicated folder is available as a share on 2 different
> servers:
> RAG> \\SERVER1\Share and \\SERVER2\Share. Bob is
> connected
> RAG> to \\SERVER1\Share.
>
> RAG> Alice uses "Spydir" to monitor files creation by Bob. Every
> time Bob
> RAG> creates new file on \\SERVER1\Share, Alice use spyfile to
> create
> RAG> file with same name on \\SERVER2\Share. It effectively leads
> to FRS
> RAG> collision. While trying to resolve collision, FRS fails to
> delete
> RAG> file created by Alice and Bob file is deleted (original
> file is
> RAG> moved to special hidden folder only accessible by
> administrator).
>
> RAG> Workaround: never try to use creator-owner based
> permissions in
> RAG> replicated folders.
>
> RAG> Again, [1] seriously escalates this problem.
>
> RAG> 2. Conclusion:
>
> RAG> It's simply impossible to securely create something in public
> folder.
> RAG> At least DoS conditions are always possible.
> RAG> Developers should not consider mandatory file locking as a
> security
> RAG> feature.
> RAG> Developers should care about secure file creation to store
> sensitive
> RAG> information. CREATE_NEW should always be used and ACL should
> be set
> RAG> with lpSecurityAttributes of CreateFile. No attempt to open
> existing
> RAG> file should be made.
> RAG> Never try to create secure folder in public one. If you are
> forced,
> RAG> disconnect all users before this operation.
> RAG> Never use replication, archive extraction or backup
> restore to
> RAG> user-accessible folder.
> RAG> Bob and Alice should finally marry.
>
> RAG> 3. Vendor:
>
> RAG> All timelines are same with [1].
>
> http://passwords.security-feed.com
> RAG> [1]. Microsoft Windows ReadDirectoryChangesW information leak
> RAG> (CVE-2007-0843)
> RAG> http://security.nnov.ru/news/Microsoft/Windows/ReadDirector.html
> RAG> [2]. Windows 2000 system partition weak default permissions
> RAG> http://securityvulns.ru/news2205.html
> http://xato.net
> RAG> --
> RAG> http://securityvulns.com/
> RAG> /\_/\
> RAG> { , . } |\
> RAG> +--oQQo->{ ^ }<-----+ \
> RAG> | ZARAZA U 3APA3A } You know my name - look up my number (The
> RAG> Beatles)
> RAG> +-------------o66o--+ /
> RAG> |/
>
>
>
> --
> ~/ZARAZA http://securityvulns.com/
> Но ведь кому угодно могут прийти в голову яйца, пятки и епископы. (Лем)