RE: Re[2]: Microsoft Windows Vista/2003/XP/2000 file management
> 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.=20
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.=20
=20
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.=20
Mark Burnett
http://xato.net
=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> You are essentially say, "If you misconfigure your system and make
> further insecure choices, someone can hack you." Duh.
>=20
> There's a reason why your "announcements" aren't making the news
> media...because it isn't news.
>=20
> 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.
>=20
> You're a smart person, concentrate on issues that will really give us
> bang for the buck discussions and issues.
>=20
> Roger
>=20
> *****************************************************************
> *Roger A. Grimes, InfoWorld, Security Columnist
> *CPA, CISSP, MCSE: Security (2000/2003/MVP), CEH, yada...yada...
> *email: roger_grimes@infoworld.com or roger@banneretcs.com
> *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@SECURITY.NNOV.RU]
> Sent: Friday, March 09, 2007 7:09 AM
> To: Roger A. Grimes
> Cc: bugtraq@securityfocus.com; full-disclosure@lists.grok.org.uk
> Subject: Re[2]: Microsoft Windows Vista/2003/XP/2000 file management
> security issues
>=20
> Dear Roger A. Grimes,
>=20
> --Friday, March 9, 2007, 7:31:54 AM, you wrote to
> 3APA3A@SECURITY.NNOV.RU:
>=20
> 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.
>=20
> As a folder owner Alice can give any permissions to Bob she wants.
>=20
> 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.
>=20
> He can, if he knows he must.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
>=20
> "You never know what is enough unless you know more than enough."
> William Blake
>=20
> 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".
>=20
> RAG> Why do you spend your time coming up with such weird scenarios
> to
> RAG> focus on?
>=20
> 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".
>=20
> RAG> You're obviously a creative guy with some Windows security
> RAG> smarts.
>=20
> Thanks.
>=20
> 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.
>=20
> 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.
>=20
> RAG> Roger
>=20
> RAG> *****************************************************************
> RAG> *Roger A. Grimes, InfoWorld, Security Columnist *CPA, CISSP, =
MCSE:
> RAG> Security (2000/2003/MVP), CEH, yada...yada...
>=20
> 3APA3A. MCSE/MCT since Windows NT 4.0.
>=20
> RAG> *email: roger_grimes@infoworld.com or roger@banneretcs.com =
*Author
> RAG> of Professional Windows Desktop and Server Hardening (Wrox)
> RAG> *http://www.amazon.com/gp/product/0764599909
> RAG> *****************************************************************
>=20
>=20
> RAG> -----Original Message-----
> RAG> From: 3APA3A [mailto:3APA3A@SECURITY.NNOV.RU]
> RAG> Sent: Thursday, March 08, 2007 2:59 PM
> RAG> To: bugtraq@securityfocus.com; full-disclosure@lists.grok.org.uk
> RAG> Subject: Microsoft Windows Vista/2003/XP/2000 file management
> RAG> security issues
>=20
>=20
> 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.
>=20
>=20
>=20
> 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
>=20
> RAG> 0. Intro
>=20
> 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.
>=20
> RAG> 1.1 Problem: inability to create secured file / folder in public
> one.
> RAG> Attack: folder hijack attack
>=20
> RAG> First, it's simply impossible with standard Windows interface to
> RAG> create something secured in insecure folder.
>=20
> RAG> Scenario 1.1:
>=20
> 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:
>=20
> 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
>=20
> RAG> Alice wants to get access to folder Bob created. She
>=20
> 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
>=20
> 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.
>=20
> RAG> This is not new attack. Unix has "umask" command to
> protect
> RAG> administrators and users. Currently, Windows has nothing
> similar.
>=20
> 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.
>=20
> RAG> 1.2 Problem: Inability to lock / securely change permissions of
> already
> RAG> created file
> RAG> Attack: pre-open file/directory attack.
>=20
> 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
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> RAG> Exploit (or useful tool):
> RAG> http://securityvulns.com/files/spyfile.c
>=20
> RAG> Opens file, shares it for different types of access and logs
> changes,
> RAG> keeping the file open.
>=20
> RAG> Compiled version is available from
> http://securityvulns.com/soft/
>=20
> RAG> Scenario 1.2.1:
>=20
> 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.
>=20
> 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.
>=20
> RAG> In a same way directory content may be monitored by pre-
> opening
> RAG> directory.
>=20
> RAG> Scenario 1.2.2:
>=20
> 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.
>=20
> RAG> Same problem may happen on archive extraction or backup
> restoration.
>=20
> RAG> Vulnerable applications:
> RAG> xcopy (from all Windows versions),
> RAG> robocopy (Windows 2000 Resource Kit),
> RAG> different archivers
> RAG> backup restoration utilities
>=20
> 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.
>=20
> RAG> As you can see, [1] again dramatically elevates this problem.
>=20
> RAG> 1.3 Problem: user can completely block access to the files
> RAG> Attack: open file deletion
> RAG> (including Windows file replication service DoS)
>=20
> 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).
>=20
> 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).
>=20
> RAG> Scenario 1.3.1
>=20
> 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.
>=20
> RAG> Scenario 1.3.2
>=20
> 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.
>=20
> 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.
>=20
> 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).
>=20
> RAG> Workaround: never try to use creator-owner based
> permissions in
> RAG> replicated folders.
>=20
> RAG> Again, [1] seriously escalates this problem.
>=20
> RAG> 2. Conclusion:
>=20
> 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.
>=20
> RAG> 3. Vendor:
>=20
> RAG> All timelines are same with [1].
>=20
> 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> |/
>=20
>=20
>=20
> --
> ~/ZARAZA http://securityvulns.com/
> =EE=CF =D7=C5=C4=D8 =CB=CF=CD=D5 =D5=C7=CF=C4=CE=CF =CD=CF=C7=D5=D4 =
=D0=D2=C9=CA=D4=C9 =D7 =C7=CF=CC=CF=D7=D5 =D1=CA=C3=C1, =D0=D1=D4=CB=C9 =
=C9 =C5=D0=C9=D3=CB=CF=D0=D9. (=EC=C5=CD)
討論串 (同標題文章)
完整討論串 (本文為第 3 之 3 篇)：