Page 1 of 2 12 LastLast
Results 1 to 10 of 18

Thread: Vulnerabilities

  1. #1
    Newbie
    Join Date
    Nov 2008
    Posts
    8

    Default Vulnerabilities

    So I decided to test my Untangle box with a Qualys vulnerability scan. At the moment, I have the UT setup as a router and it is behind an FIOS Actiontec router that is setup as a router (back from bridge mode to test some DVR functions). I have two ports forwarded from the Actiontec to the UT, ports 443 and 1149 for OpenVPN and OpenVPN client distribution.

    Other than the expected SSL cert issues that the scan found, there were two other findings that it called out.

    1. Netscape/OpenSSL Cipher Forcing Bug port 443/tcp over SSL

    QID:
    38284
    Category:
    General remote services
    CVE ID:
    -
    Vendor Reference
    -
    Bugtraq ID:
    -
    Service Modified:
    02/17/2010
    User Modified:
    -
    Edited:
    No

    CVSS Base:
    2.6[1]
    CVSS Temporal:
    2.2

    THREAT:
    Netscape's SSLv3 implementation had a bug where if a SSLv3 connection is initially established, the first available cipher is used. If a session is resumed, a different cipher may be chosen if it appears in the passed cipher list before the session's current cipher. This bug can be used to change ciphers on the server.

    OpenSSL contains this bug if the SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG option is enabled during runtime. This option was introduced for compatibility reasons.

    The problem arises when different applications using OpenSSL's libssl library enable all compatibility options including SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG, thus enabling the bug.
    IMPACT:
    A malicious legitimate client can enforce a ciphersuite not supported by the server to be used for a session between the client and the server. This can result in disclosure of sensitive information.
    SOLUTION:
    Patch:
    This bug appears to be fixed in OpenSSL 0.9.8j and later. Refer to Changes between 0.9.8i and 0.9.8j at OpenSSL Changelog to obtain additional details. The latest version of OpenSSL is available for download at OpenSSL Download Page.

    Workaround:
    This problem can be fixed by disabling the SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG option from the options list of OpenSSL's libssl library. This can be done by replacing the SSL_OP_ALL definition in the openssl/ssl.h file with the following line:

    #define SSL_OP_ALL (0x00000FFFL^SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG)

    The library and all programs using this library need to be recompiled to ensure that the correct OpenSSL library is used during linking.
    COMPLIANCE:
    Not Applicable
    EXPLOITABILITY:
    There is no exploitability information for this vulnerability.
    RESULTS:
    NULL-SHA:NULL-MD5:ADH-AES256-SHAHE-DSS-AES256-SHA:ADH-AES128-SHAHE-DSS-AES128-SHA

    2. Web Directories Listable Vulnerability port 443/tcp

    QID:
    86445
    Category:
    Web server
    CVE ID:
    -
    Vendor Reference
    -
    Bugtraq ID:
    -
    Service Modified:
    05/04/2009
    User Modified:
    -
    Edited:
    No

    CVSS Base:
    5[1]
    CVSS Temporal:
    4.7

    THREAT:
    The Web server has some listable directories. Very sensitive information can be obtained from directory listings.
    IMPACT:
    A remote user may exploit this vulnerability to obtain very sensitive information on the host. The information obtained may assist in further attacks against the host.
    SOLUTION:
    Disable directory browsing or listing for all directories.
    COMPLIANCE:
    Not Applicable
    EXPLOITABILITY:
    There is no exploitability information for this vulnerability.
    RESULTS:
    Listable Directories
    /images/


    I verified that the "images" directory is indeed listable without authentication. This would be a PCI failure for the UT. This could be limited by selecting specific IPs for remote connection, but that is a compensating control and not true remediation of this issue.

    Just figured that I would let people know. Once I put the Actiontec back into bridge mode, I will scan the UT again and post the results.

    Regards,

    MJ
    Last edited by MumblyJoe; 09-28-2010 at 04:56 PM.

  2. #2
    Newbie
    Join Date
    Nov 2008
    Posts
    8

    Default

    Oops, forgot one finding:


    Web Server HTTP Trace/Track Method Support Cross-Site Tracing Vulnerability port 443/tcp



    QID:
    86473
    Category:
    Web server
    CVE ID:
    CVE-2004-2320 CVE-2007-3008
    Vendor Reference
    -
    Bugtraq ID:
    -
    Service Modified:
    11/19/2008
    User Modified:
    -
    Edited:
    No

    CVSS Base:
    5.8
    CVSS Temporal:
    4.3

    THREAT:
    A Web server was detected that supports the HTTP TRACE method. This method allows debugging and connection trace analysis for connections from the client to the Web server. Per the HTTP specification, when this method is used, the Web server echoes back the information sent to it by the client unmodified and unfiltered. Microsoft IIS web server uses an alias TRACK for this method, and is functionally the same.

    A vulnerability related to this method was discovered. A malicious, active component in a Web page can send Trace requests to a Web server that supports this Trace method. Usually, browser security disallows access to Web sites outside of the present site's domain. Although unlikely and difficult to achieve, it's possible, in the presence of other browser vulnerabilities, for the active HTML content to make external requests to arbitrary Web servers beyond the hosting Web server. Since the chosen Web server then echoes back the client request unfiltered, the response also includes cookie-based or Web-based (if logged on) authentication credentials that the browser automatically sent to the specified Web application on the specified Web server.

    The significance of the Trace capability in this vulnerability is that the active component in the page visited by the victim user has no direct access to this authentication information, but gets it after the target Web server echoes it back as its Trace response.

    Since this vulnerability exists as a support for a method required by the HTTP protocol specification, most common Web servers are vulnerable.

    The exact method(s) supported, Trace and/or Track, and their responses are in the Results section below.
    IMPACT:
    If this vulnerability is successfully exploited, users of the Web server may lose their authentication credentials for the server and/or for the Web applications hosted by the server to an attacker. This may be the case even if the Web applications are not vulnerable to cross site scripting attacks due to input validation errors.
    SOLUTION:
    Solutions for some of the common Web servers are supplied below. For other Web servers, please check your vendor's documentation.

    Apache: Recent Apache versions have a Rewrite module that allows HTTP requests to be rewritten or handled in a specific way. Compile the Apache server with the mod_rewrite module. You might need to uncomment the 'AddModule' and 'LoadModule' directives in the httpd.conf configuration file. Add the following lines for each virtualhost in your configuration file (Please note that, by default, Rewrite configurations are not inherited. This means that you need to have Rewrite directives for each virtual host in which you wish to use it):

    <IfModule mod_rewrite.c>
    RewriteEngine on
    RewriteCond %{REQUEST_METHOD} ^TRACE
    RewriteRule .* - [F]
    </IfModule>

    With this configuration, Apache catches all TRACE requests, and replies with a page reporting the request as forbidden. None of the original request's contents are echoed back.

    A slightly tighter fix is to use:

    <IfModule mod_rewrite.c>
    RewriteEngine on
    RewriteCond %{REQUEST_METHOD} !^(GET|POST|HEAD)$
    RewriteRule .* - [F]
    </IfModule>

    Please note that RewriteEngine can be processor intensive and may impact the web server performance. The trace method can also be controlled by use of the TraceEnable directive.
    In the httpd.conf add or modify:

    TraceEnable Off

    Microsoft IIS: Microsoft released URLScan, which can be used to screen all incoming requests based on customized rulesets. URLScan can be used to sanitize or disable the TRACE requests from the clients. Note that IIS aliases 'TRACK' to 'TRACE'. Therefore, if URLScan is used to specfically block the TRACE method, the TRACK method should also be added to the filter.

    URLScan uses the 'urlscan.ini' configuration file, usually in \System32\InetSrv\URLScan directory. In that, we have two sections - AllowVerbs and DenyVerbs. The former is used if the UseAllowVerbs variable is set to 1, else (if its set to 0), the DenyVerbs are used. Clearly, either can be used, depending on whether we want a Default-Deny-Explicit-Allow or a Default-Allow-Explicit-Deny policy. To disallow TRACE and TRACK methods through URLScan, first remove 'TRACK', 'TRACE' methods from the 'AllowVerbs' section and add them to the 'DenyVerbs' section. With this, URLScan will disallow all 'TRACE' and 'TRACK' methods, and generate an error page for all requests using that method. To enable the changes, restart the 'World Wide Web Publishing Service' from the 'Services' Control Panel item.

    Sun ONE/iPlanet Web Server: Here are the sun recommandations to disable the trace method.

    For more details about other web servers : Cert Advisory.
    COMPLIANCE:
    Not Applicable
    EXPLOITABILITY:
    There is no exploitability information for this vulnerability.
    RESULTS:
    TRACE / HTTP/1.1
    Host:
    Via: <script>alert('QualysXSS');</script>



    HTTP/1.1 200 OK
    Date: Wed, 29 Sep 2010 00:06:31 GMT
    Server: Apache/2.2.9 (Debian) mod_jk/1.2.26 mod_python/3.3.1 Python/2.5.2 mod_ssl/2.2.9 OpenSSL/0.9.8g
    Transfer-Encoding: chunked
    Content-Type: message/http

    TRACE / HTTP/1.1
    Host:
    Via: <script>alert('QualysXSS');</script>

    -CR-TRACE / HTTP/1.0
    Via: <script>alert('QualysXSS');</script>



    HTTP/1.1 200 OK
    Date: Wed, 29 Sep 2010 00:06:31 GMT
    Server: Apache/2.2.9 (Debian) mod_jk/1.2.26 mod_python/3.3.1 Python/2.5.2 mod_ssl/2.2.9 OpenSSL/0.9.8g
    Connection: close
    Content-Type: message/http

    TRACE / HTTP/1.0
    Via: <script>alert('QualysXSS');</script>


    This too would be a PCI failure.
    Last edited by MumblyJoe; 09-28-2010 at 05:23 PM.

  3. #3
    Untangle Ninja sky-knight's Avatar
    Join Date
    Apr 2008
    Location
    Phoenix, AZ
    Posts
    26,554

    Default

    /etc/apache2/conf.d/security

    Last directive in the file, TraceEnable Off

    A DEFAULT directive in all Debian based installations, that disables the HTTP Trace command. If that one vulnerability is so easily proven to not be the case what about the others?

    Many have come here with random pen tests in the past with similar reports. And all of them before have been similarly laughed right off the forums. Have you investigated these vulnerabilities yourself? Or are you just spitting back the report that doesn't know what it's talking about for our edification?
    Rob Sandling, BS:SWE, MCP
    NexgenAppliances.com
    Phone: 866-794-8879 x201
    Email: support@nexgenappliances.com

  4. #4
    Untangle Ninja Solignis's Avatar
    Join Date
    Jul 2008
    Location
    Hudson, Ohio, USA
    Posts
    1,697

    Default

    I remember a while back people were up in arms over ShieldsUP by GRC.

    That was actually slightly comical in nature. according to that site I am riddled with holes.

    But after doing some research I found that it was all smoke and mirror tricks and I was locked down like a prision.

    My personal opinion, if it does not come from a company like ESET or i hate to say, Symantec or even Sophos. It really is nothing to be worried about unless you actively notice unusually behaviors on your network.
    “Most good programmers do programming not because they expect to get paid or get adulation by the public, but because it is fun to program.” - Linus Torvalds

  5. #5
    Newbie
    Join Date
    Nov 2008
    Posts
    8

    Default

    Vulnerability scanning is what I currently do at my day job, so no, no random spitting.

    Just pointing these out so that they can addressed by the devs. I have investigated them and I know how to fix the findings, but I am pointing out what a default scan is showing and what an end-user using this scanning engine would see.

    Also, Qualys is currently one of the largest vulnerability scanning engines around. A large amount of the Fortune 500 are using it for vulnerability and PCI scanning.

    MJ
    Last edited by MumblyJoe; 09-28-2010 at 05:58 PM.

  6. #6
    Untangle Ninja Solignis's Avatar
    Join Date
    Jul 2008
    Location
    Hudson, Ohio, USA
    Posts
    1,697

    Default

    I just wanted to say I based on what I said I am not discounting your job, I was sorta pointing out that Untangle is a bit different than some other UTM / Firewalls.

    It does not behave the same way, so if a website says there are holes it might not mean anything to Untangle but it might be a huge problem to someone like Sonicwall.

    The reason I was saying what I was saying is simply because all too often people show up on the forums screaming about how AVG said they found a massive hole in Untangle but it ended up being a gross misunderstanding.
    “Most good programmers do programming not because they expect to get paid or get adulation by the public, but because it is fun to program.” - Linus Torvalds

  7. #7
    Newbie
    Join Date
    Nov 2008
    Posts
    8

    Default

    I understand that Untangle is different and I took no offensive to your comments (although I it may have come off like that now that I reread my comments). Also, these findings are not game breakers, just PCI failures. PCI is about compliance to a standard, not necessarily security.

    I am just trying to provide feedback in case a client is attempting to get a UT PCI certified. A lot of the rules changed as of September 1st of this year.

    I love my UT and recommend it all the time.

    MJ

  8. #8
    Newbie
    Join Date
    Nov 2008
    Posts
    8

    Default

    Also, I should point out that my UT install has been around through my version upgrades. Trace was enabled on my installation (not anymore), but it may have been an artifact from the old installation and may not present on a fresh install.

    MJ

  9. #9
    Untangle Ninja proactivens's Avatar
    Join Date
    Sep 2008
    Location
    Greensburg, Pa
    Posts
    2,362

    Default

    So create a packet filter rule

    Action: Drop
    Source Interface: External
    Destination port: 443

    Save

    Re-run the tests and it'll pass. The things the scanner are reporting are the external admin interface for Untangle. Its a bad security practice to expose your edge router's management interface to the internet anyway, we dont need a security scan to tell us that much. If you need HTTPS for an internal server than port forward port 443 and change the admin interface of Untangle to something else, disable it, and then enter that port into the packet filter rule above and problem solved.
    www.nexgenappliances.com
    Toll Free: 866-794-8879
    UNTANGLE STAR PARTNER
    Follow us at spiceworks!

  10. #10
    Untangle Ninja sky-knight's Avatar
    Join Date
    Apr 2008
    Location
    Phoenix, AZ
    Posts
    26,554

    Default

    Well I don't know how to get that test to pass the TRACE issue, because it's already disabled and if you manually check the TRACE command with telnet it won't work.

    As for the most of the rest, what you do is insert a packet filter rule to prevent access to TCP 443 for the scan.

    The SSL vulnerabilities are all bogus, I know that from old posts. The vulnerabilities in question ARE real for the versions used. But, Untangle has incorporated all the backports from the Debian project that patch all of those holes. I haven't seen a single pen test report that we haven't been able to go through one result at a time and knock down.

    So forgive me for being lazy, but I don't see a point in doing that again. At least not for free.

    P.S. That Trace command has been disabled since I've been around. That's 5.1 onward.
    Rob Sandling, BS:SWE, MCP
    NexgenAppliances.com
    Phone: 866-794-8879 x201
    Email: support@nexgenappliances.com

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

SEO by vBSEO 3.6.0 PL2