ASLabs-2001-01: Multiple Security Problems in eEye SecureIIS

[Alliance Security Labs <AllianceSecurityLabs () safe-mail net>]

=>=>=> Alliance Security Labs <=<=<=

=>=>=> ASLabs-2001-01: Multiple Security Problems in eEye SecureIIS
<=<=<=

Advisory ID: ASLabs-2001-01

Vendor: eEye (http://www.eEye.com)

Product: SecureIIS
(http://www.eeye.com/html/Products/SecureIIS/index.html)

Versions: v1.0.2 (latest available) - probably relevant for < 1.0.2 as
well.

Platform: Checked for Windows/NT 4.0 SP5, probably relevant for all
Windows/NT 4.0 (IIS 4.0) and Windows/2000 (ISS 5.0).

Severity: High - False sense of security. Breach of privacy. Exposure of

internal data. Degradation of site security.

Product description (from
http://www.eeye.com/html/Products/SecureIIS/index.html):
SecureIIS protects Microsoft IIS (Internet Information Services) Web
servers from known and unknown attacks. SecureIIS wraps around IIS and
works within it, verifying and analyzing incoming and outgoing Web
server data for any possible security breaches. It combines the best
features of Intrusion Detection Systems and Conventional Network
Firewalls all into one, and it is custom tailored to your Web server.

Release Date: May 17th, 2001.

Authors: C-3P0 and R2-D2.

Summary:
Alliance Security Labs found multiple security problems in SecureIIS
v1.0.2. These problems can expose users to security holes that SecureIIS

was designed to protect.
The problems found span several aspects in the product and can be
attributed to design flaws in SecureIIS, as well as some conceptual
oversight in the product specs.

Details:
1. Keyword checking - SecureIIS promises "By checking for common
attacker "payloads" involved with these exploits, we can prevent an
attacker from gaining unauthorized access to your Web server and its
data.". However, SecureIIS fails to decode escaped characters in the
query part of the request. Thus, "ADMIN" will be detected in the query,
but not "%41DMIN". The body part of the (POST) request is not checked at

all. For example, the following requests will not be rejected by
SecureIIS (assuming whatever.script is some script validly accessible on

the server, and suppose the user of SecureIIS does not want the script
to receive ADMIN as a value for any script parameter, so ADMIN is
configured as a keyword in SecureIIS):
 GET /whatever.script?user=%41DMIN HTTP/1.0
And:
 POST /whatever.script HTTP/1.0
 Content-Type: application/x-www-form-urlencoded
 Content-Length: 10

 user=ADMIN

2. Directory traversal - SecureIIS promises "In certain situations,
various characters and symbols can be used to break out of the Web
server's root directory and access files on the rest of the file system.

By checking for these characters and only allowing certain directories
to be accessed, directory traversal attacks are prevented.". Similar to
section #1, directory traversal is checked at the query without decoding

of escaped characters, and is not checked at all in the body part of a
(POST) request. It is possible, therefore, to use %2e instead of dot,
and %2f instead of slash, thus enabling an attacker to perform a
directory traversal attack. For example, the following requests will not

be rejected by SecureIIS (assuming whatever.script is some script
validly accessible on the server, and it handles a parameter named page
whose value may be vulnerable to directory traversal attack):
 GET /whatever.script?file=/%2e%2e/%2e%2e/boot.ini HTTP/1.0
And:
 POST /whatever.script HTTP/1.0
 Content-Type: application/x-www-form-urlencoded
 Content-Length: 20

 page=/../../boot.ini

3. Buffer Overflows - For HTTP headers, SecureIIS promises (from
explanation box in SecureIIS GUI for the Buffer Overflows item): "Many
web servers have had problems with handling request-header variables in
the past. By checking the length of these variables we can prevent many
potential buffer overflows. In this section each variable is listed with

a numeric entry specifying the maximum size of the buffer that we will
accept for that particular variable. If a client sends a variable value
with a length greater than specified in SecureIIS, the request will be
denied and the attempt will be logged.". Not so! - although the user of
SecureIIS can turn on HTTP length restriction for each of the ten or so
individual HTTP headers - in fact SecureIIS does not perform any header
length restriction for them. It does perform the check for the URL,
query and "header length" (meaning - total length of all headers). For
example, turning on Host protection (with a default limit of 256 bytes)
and sending more than 256 bytes in a host header goes through SecureIIS
and is not rejected:
 GET / HTTP/1.0
 Host: [500 x random a-z charachers]

BTW - a workaround can be to limit the total headers length, but this
imposes a severe functionality limit for the site. A common browser
generates HTTP headers with more than 300 characters - and this number
can grow for more advanced requests.

4. Buffer Overflows in SecureIIS - if the request is large (several
thousnad characters), then the following situations were noticed:
 (a) The error page is trimmed (after 3 lines). This is the most common
situation.
 (b) The error page is trimmed, and a part of the request is appended to

it.
 (c) The error page is trimmed, and a part of the PREVIOUS request is
appended to it (!).
 (d) The error page is trimmed, and some data from the SecureIIS process

memory space is  appended to it (!). We once encountered some internal
configuration data of the site (!).
This has a devastating effect - in fact to some extent it degrades the
security of the site. This is the result of the ability to see other
clients' requests (severe breach of privacy) as demonstrated in (c), as
well as the ability to see the configuration of SecureIIS as
demonstrated in (d), which reveals the server structure and soft areas
(which can be exploited using the previous 3 security problems of
SecureIIS).
It should be noted that (c) and (d) are hard to reproduce - we found no
deterministic way to demonstrate them. However, each happened several
times, so we can be assured of their existence.

Workaround: No workaround is known.

Conclusion: Having all these security problems in a security product
like eEye can be extremely damaging to users who rely on eEye to secure
their sites.
SecureIIS cannot be trusted with protecting web-sites, and eEye users
need to find other ways to protect their sites.

Copyright (c) 2001 Alliance Security Labs. Permission is hereby granted
for the redistribution of this alert electronically. It is not to be
edited in any way without express and explicit consent of Alliance
Security Labs.

Disclaimer: THE INFORMATION PROVIDED IS RELEASED BY ALLIANCE SECURITY
LABS "AS IS" WITHOUT WARRANTY OF ANY KIND. ALLIANCE SECURITY LABS
DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED. IN NO EVENT SHALL
ALLIANCE SECURITY LABS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING
DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR

SPECIAL DAMAGES.

May the Force be with you,
C-3P0 and R2-D2.