Likes Likes:  0
Resultaten 1 tot 3 van de 3
Geen
  1. #1
    Luca Falavigna
    Possible bug in PHPNuke and other CMS
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Possible bug in PHPNuke and other CMS

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    There is a vulnerability in PHPNuke that permits execution of arbitrary
    SQL queries on a database located in the same server of an attacker's
    account. This is the procedure: first of all attacker must create a
    symlink pointing to victim's db directory in PHPNuke home directory
    because of mainfile.php include method. After that he can build a simple
    php code executing a query to the PHPNuke database. Here is an example:

    <?php
    require_once ("/location_of_victim's_PHPNuke/mainfile.php");
    $sql = $db->sql_query("SELECT aid,pwd FROM ".$prefix."_authors");
    while($record = $db->sql_fetchrow($sql))
    ~ echo "Username: $record[aid]\n<br>\nPassword: $record[pwd]\n<br><br>\n";
    unset($sql);
    ?>

    Queries are executed normally because config.php (which is included by
    mainfile.php) provides the information in order to connect to the chosen
    database. This is a very easy way to deface PHPNuke-based websites or
    adding and removing users, and so on.

    This "homemade patch" goes in config.php, just below connection
    variables. It checks domain name provided by web server with the one
    provided by the user and grants execution of SQL queries only if domain
    names match. Here is the code:

    $domainname = "www.example.com";
    if ($_SERVER['SERVER_NAME'] != $domainname ) {
    ~ echo "Access denied";
    ~ die();
    }

    This vulnerability isn't only for PHPNuke, but also for every CMS that
    doesn't check domain names.

    Greetings,

    Luca Falavigna

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.1 (GNU/Linux)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iQEVAwUBQLn1V/TtdJayrm9xAQL8jAf+MV1wlF5MJW8nDez3kOoHugvqmb2L2ftG
    kwkEfl/zERPfsu651/PM9ocDkm1z+pLJh6kzPusED2GVuZOGY9Gbd5P5dOjGc7qX
    OqEzXMRWkX3r2joAzyjKsO24sAc4YNI0FQPPFve9sZqRMdG+vF 4VzIoldjiegSVH
    d5rLceL/AojrzEakUiBGBUuKJN/k0uG3NzACra3Oa8haMwlTvQmY0VRjSgGArCq2
    ohpSlCTZOk4iANYJXHaZE0u+Ep0t4UOCZK9j/jM8rjMdpCynWCkGo/FzcreakHom
    FCHAR9m0LJ0UuuPU/1VbamwZ6OlNhdMWau9wIKJGW0bsWnzSwd7llg==
    =JnMQ
    -----END PGP SIGNATURE-----


  2. #2
    Luca Falavigna
    Possible bug in PHPNuke and other CMS
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: Possible bug in PHPNuke and other CMS

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Alexander GQ Gerasiov ha scritto:
    |
    | I'm sure that such problems must be fixed not with some hacks like
    | yours (checking domain name), but with webserver configuration (uid
    | and permissions, php abilities (like safe mode or open_base_dir
    | option) etc.)
    |

    File permissions must always permit execution of php pages by web
    servers. And symlink is followed and code executed because web servers
    must have access to that directory and code. We can operate with php
    security options too and obtain the same result but what if we cannot
    modify them? We are uncovered!!!

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.1 (GNU/Linux)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iQEVAwUBQLy5UPTtdJayrm9xAQJYsggAjH3AAqT6olYdcnK6Oo n91TtPDk96ajSC
    JCJbqcdjRgGeOWq7YczYvysr7ff/splZZ6f1wMWbJwcmFntE/gWdRmU2+Y0/4sHv
    P4w9Cymmdhhc8E91KqYUfJNYFqWhGfdjaCsZ6p+8tj/+hm/ZPWFuU+2mI+8T4S6i
    lEEveVl3DiUfG4oxImOyn/6vAgmUcnMkL/qm+TpSqItPd22Q3rP7gagXbJBn8U34
    lKjQHy8KhJeEh8NZ4bQ6BR7My3iHFigOcA3sbN+vDnsptz+TII hKfF2R1vvEOjcd
    2YICuxiio7hHN/VkmJP++OazuWIUr5lDQuJIOwszfI0ozwalRQ9X/Q==
    =41ma
    -----END PGP SIGNATURE-----

  3. #3
    Peter Hagstrøm
    Possible bug in PHPNuke and other CMS
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: Possible bug in PHPNuke and other CMS

    <snip>
    > <?php
    > require_once ("/location_of_victim's_PHPNuke/mainfile.php");
    > $sql = $db->sql_query("SELECT aid,pwd FROM ".$prefix."_authors");
    > while($record = $db->sql_fetchrow($sql))
    > ~ echo "Username: $record[aid]\n<br>\nPassword: $record[pwd]\n<br><br>\n";
    > unset($sql);
    > ?>
    >
    > Queries are executed normally because config.php (which is included by
    > mainfile.php) provides the information in order to connect to the chosen
    > database. This is a very easy way to deface PHPNuke-based websites or
    > adding and removing users, and so on.
    >
    > This "homemade patch" goes in config.php, just below connection
    > variables. It checks domain name provided by web server with the one
    > provided by the user and grants execution of SQL queries only if domain
    > names match. Here is the code:
    >
    > $domainname = "www.example.com";
    > if ($_SERVER['SERVER_NAME'] != $domainname ) {
    > ~ echo "Access denied";
    > ~ die();
    > }
    >
    > This vulnerability isn't only for PHPNuke, but also for every CMS that
    > doesn't check domain names.
    >
    > Greetings,
    >
    > Luca Falavigna


    Actually this "vulnerability" exist for all server side code. You could
    even step up one level and have the php code printed out, getting the
    passwords/usernames for the passwords in plain text for a more direct
    usage. Two points I would like to make:

    1. I would not call this a vulnerability. If you CAN do this for a
    system, I would call it a configuration problem. PHP should be limited
    to only accept allowed include directories by use of the include_path
    option. This can be setup on a virtual domain basis, and thereby
    preventing any other virtual domains from doing any such evil.

    2. Even if this was a bug, the fix you propose would not really work. In
    your code, you could simply add a $_SESSION['SERVER_NAME'] =
    "some_other_domain_name"; prior to the include statement, and the code
    would be still be fooled.

    However, this is a point that website admins should be attentive to when
    setting up multiple domain servers.

    /Peter Hagstrøm




Webhostingtalk.nl

Contact

  • Rokin 113-115
  • 1012 KP, Amsterdam
  • Nederland
  • Contact
© Copyright 2001-2026 Webhostingtalk.nl.
Web Statistics