COMMAND
SecureIIS
SYSTEMS AFFECTED
SecureIIS 1.0.3
PROBLEM
ASLabs (namely C-3P0 and R2-D2) found some problems with eEye's
SecureIIS. 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.
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
user=ADMIN
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
page=/../../boot.ini
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]
SOLUTION
To download the latest version of SecureIIS (v.1.0.4) then visit
the SecureIIS website at:
http://www.eeye.com/secureiis/
They have updated SecureIIS to properly handle various web
encoding methods including unicode and hex (%) style encoding.
They have also updated SecureIIS to perform keyword checking on
POST data.
eEye enabled individual header length checking in SecureIIS 1.0.4.