Mantis Bugtracker - Remote Database Scanner and XSS Vulnerabilities

From: Joxean Guay del Paraguay (joxeankoret_at_yahoo.es)
Date: 09/26/05

  • Next message: Martin Schulze: "[SECURITY] [DSA 821-1] New python2.3 packages fix arbitrary code execution" 
    Date: Mon, 26 Sep 2005 12:17:35 +0200 (CEST)
To: bugtraq@securityfocus.com

    ---------------------------------------------------------------------------
        Mantis Bugtracker - Remote Database Scanner and
    XSS Vulnerabilities
    ---------------------------------------------------------------------------

    Author: Jose Antonio Coret (Joxean Koret)
    Date: 2005
    Location: Basque Country

    ---------------------------------------------------------------------------

    Affected software description:
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    Mantis Bugtracker - Mantis is a php/MySQL/web based
    bugtracking system

    Affected versions:

     + 1.0.0a3
     + 1.0.0a2
     + 1.0.0a1
     + 0.19.2
     + 0.19.1
     + 0.19.0
     + 0.19.0RC1
     + 0.19.0a2
     + 0.19.0a1

    Partially affected versions:

     + 1.0.0RC1 (A2 Cross Site Scripting Vulnerability)

    Not affected versions:

     + 1.0.0RC2
     + 0.18.3 and prior versions

    Web : http://mantisbt.sourceforge.net

    ---------------------------------------------------------------------------

    Vulnerabilities Summary
    ~~~~~~~~~~~~~~~~~~~~~~~

    A - Cross Site Scripting Vulnerabilities
    A1.- Parameter 'dir' of the script "/view_all_set.php"
    is vulnerable to XSS attacks
    A2.- XSS in /bug_actiongroup_page.php when deleting a
    bug from the /view_all_bug_page.php
    B.- Database scanner via variable poisoning in
    /core/database_api.php script
        
    Vulnerabilities
    ~~~~~~~~~~~~~~~

    A - Cross Site Scripting Vulnerabilities
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    A1.- Parameter 'dir' of the script "/view_all_set.php"
    is vulnerable to XSS attacks
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    The parameter 'dir' of the /view_all_set.php script is
    not correctly sanitize
    and is vulnerable to XSS attacks.

    The following is a sample url to check the problem:

      
    http://[target]/view_all_set.php?sort=severity&dir="><script>alert(document.cookie)</script>&type=2

    This bug is addressed as #0005959 in the MantisBT bug
    database.

    A1.- XSS in /bug_actiongroup_page.php when deleting a
    bug from the /view_all_bug_page.php
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    A Cross Site Scripting Vulnerability was found in the
    script /bug_actiongroup_page.php when deleting a bug
    from the /view_all_bug_page.php.

    To reproduce behaviour follow these steps:

            1.- Report a bug with the following summary:
    Test<script>alert(document.cookie)</script>
            2.- Enter as administrator and find the bug in
    /view_all_bug_page.php script
            3.- Select the checkbox correspondient to this bug
    and DELETE in the drop down bellow.
            4.- Press OK.
            5.- In the /bug_actiongroup_page.php you will see the
    bug to delete and also a wonderfull
                javascript alert.

    This bug may be considered as non exploitable but it
    is exploitable. If you registers only one bug is
    possible that the administrator do not selects for
    deletion it from the /view_all_bug_page.php but, what
    about if you registers 15 messages? The administrator
    surely will delete all the bugs by selecting all
    the bugs from the /view_all_bug_page.php.

    This bug is addressed as #0006002 in the MantisBT bug
    database.

    B.- Database scanner via variable poisoning in
    /core/database_api.php script
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    If the 'register_globals' directive is enabled the
    script located at /core/database_api.php
    is vulnerable to variable poisoning attacks.
     
    By exploiting the vulnerability an attacker can
    connect to databases that are in the web server LAN.

    To reproduce the behavior simply navigate to any of
    these urls:

    http://[target]/core/database_api.php?g_db_type=mysql://invaliduser@localhost:3336
    [^]
           
    http://[target]/core/database_api.php?g_db_type=mysql://root@localhost:3336
    [^]
             
    http://[target]/core/database_api.php?g_db_type=informix://localhost:8080
    [^]

    Due to this vulnerability an attacker can write a
    database scanner or a network scanner by simply
    changing the hostname and port and parsing the
    responses.

    Examples:
            1.-
    http://[target]/core/database_api.php?g_db_type=mysql://root@localhost
    [^]
            (Fast response)

            2.-
    http://[target]/core/database_api.php?g_db_type=mysql://root@192.168.1.1
    [^]
            (No response in about 30 seconds)

            3.-
    http://[target]/core/database_api.php?g_db_type=mysql://root@10.x.y.z
    [^]
            (Response in about 3 seconds)

    A remote user can supply a specially crafted URL to
    scan arbitrary ports on arbitrary
    hosts using a URL with the following form:
     
     
    http://[target]/core/database_api.php?g_db_type=<database
    type>://<hostname>:<port>

    Based on the Response Time and the Response returned
    by MantisBT, the remote user can
    determine whether the specified port on the specified
    host is open or closed. As a consecuence,
    a remote user can invoke MantisBT to scan arbitrary
    ports on arbitrary hosts.

    This bug is addressed as #0005956 in the MantisBT bug
    database.

    Notes about issue #0005956
    ~~~~~~~~~~~~~~~~~~~~~~~~~~

    1.- This vulnerability doesn't allow an attacker to
    run SQL commands against the database.

    2.- Not all sites running Mantis Bugtracker are
    vulnerables. This only works if the 'register_globals'

    directive is On. If you're unsure if your site is
    vulnerable you can try the provided exploit,
    called 'exploit.py'.

    Workarounds:
    ~~~~~~~~~~~~

    There is no known workaround for the #0005959 and
    #0006002 issues.

    For #0005956 issue you only need to DISABLE the f* PHP
    directive 'register_globals'.

    Patches:
    ~~~~~~~~

    The followings are patches that solves the #0005956,
    #0005959 and #0006002 issues.

    Patch for issue #0005959

    -----------------------------------------------------------------------------------------------------------------------
    --- filter_api.orig 2005-07-18 17:07:03.000000000
    +0200
    +++ filter_api.php 2005-07-18 17:06:15.000000000 +0200
    @@ -753,7 +753,7 @@
     ?>
     
                     <br />
    - <form method="post" name="filters" action="<?php
    PRINT $t_action; ?>">
    + <form method="post" name="filters" action="<?php
    PRINT htmlentities($t_action); ?>">
                     <input type="hidden" name="type" value="5" />
                     <?php
                             if ( $p_for_screen == false ) {
    @@ -761,10 +761,10 @@
                                     PRINT '<input type="hidden" name="offset"
    value="0" />';
                             }
                     ?>
    - <input type="hidden" name="sort" value="<?php PRINT
    $t_sort ?>" />
    - <input type="hidden" name="dir" value="<?php PRINT
    $t_dir ?>" />
    - <input type="hidden" name="page_number"
    value="<?php PRINT $p_page_number ?>" />
    - <input type="hidden" name="view_type" value="<?php
    PRINT $t_view_type ?>" />
    + <input type="hidden" name="sort" value="<?php PRINT
    htmlentities($t_sort) ?>" />
    + <input type="hidden" name="dir" value="<?php PRINT
    htmlentities($t_dir) ?>" />
    + <input type="hidden" name="page_number"
    value="<?php PRINT htmlentities($p_page_number) ?>" />
    + <input type="hidden" name="view_type" value="<?php
    PRINT htmlentities($t_view_type) ?>" />
                     <table class="width100" cellspacing="1">
                     
                     <?php
    -----------------------------------------------------------------------------------------------------------------------
            
    Patch for issue #0005956

    -----------------------------------------------------------------------------------------------------------------------
    --- database_api.orig 2005-07-18 16:43:36.000000000
    +0200
    +++ database_api.php 2005-07-18 16:49:43.000000000
    +0200
    @@ -9,6 +9,13 @@
             # $Id: database_api.php,v 1.42 2005/02/26
    15:16:46 thraxisp Exp $
             #
    --------------------------------------------------------
     
    + #
    + # Patch for #0005956: Database system scanner via
    variable poisoning
    + #
    +
    + if ((isset($_GET["g_db_type"])) ||
    (isset($_POST["g_db_type"])))
    + die("");
    +
             ### Database ###
     
             # This is the general interface for all
    database calls.
    -----------------------------------------------------------------------------------------------------------------------

    Patch for issue #0006002

    -----------------------------------------------------------------------------------------------------------------------
    --- bug_actiongroup_page.orig 2005-07-24
    04:14:11.000000000 +0200
    +++ bug_actiongroup_page.php 2005-07-24
    04:13:31.000000000 +0200
    @@ -114,7 +114,7 @@
     foreach( $f_bug_arr as $t_bug_id ) {
             $t_class = sprintf( "row-%d", ($t_i++ % 2) + 1 );
             $t_bug_rows .= sprintf( "<tr bgcolor=\"%s\">
    <td>%s</td> <td>%s</td> </tr>\n"
    - , get_status_color( bug_get_field( $t_bug_id,
    'status' ) ), string_get_bug_view_link( $t_bug_id ),
    bug_get_field( $t_bug_id, 'summary' )
    + , get_status_color( bug_get_field( $t_bug_id,
    'status' ) ), string_get_bug_view_link( $t_bug_id ),
    htmlentities(bug_get_field( $t_bug_id, 'summary' ))
         );
             echo '<input type="hidden" name="bug_arr[]" value="'
    . $t_bug_id . '" />' . "\n";
     }
    -----------------------------------------------------------------------------------------------------------------------
     
    The fix:
    ~~~~~~~~

    Issues #0005956 and #0005959 are correcteds in version
    1.0.0RC1.
    Alternatively, you can use the attacheds non-official
    patches.

    How to apply the patches:
    ~~~~~~~~~~~~~~~~~~~~~~~~~

    To apply the patches follow these steps:

            1.- Download (or copy/paste) the patch (or patches)
    that you need (i.e.: 0005956.patch).
            2.- Copy the patch to your local '<mantis_dir>/core/'
    directory. (i.e.: in my
                Debian Sarge distribution this is located under
    /usr/local/mantis/gui/core).
            3.- Execute the following command:

                    $ patch -p0 < 0005956.patch

    After applying the patch:
    ~~~~~~~~~~~~~~~~~~~~~~~~~

    If you have been applied the patch and you're not sure
    if your system is vulnerable
    or not, you can run the attached exploit called
    (originally...) 'exploit.py' and
    follow the instructions.

    NOTE: This exploit only probes the issue #0005956.

    Notes
    ~~~~~

    Thanks to Victor Boctor, and all the Mantis Bugtracker
    guys. The were very kind and
    proffessionals.

    Disclaimer:
    ~~~~~~~~~~~

    The information in this advisory and any of its
    demonstrations is provided
    "as is" without any warranty of any kind.

    I am not liable for any direct or indirect damages
    caused as a result of
    using the information or demonstrations provided in
    any part of this
    advisory.

    ---------------------------------------------------------------------------

    Contact:
    ~~~~~~~~

            Joxean Koret at joxeanpiti<<<<<<<<@>>>>>>>>yah00<<<<<<dot>>>>>es

            
            
                    
    ______________________________________________
    Renovamos el Correo Yahoo!
    Nuevos servicios, más seguridad
    http://correo.yahoo.es

  • Next message: Martin Schulze: "[SECURITY] [DSA 821-1] New python2.3 packages fix arbitrary code execution"

    Relevant Pages