PHP Nuke <= 7.8 Multiple SQL Injections

[r.verton@gmail.com]

[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=[SQL]

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 :D :D

[evaders99@gmail.com]

I'd just like to report as a solution: the Nuke Patched files. These are being developed to cover all the latest vulnerabilities, and to fix issues with previous versions of phpNuke.

Current change log
http://www.nukefixes.com/ftopict-1779-.html#7641

These changes will be implemented to our CVS and package downloads soon.

Download at http://www.nukeresources.com

[Paul Laudanski]

On 12 Sep 2005 r.verton@gmail.com wrote:

> Software: PHP Nuke 7.8
> Type: SQL Injections
> Risk: High
>
> 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:
>
>
> 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=[SQL]
>
> 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]

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.

--
Paul Laudanski, Microsoft MVP Windows-Security
CastleCops(SM), http://castlecops.com


________ Information from Computer Cops, L.L.C. ________
This message was checked by NOD32 Antivirus System for Linux Mail Server.

part000.txt - is OK
http://castlecops.com

[Matthias Jim Knopf]

What do you gain from that? In what way would you think your advice did
ANYTHING GOOD?
You did neither issue a "addslashes()" as appropriate for SQL-commands,
nor did you explain, why a variable set by a POST or a COOKIE could be
worse than anything you could give any URL by appending '?name=...' or
'&name=...' (->GET vars)

Greetings, Matthias "jim" Knopf
--
GPG/PGP encrypted mails welcome!
Windose Milenium Bug

> > 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:
[...]
> 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.
[...]
> 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'];

[Paul Laudanski]

On 14 Sep 2005 evaders99@gmail.com wrote:

> I'd just like to report as a solution: the Nuke Patched files. These are being developed to cover all the latest vulnerabilities, and to fix issues with previous versions of phpNuke.
>
> These changes will be implemented to our CVS and package downloads soon.

The PHP-Nuke vendor @ http://phpnuke.org has already released a security
fix to this immediately. It is strongly advised to run the patch.

Read the vendor's disclosure:

http://phpnuke.org/modules.php?name=News&file=article&sid=7434

The patch is for all PHP-Nuke 7.8 and older.

--
Paul Laudanski, Microsoft MVP Windows-Security
CastleCops(SM), http://castlecops.com



________ Information from Computer Cops, L.L.C. ________
This message was checked by NOD32 Antivirus System for Linux Mail Server.

part000.txt - is OK
http://castlecops.com

[Paul Laudanski]

On Fri, 16 Sep 2005, Matthias Jim Knopf wrote:

> What do you gain from that? In what way would you think your advice did
> ANYTHING GOOD?
> You did neither issue a "addslashes()" as appropriate for SQL-commands,
> nor did you explain, why a variable set by a POST or a COOKIE could be
> worse than anything you could give any URL by appending '?name=...' or
> '&name=...' (->GET vars)
>

If you read the code and original advisory, there is filtering already in
place within the PHP-Nuke framework that monitors HTTP GETs. As such,
this 'exploit' makes of variables which should only be passed via HTTP
GETs and not POSTs nor cookies.

Proper data sanitization for this is simply to retrieve what is expected:

$name = $_GET['name'];

The function you specify like http://php.net/addslashes is neither here
nor there. Why use that function for a variable in POST or cookies when
it is clearly expected to be returned via GET alone?

Ergo:

register_globals off !

--
Paul Laudanski, Microsoft MVP Windows-Security
CastleCops(SM), http://castlecops.com



________ Information from Computer Cops, L.L.C. ________
This message was checked by NOD32 Antivirus System for Linux Mail Server.

part000.txt - is OK
http://castlecops.com

[Daniel Bonekeeper]

I made some tests and seems to me that just environments where
magic_quotes_gpc =3D 'Off' are affected (which is not default on php).
When magic_quotes_gpc =3D On, the query that is sent to database is
interpreted as:

SELECT active, view FROM nuke_modules WHERE title=3D'\' OR 1=3D2 /*'

Which is properly slashed. But, if we do have magic_quotes_gpc =3D Off,
it's interpreted as:

SELECT active, view FROM nuke_modules WHERE title=3D'' OR 1=3D2 /*'

Which is exploitable.=20


On 9/15/05, Paul Laudanski <zx@castlecops.com> wrote:
> On Fri, 16 Sep 2005, Matthias Jim Knopf wrote:
>=20
> > What do you gain from that? In what way would you think your advice did
> > ANYTHING GOOD?
> > You did neither issue a "addslashes()" as appropriate for SQL-commands,
> > nor did you explain, why a variable set by a POST or a COOKIE could be
> > worse than anything you could give any URL by appending '?name=3D...' o=
r
> > '&name=3D...' (->GET vars)
> >
>=20
> If you read the code and original advisory, there is filtering already in
> place within the PHP-Nuke framework that monitors HTTP GETs. As such,
> this 'exploit' makes of variables which should only be passed via HTTP
> GETs and not POSTs nor cookies.
>=20
> Proper data sanitization for this is simply to retrieve what is expected:
>=20
> $name =3D $_GET['name'];
>=20
> The function you specify like http://php.net/addslashes is neither here
> nor there. Why use that function for a variable in POST or cookies when
> it is clearly expected to be returned via GET alone?
>=20
> Ergo:
>=20
> register_globals off !
>=20
> --
> Paul Laudanski, Microsoft MVP Windows-Security
> CastleCops(SM), http://castlecops.com
>=20
>=20
>=20
> ________ Information from Computer Cops, L.L.C. ________
> This message was checked by NOD32 Antivirus System for Linux Mail Server.
>=20
> part000.txt - is OK
> http://castlecops.com
>=20


--=20
# (perl -e "while (1) { print "\x90"; }") | dd of=3D/dev/evil

[Paul Laudanski]

On Fri, 16 Sep 2005, Matthias Jim Knopf wrote:

> What do you gain from that? In what way would you think your advice did
> ANYTHING GOOD?
> You did neither issue a "addslashes()" as appropriate for SQL-commands,
> nor did you explain, why a variable set by a POST or a COOKIE could be
> worse than anything you could give any URL by appending '?name=...' or
> '&name=...' (->GET vars)

If you read the code and original advisory, there is filtering already in
place within the PHP-Nuke framework that monitors HTTP GETs. As such,
this 'exploit' makes use of variables which should only be passed via HTTP
GETs and not POSTs nor cookies.

Proper data sanitization for this is simply to retrieve what is expected:

$name = $_GET['name'];

The function you specify like http://php.net/addslashes is neither here
nor there. Why use that function for a variable in POST or cookies when
it is clearly expected to be returned via GET alone?

Ergo:

register_globals off !

If you desire to filter $_POST['name'] and/or $_COOKIE['name'] go for it.
I can tell you that those values are never to be expected in PHP-Nuke so
you are just adding extra overhead.

--
Paul Laudanski, Microsoft MVP Windows-Security
CastleCops(SM), http://castlecops.com



________ Information from Computer Cops, L.L.C. ________
This message was checked by NOD32 Antivirus System for Linux Mail Server.

part000.txt - is OK
http://castlecops.com

[hans]

On Fri, 16 Sep 2005, Matthias Jim Knopf wrote:


> What do you gain from that? In what way would you think your advice did
> ANYTHING GOOD?

Could you please stop topposting? I had to read the complete thread to
know what php*uke bug it was related to.

> You did neither issue a "addslashes()" as appropriate for SQL-commands,
> nor did you explain, why a variable set by a POST or a COOKIE could be
> worse than anything you could give any URL by appending '?name=...' or
> '&name=...' (->GET vars)

Adding slashes, using register_globals, it's all bad.

> > > These issues are due to a failure in the application to properly sanitize

'Sanitizing' input has always been a problem. Mandrake once supported
phpnuke and therefor I commited a 11K line diff to them a few years
back. That was to 'sanitize' only part of the problem, mostly some
descent behaviour against the used dblayer.

Let's stop whining about phppuke, and start using some user input
validation.

Hans

--
<iemand>
iemand heeft een gat gevonden in pdp's access.db? bel cnn

http://blacklist.kernelnewbies.nl