IIS6 + latest beta of IIRF (and 2.0 stable) cause security hole to be detected.

Topics: Developer Forum
May 1, 2010 at 10:02 PM

There's a software package called IISProtect that created the exact following condition - our PCI scanning software detects this as an IIS Protect issue, but since I don't use that software (and the problem goes away if I disable IIRF), I feel confident in saying that this is an IIRF issue.

IIRF is installed in ISAPI filers under my domain, xyz.com, with Wordpress installed under /blog/wp-includes
When I browse to xyz.com/blog/wp-includes/ , I get a Virtual Directory Listing Denied message. All well and good.
When I browse to xyz.com/blog/%77p-includes/ (same URL just encoded), I get wordpress telling me that there are no active posts - i.e. the encoding somehow breaks the Virtual Directory Listing Denied post.

I've been struggling with my PCI auth company, but I need to get this fixed -- any suggestions? It seems like a bug in IIRF..

===

What logging should I include?

Coordinator
May 1, 2010 at 10:37 PM
Edited May 1, 2010 at 10:51 PM
rizwank wrote:

IIRF is installed in ISAPI filers under my domain, xyz.com, with Wordpress installed under /blog/wp-includes
When I browse to xyz.com/blog/wp-includes/ , I get a Virtual Directory Listing Denied message. All well and good.
When I browse to xyz.com/blog/%77p-includes/ (same URL just encoded), I get wordpress telling me that there are no active posts - i.e. the encoding somehow breaks the Virtual Directory Listing Denied post.

I've been struggling with my PCI auth company, but I need to get this fixed -- any suggestions? It seems like a bug in IIRF..

 Before concluding that this is due to a bug in IIRF, I need to understand what you're doing.

You mentioned a virtual directory listing denied issue, but no where in your description do you descrive a virtual directory listing occurring.  You said that when you use IIRF, Wordpress returns some information, but if I understand what you wrote, a response from wordpress is not a virtual directory listing, right?  So what does the virtual directory listing have to do with the situation?

I can imagine a simple rule that rewrites incoming requests to ... a wordpress URL that then returns "there are no active posts".  This wouldn't be a bug.  Are you saying it is?

I also don't understand what the IISProtect thing has to do with anything. 

Maybe we can just focus on the things you observe and why you think they're bugs in IIRF.


Thinking about what you wrote a little further, I'm going to guess at what you're seeing and reporting:  you have an tool that analyzes IIS security. (I think that is the IIS Protect thing you mentioned).  If I am right, It checks to see if IIS returns results when requests ending in a slash are sent to the server. Without IIRF, such a request gets a "Virtual Directory Listing Denied" message.  With IIRF, there is a different response. IIS Protect then reports a security error. 

If so, it's a false alarm.  It's not a directory listing.  It's a response from wordpress.  The response from wordpress comes because you've used IIRF to rewrite a request for a directory, into a request for something else.  If you don't want that to happen, in other words if you want requests that end in slash to always generate a "directory listing denied" message, then you need to properly set the IIRF rules to do that.

 

May 2, 2010 at 2:11 AM

Something's odd with his description, because I wouldn't necessarily expect a request ending in a slash to return a "Virtual Directory Listing Denied error", I'd expect it to return whatever the Vhost has designated as the highest priority default page.  The only time I'd expect the denied error is if there were *no* files matching any of the files listed in the default list.  Which to me means that assuming that a link ending in a slash should return a listing denied error is just flat out wrong.

I would guess that IIRF breaks the whatever the PCI scanning software's assumptions are.  It probably assumes that whatever URL that IIS receives, is the URL that it processes.  IIRF completely breaks that assumption, and could certainly cause false positives. I looked up IISProtect and it seems to be an ISAPI that provides separately managed (i.e. not ntfs based) user and group authentication accounts.  To be honest I have no idea why one would want to use this with Wordpress, since Wordpress provides it's *own* non-ntfs user account, authentication, and authorization management interfaces, and most of the data is pulled from a database anyway.

rizwank needs to specify exactly *why* the software is saying there's a security risk.  What's happening that's no supposed to?  Nothing described at this point is unexpected or improper.

 

Coordinator
May 5, 2010 at 9:54 PM

Randy, I think similarly.  the PCI software has some assumptions, and the use of IIRF is breaking those assumptions.  That's what I think.

Any response, rizwank?