OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Alliance Security Labs (AllianceSecurityLabssafe-mail.net)
Date: Fri May 18 2001 - 12:15:20 CDT

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    =>=>=> 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.