Matt, It seems that your misconception between Parent Paths and the IIS Unicode Directory Transversal VULNERABILITY remains. Additionally, you also seem to be completely confused with Code Red.
Code Red was related to a buffer overflow in Index Server. In order to avoid being impacted this worm, you either needed to install the patch by Microsoft or remove .ida/.idq mappings from IIS. Please see http://www.cert.org/advisories/CA-2001-19.html and http://www.cert.org/advisories/CA-2001-13.html. The same is true of Code Red II - http://www.cert.org/incident_notes/IN-2001-09.html. Nimda delivered it's IIS payload by exploiting the Unicode Directory Transversal bug(s) in IIS. Again, this has nothing to do with parent paths!!! http://www.cert.org/body/advisories/CA200126_FA200126.html System FootPrint The scanning activity of the Nimda worm produces the following log entries for any web server listing on port 80/tcp: GET /scripts/root.exe?/c+dir GET /MSADC/root.exe?/c+dir GET /c/winnt/system32/cmd.exe?/c+dir GET /d/winnt/system32/cmd.exe?/c+dir GET /scripts/..%5c../winnt/system32/cmd.exe?/c+dir GET /_vti_bin/..%5c../..%5c../..%5c../winnt/system32/cmd.exe?/c+dir GET /_mem_bin/..%5c../..%5c../..%5c../winnt/system32/cmd.exe?/c+dir GET /msadc/..%5c../..%5c../..%5c/..\xc1\x1c../..\xc1\x1c../..\xc1\x1c../winn t/system32/cmd.exe?/c+dir GET /scripts/..\xc1\x1c../winnt/system32/cmd.exe?/c+dir GET /scripts/..\xc0/../winnt/system32/cmd.exe?/c+dir GET /scripts/..\xc0\xaf../winnt/system32/cmd.exe?/c+dir GET /scripts/..\xc1\x9c../winnt/system32/cmd.exe?/c+dir GET /scripts/..%35c../winnt/system32/cmd.exe?/c+dir GET /scripts/..%35c../winnt/system32/cmd.exe?/c+dir GET /scripts/..%5c../winnt/system32/cmd.exe?/c+dir GET /scripts/..%2f../winnt/system32/cmd.exe?/c+dir http://www.sans.org/resources/idfaq/iis_unicode.php "A number of recent worms-including the Red Worm, Red Worm II, and Nimda worm-have exploited Unicode vulnerabilities in the IIS server in order to achieve phenomenal growth. This article will describe and examine these vulnerabilities. There are two major vulnerabilities: the IIS/PWS Exetended Unicode Directory Traversal Vulnerability and the IIS/PWS Escaped Character Decoding Command Execution Vulnerability." "Normally, IIS checks URL strings to ensure that certain constructs do not occur. For example, the following string will be caught by the parser: http://www.example.com/scripts/..\../winnt/system32/cmd.exe?/c+dir Obviously, the requester is attempting to access some parent of the "/scripts" directory, and IIS catches this and returns an HTTP 404 - File not found response. However, when the exact same request is made in the following form: http://www.example.com/scripts/..%c1%9c../winnt/system32/cmd.exe?/c+dir The response is: Directory of c:\inetpub\scripts 10/01/2001 03:46p <DIR> . 10/01/2001 03:46p <DIR> .. 0 File(s) 0 bytes 2 Dir(s) 2,527,547,392 bytes free " Ultimately, you are unable to distinguish the fact that parent paths directly relates to code that must be run on the system and has nothing to do with a HTTP GET request. Code Red, Code Red II, and Nimda were so insidious because of vulnerabilities within IIS and poor general patching practices by the system administration community at large. Your vulnerability to Code Red or Nimda had everything to do with having implemented a proper workaround to Code Red or Nimda, or having installed the patches from Microsoft prior to these worms hitting the net. In the case of these two worms, disabling parent paths was not a valid workaround to overcome the vulnerability. Most hacked IIS servers that I repair end up defaced because of improper NTFS permissions. Typical attack vectors that are common are insecure file upload scripts and brute forced FTP accounts. Generally speaking, these attacks do not rely on being able to obtain an administrator access. They also do not depend on parent paths. They exploit the fact that many Windows servers are run with people who have no clue and have improperly configured NTFS permissions, which allows any authenticated user account permissions on most or all customer uploaded data. Please show me any reliable, empirical evidence that parent paths is an attack vector or even a contributing factor to the success of Code Red or Nimda and I will go away. However, continue to present completely misinformed information and I will be happy to continue rebutting your posts. -Jay -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Sent: Monday, April 03, 2006 8:47 PM To: [email protected] Subject: Re: [Declude.JunkMail] Declude 4.1 Is Out Jay, Code Red and Nimda, the two biggest worms in the history of the Internet, used vulnerabilities aided by directory transversal (Parent Paths enabled) along with default permissions and paths to infect millions of servers. Servers that weren't patched for the specific vulnerability exploited by these worms could not be infected if websites were not installed on the same drive as the system root, or if they had Parent Paths disabled. Most IIS servers that are hacked are done so with some form of directory transversal. The success of these worms caused Microsoft to redesign default permissions and disable Parent Paths by default in IIS 6.0. I'm surprised that there was any debate about this whatsoever. Matt Jay Sudowski - Handy Networks LLC wrote: >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: [email protected] >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: [email protected] >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: [email protected] >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: [email protected] >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: [email protected] >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. > > > > --- 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.
