[NT] Unchecked Buffer in ISAPI Filter Could Allow Commerce Server Compromise

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

From: support@securiteam.com
To: list@securiteam.com
Date: Sun, 24 Feb 2002 23:19: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.
- - - - - - - - -

  Unchecked Buffer in ISAPI Filter Could Allow Commerce Server Compromise
------------------------------------------------------------------------

SUMMARY

By default, Commerce Server 2000 installs a .dll with an ISAPI filter that
allows the server to provide extended functionality in response to events
on the server. This filter, called AuthFilter, provides support for a
variety of authentication methods. Commerce Server 2000 can also be
configured to use other authentication methods.

A security vulnerability results because AuthFilter contains an unchecked
buffer in a section of code that handles certain types of authentication
requests. An attacker who provided authentication data that overran the
buffer could cause the Commerce Server process to fail, or could run code
in the security context of the Commerce Server process. The process runs
with LocalSystem privileges, so exploiting the vulnerability would give
the attacker complete control of the server.

DETAILS

Affected software:
 * Microsoft Commerce Server 2000

Mitigating factors:
 * Although Commerce Server 2000 does rely on IIS for its base web
services, the AuthFilter ISAPI filter is only available as part of
Commerce Server. Customers using IIS are at no risk from this
vulnerability.
 * The URLScan tool, if deployed using the default ruleset for Commerce
Server, would make it difficult if not impossible for an attacker to
exploit the vulnerability to run code, by significantly limiting the types
of data that could be included in an URL. It would, however, still be
possible to conduct denial of service attacks.
 * An attacker's ability to extend control from a compromised web server
to other machines would depend heavily on the specific configuration of
the network. Best practices recommend that the network architecture
account for the inherent high-risk that machines in an uncontrolled
environment, like the Internet, face by minimizing overall exposure though
measures like DMZ's, operating with minimal services and isolating contact
with internal networks. Steps like this can limit overall exposure and
impede an attacker's ability to broaden the scope of a possible
compromise.
 * While the ISAPI filter is installed by default, it is not loaded on any
web site by default. It must be enabled through the Commerce Server
Administration Console in the Microsoft Management Console (MMC).

Patch availability:
Download locations for this patch
 * Microsoft Commerce Server 2000
    <http://www.microsoft.com/Downloads/Release.asp?ReleaseID=36683>
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=36683

What is the scope of the vulnerability?
An attacker who successfully exploited this vulnerability could gain
complete control over an affected commerce web server. This would give the
attacker the ability to take any desired action on the server, including
changing web pages, reformatting the hard drive or adding new users to the
local administrators group.

The vulnerability only affects web sites that use Microsoft Commerce
Server; those using IIS are not at risk. In addition, if a recommended
tool has been applied to the server, the seriousness of the vulnerability
would be significantly reduced. Specifically, if the URLScan tool were in
use, the vulnerability could only be used to cause the service to fail,
after which point it would automatically restart itself. The URLScan tool
is not installed by default.

What causes the vulnerability?
The vulnerability results because an ISAPI filter that supports user
authentication on Commerce Server 2000 contains an unchecked buffer. By
providing especially malformed authentication information, an attacker
could create a buffer-overrun condition.

What is Microsoft Commerce Server?
Commerce Server is a web server product that is tailored for building
e-commerce sites. It provides tools and features that simplify developing
and deploying e-commerce solutions, and provides tools that let the site
administrator analyze the usage of the site.

Is Commerce Server different from Internet Information Server?
Yes. Commerce Server uses Internet Information Service (IIS) to provide
basic web server capabilities, but also includes additional features and
functions. Of particular importance in this case is the fact that the
vulnerability lays within a component that ships as part of Commerce
Server 2000 but not IIS. Because of this, IIS servers are at no risk from
this vulnerability.

What is an ISAPI filter?
ISAPI (Internet Services Application Programming Interface) is a
technology that enables developers to extend the functionality provided by
a web server. An ISAPI filter is a dynamic link library (.dll) that uses
ISAPI to respond to events that occur on the server.

What is the ISAPI filter associated with this vulnerability?
The vulnerability lies within the AuthFilter ISAPI filter. AuthFilter
provides support for a variety of authentication methods. The
vulnerability results because the code that processes the authentication
data in several of these methods contains an unchecked buffer.

What would this vulnerability enable an attacker to do?
The vulnerability could enable an attacker, by providing data that
overruns the buffer in AuthFilter, to overwrite memory within the Commerce
Server process itself.

What would this enable an attacker to do?
Depending on the specific data the attacker chose, either of two effects
could occur:
 * If the data were randomly selected, the Commerce Server process would
fail.
 * If the data were carefully selected, it could be possible for the
attacker to alter the Commerce Server software while it was running.

If the attacker provided random data, what would be required in order to
restore normal operation?
Nothing. The Commerce Server process would automatically restart itself.
However, any user sessions that were in process at the time of the attack
could be lost.

If the attacker provided carefully selected data and altered the Commerce
Server process, what could the modified process do?
The modified process would be able to take any action the attacker
directed it to. The Commerce Server process runs with LocalSystem
privileges, so the attacker could gain complete control over the server
and taken any desired action on it.

Could this vulnerability be exploited by accident?
No. Authentication data for web sites is usually submitted via a web form
that, if properly implemented, would filter data like that used to exploit
the vulnerability. (The sample web forms that ship with Commerce Server
2000 show how this should be done). The vulnerability could only be
exploited by an attacker who sent malformed authentication data directly
to the server, bypassing any web forms.

Is AuthFilter installed by default?
Yes. This is an appropriate default setting, because e-commerce sites
virtually always require authentication support.

Commerce Server 2000 can also be configured to use other authentication
methods. If another authentication method is used, then the system is not
affected by this vulnerability.

I have installed the URLScan tool on my server. Will it prevent attacks
via this vulnerability?
By default, URLScan would prevent an attacker from using the vulnerability
to gain control over the server. This is because the default ruleset for
Commerce Server outlaws certain types of data, without which it would not
be possible to modify the Commerce Server process to take meaningful
action. On the other hand, even with URLScan installed, an attacker could
still cause the Commerce Server process to fail. As a result, even
customers who are using URLScan should install the patch.

How was this vulnerability discovered?
Microsoft discovered the vulnerability internally, as part of a security
code review.

I heard that some sites already have the patch installed. Is this correct?
Yes. Microsoft contacted a small number of customers whose sites were at
particular risk from this vulnerability and provided them with the patch,
in order to give them an opportunity to secure their systems before the
bulletin was released.

I am running Site Server 3.0 Commerce Edition. Could I be affected by the
vulnerability?
No. Site Server 3.0 and Site Server 3.0 Commerce Edition, the predecessor
product to Commerce Server 2000, are not affected by the vulnerability.

What does the patch do?
The patch eliminates the vulnerability by instituting proper buffer
handling within the AuthFilter ISAPI filter.

ADDITIONAL INFORMATION

The information has been provided by <mailto:secnotif at MICROSOFT.COM>
Microsoft Product Security.

========================================

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

====================
====================

DISCLAIMER:
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.

Relevant Pages