=>=>=> 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.
This archive was generated by hypermail 2b30 : Fri May 18 2001 - 11:00:42 PDT