[NewAngels Advisory #7]PHP Nuke <= 7.8 Multiple SQL Injections

So there is this advisory which is released:



[NewAngels Advisory #7]PHP Nuke <= 7.8 Multiple SQL Injections
========================================================================
=====

Software: PHP Nuke 7.8
Type: SQL Injections
Risk: High

Date: Sep. 10 2005
Vendor: PHP-Nuke (phpnuke.org)

Credit:
=======
Robin ‘onkel_fisch’ Verton from it-security23.net

Description:
============
PHP-Nuke is a news automated system specially designed to be used in Intranets and Internet.
The Administrator has total control of his web site, registered users, and he will have in the hand
a powerful assembly of tools to maintain an active and 100% interactive web site using databases.
[http://www.phpnuke.org/]

Vulnerability:
==============

PHP Nuke 7.8 is prone to multiple SQL injection vulnerabilities.
These issues are due to a failure in the application to properly sanitize user-supplied input before using it in SQL queries.

In the modules.php

$result = $db->sql_query(“SELECT active, view FROM “.$prefix.”_modules WHERE title=’$name'”);

The $name variable is not checked so you could inject malicious SQL Code. In an file which is included whe have the following code:

$queryString = strtolower($_SERVER[‘QUERY_STRING’]);
if (stripos_clone($queryString,’%20union%20′) OR stripos_clone($queryString,’/*’) OR stripos_clone($queryString,’*/union/*’) OR stripos_clone($queryString,’c2nyaxb0′)) {
header(“Location: index.php”);
die();
}

[…]

if (!ini_get(“register_globals”)) {
import_request_variables(‘GPC’);
}

So you can use UNION in a GET var. But because they use register_globals or impor_request_variables you can send
the malicous SQL-Code via POST so it is not checked if you insert an “union”.

http://www.example.com/modules.php POST: name=’ OR 1=1/*
will produce an error, neither
http://www.example.com/modules.php POST: name=’ OR 1=2/*
will only tell you taht the requestet ‘modul’ is not active, so you can read out the admin password hahs via blind injections.

Additionaly there are a few SQL-Injections in the modules.
Here a few examples:

http://www.example.com/modules.php?name=News&file=article&sid=[SQL] – here the same as above, send this via POST to
bypass the ‘union’-cover

http://www.example.com/modules.php?name=News&file=comments&Reply&pid=[SQ
L]

http://www.example.com/modules.php?name=News&file=comments&op=Reply&pid=
[SQL]

http://www.example.com/modules.php?name=News&file=comments&op=Reply&sid=
[SQL]

Greets:
==============
CyberDead, atomic, sirius_
Whole secured-pussy.de Team
Zealots 😀 😀


Of course I’m not thrilled so I just had to reply:



The $name variable and others like $sid are expected via $_GET and not
$_POST.  The proper start to sanitizing the data here is to ensure that
$name is obtained via $_GET and not injected by $_POST, $_COOKIE, or
anything else.


Since you did two things I’m avidly against:


1) no vendor contact information
2) no suggested patches


I wanted to reply and alert folks who run PHP-Nuke and its forks since
after running a cursory search on some popular PHP-Nuke sites I saw
nothing about this:


http://en.wikipedia.org/wiki/Php-nuke


About the above suggestion.


To be specific, find the modules.php file and check for the first instance
of “$name”.  An example:


if (isset($name)) {


Prior to that, simply put in such a line:


$name = $_GET[‘name’];


You’re forcing the $name variable to be set by the HTTP GET request,
rather than inject a value by a cookie or post ($_COOKIE, $_POST
respectively).

The same applies to the rest of the code for other variables.

4 thoughts on “[NewAngels Advisory #7]PHP Nuke <= 7.8 Multiple SQL Injections”

Leave a Reply

Your email address will not be published. Required fields are marked *