[NT] ISAPI Priority Issue with IIS (NetPoint)

From: support@securiteam.com
Date: 02/07/02

From: support@securiteam.com
To: list@securiteam.com
Date: Thu,  7 Feb 2002 23:23:54 +0100 (CET)

The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

When was the last time you checked your server's security?
How about a monthly report?
http://www.AutomatedScanning.com - Know that you're safe.
- - - - - - - - -

  ISAPI Priority Issue with IIS (NetPoint)


 <http://www.oblix.com/products/netpoint/net_description.html> Oblix
NetPoint creates a unified e-business infrastructure by providing an
integrated access control and identity management solution that can be
extended to all e-business initiatives. When combined with WebSphere, a
security flaw is exposed that allow bypassing of security restrictions
imposed on the resource (JSP, or otherwise).


The way Oblix works is that it installs an ISAPI (called WebGate) filter
in IIS to capture all HTTP requests. Then every captured incoming HTTP
requests, is checked for an Oblix cookie, and if there is not one, returns
a challenge screen to the client browser. Once the client has logged in,
WebGate then redirects the browser to the original request that was made
for the resource. WebGate monitors all subsequent requests for resources
to ensure the client has the proper authorization level for that resource.

The problem comes in when trying to secure a resource that contains
servlets/JSPs whose requests are handled by WebSphere 4.0.1. Both the
WebSphere ISAPI filter and the Oblix WebGate ISAPI filter are installed on
the same webserver with a priority of 'high'. Note that both filters are
installed at the "server" level, not the website level. The Oblix filter
is at the top of the list in IIS so it should take the highest priority of
all the "high" priority plugins. It appears that if we hit a URL that is
handled by 'WAS', IIS executes the 'WAS' ISAPI filter before executing the
Oblix filter, which is not correct. The result is that requests made to a
resource that 'WAS' should handle are not secured.

Here are the testing results on various platforms:

 - JRun 3.0 was installed (works similar to WAS global ISAPI filter
plugin) on a Windows NT SP6 IIS 4 box, the JRun resources were secured
 - WAS 4.0.1 was installed on a Windows NT sp6 IIS 4 box, the WAS
resources were also secured correctly
 - JRun was installed on a Windows 2000 IIS 5 box (with the ISAPI filter
plugin), the resources were not secured. This appeared to have the same
result as with WAS, it appeared to hit the JRun ISAPI filter first
 -.asp resource was tested on Windows 2000 IIS 5, however .asps are mapped
using ISAPI extensions vs. ISAPI filters. This resource was secured, as it
should have.
 - The JRun ISAPI filter was removed, and mapped a .JSP using the ISAPI
extension, which also worked as it should.
 - WAS and Oblix were installed on a "clean" Windows 2000 IIS 5 box, and
the problem repeated.
 - The URLScan IIS security plugin was removed from the tested boxes.

Note: All IIS 5 boxes tested had some standard security "hardening" on
them (Microsoft Security Utility).

The above test results leads to the conclusion that the problem is related
to one of the following:
A) IIS5.0 does not handle ISAPI filter priorities correctly (for any
number of reasons, general bug, security patch, configuration, etc).
B) Both WAS and JRun filters have bugs on IIS 5
C) Security hardening of the OS caused problems (still need to test). The
request is actually going to the Oblix filter. However, it is not doing
anything with it (this is not likely, especially since we do not see any
requests in the Oblix WebGate ISAPI trace log).


The information has been provided by
<mailto:matt.davis@COUNTRYFINANCIAL.COM> Davis, Matt.


This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com


The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.