Users login

Create an account »


Users login

Home » Hacking News » Multiple Security Problems in eEye SecureIIS

Multiple Security Problems in eEye SecureIIS

by phiber on May 20th, 2001 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.


This is an Alliance Security Labs Advisory ID:ASLabs-2001-01

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


POST /whatever.script HTTP/1.0

Content-Type: application/x-www-form-urlencoded

Content-Length: 10


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


POST /whatever.script HTTP/1.0

Content-Type: application/x-www-form-urlencoded

Content-Length: 20


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.


eEye released SecureIIS 1.0.4 which has this vulnerabilities fixed. More information here.

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 1.0.2. cannot be trusted with protecting web-sites, and eEye users need to find other ways to protect their sites.

Newsletter signup

Signup to our monthly newsletter and stay in touch with IT news!

Free E-books

We've got ebooks! But they're not online. :( Please give us a few days to bring downloads back.


Have something to say or just wanna drop us a line? Please keep this in mind: to spam, we reply with spam.

Contact us »