Hello Matt -
With all due respect, if NTFS permissions are not configured properly then you
have many, many things to be worried about aside from having Parent Path being
enabled or disabled, particularly if you are allowing people to upload
executable files remotely (as in, the server is a shared hosting server). In
this scenario, a user can literally upload a very simple ASP script that
utilizes FSO and they can delete every single file on the server. Would
disabling parent paths help you at all in this case? Absolutely not - because
it's would be possible to specify the drive root and begin recursively deleting
files using some loops. Furthermore, if hackers are exploiting poorly coded
web applications that allow executable files to be uploaded and you insecure
NTFS permissions, your server is screwed, regardless of having Parent Paths
enabled or not.
Please also understand that second scenario that you note is also related NTFS permissions being insecure. With proper NTFS permissions, one customer cannot access another customer files. This is the whole point of permissions. Without proper permissions in place, your server is a sitting duck. Goodness gracious.
-Jay
________________________________________
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt
Sent: Monday, April 03, 2006 6:27 PM
To: Declude.JunkMail@declude.com
Subject: Re: [Declude.JunkMail] Declude 4.1 Is Out
Kevin, IIS 6 has built in protection from double encoding by default (like "..%5c" or
".%2e/" instead of "../"), and I also still use URLScan to block such things even though
Microsoft was saying that it wasn't necessary with IIS 6. The other important addition in IIS 6's security
is in only allowing explicitly defined extensions to be returned, and by default, extensions like EXE are not
configured. I also don't use default locations, I remove all example code, and I give Web sites the bare
minimum permissions.
Jay, one of the issues with parent paths is the fact that permissions are
sometimes configured to allow Everyone access. Script kiddies often deface or
hack servers by exploiting poor code and file permissions of popular Web
applications. For instance, a lot of the phishers are putting their content on
sites where PHP-Nuke is used, and there has been a long history of hacks for
all sorts of content management and bulletin board code. Often the attacker
adds the directory transversal string as an argument to a script.
Another very big issue with such a configuration is that Parent Paths can allow
an admin for one website to write a simple script that escapes their root and
read or write content from/to another site (depending on permissions). For
instance, someone could look for a common file in another site such a
web.config, and read the SQL Server login and password, and then steal or
corrupt another customer's data in the database. Simple as pie!
The best security is to explicitly define the minimal permissions necessary for
every unique site use, and to layer your security. Declude can get around the
limitations of disabled Parent Paths by requiring a virtual directory to be
created, and using a specific Group with explicitly defined permissions to
access the required files. This is not a big deal to do.
Matt
Kevin Bilbee wrote:
Install url scan and use the IIS lockdown tool. this will stop all ../../../ attacks dead in their tracks. Rerardless of the parent paths setting.
Kevin Bilbee
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Matt
Sent: Monday, April 03, 2006 2:38 PM
To: Declude.JunkMail@declude.com
Subject: Re: [Declude.JunkMail] Declude 4.1 Is Out
Jay,
This is incorrect. You can traverse directories within your root using "../"
with Parent Paths disabled, but if you enable it, you can go outside your root so long as
the file permissions allow it. Here's a quote from the KB article that you linked to:
"The Parent Paths option (the AspEnableParentPaths metabase property) permits you to use
".." in calls to functions such as MapPath by allowing paths that are relative to the
current directory using the ..\notation. Setting this property to True may constitute a security
risk because an include path can access critical or confidential files outside the root directory
of the application."
Matt
Jay Sudowski - Handy Networks LLC wrote:
Wrongggggggggg.
Enabling parent paths doesn't allow you to actually enter ../../../../../ and
transverse directories into your URL string!
http://support.microsoft.com/default.aspx?scid=kb;en-us;332117
It simply allows you to use ../ in your ASP and SSI includes!
Goodness gracious.
PS - Please use plain text unless you have a particularly compelling reason to
post in HTML.
________________________________________
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt
Sent: Monday, April 03, 2006 5:27 PM
To: Declude.JunkMail@declude.com
Subject: Re: [Declude.JunkMail] Declude 4.1 Is Out
I beg to differ. IMO, Enabling Parent Paths is one of the biggest security
risks for a Web server, and IIS disables them by default because of this. Most
exploits require multiple configuration mistakes to exploit, and if you enable
Parent Paths, it increases your likelihood of being hacked many times over. If
you look at your logging of websites on your server, you will likely see
entries around 200 at a time from script kiddies, most of which are seeking to
exploit configurations where parent paths are enabled.
The proper way to approach this would be to create a virtual directory under
the website, and configure an exclusive group as having permissions for the
Declude directory.
Matt
Jay Sudowski - Handy Networks LLC wrote:
Practically speaking, the security risks related to parent paths are
near zero. On scale of 0 to 100, having parent paths enabled would be a
.01, assuming your NTFS permissions are tight.
-Jay
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of John T (Lists)
Sent: Monday, April 03, 2006 5:09 PM
To: Declude.JunkMail@declude.com
Subject: RE: [Declude.JunkMail] Declude 4.1 Is Out
From the readme.html:
"Parent paths must be enabled."
Sorry, no they will not be enabled. That is a security risk I am not
going
to open up on my server.
John T
eServices For You
"Seek, and ye shall find!"
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:Declude.JunkMail-
[EMAIL PROTECTED] On Behalf Of Jay Sudowski - Handy Networks LLC
Sent: Monday, April 03, 2006 1:45 PM
To: Declude.JunkMail@declude.com
Subject: [Declude.JunkMail] Declude 4.1 Is Out
http://www.declude.com/Articles.asp?ID=186
Aside from the web admin, are there any other fixes or feature
enhancements? The release notes reference 4.0.9.4 ...
Thanks!
-----
Jay Sudowski // Handy Networks LLC
Director of Technical Operations
Providing Shared, Reseller, Semi Managed and Fully Managed Windows
2003
Hosting Solutions
Tel: 877-70 HANDY x882 | Fax: 888-300-2FAX
www.handynetworks.com
---
This E-mail came from the Declude.JunkMail mailing list. To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail". The archives can be found
at http://www.mail-archive.com.
---
This E-mail came from the Declude.JunkMail mailing list. To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail". The archives can be found
at http://www.mail-archive.com.
---
This E-mail came from the Declude.JunkMail mailing list. To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail". The archives can be found
at http://www.mail-archive.com.
---
This E-mail came from the Declude.JunkMail mailing list. To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail". The archives can be found
at http://www.mail-archive.com.
---
This E-mail came from the Declude.JunkMail mailing list. To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail". The archives can be found
at http://www.mail-archive.com.
