I don't like to claim for the authory of bugs, because It is not
possible to clarify who discovered/exploited first some bug because
some times we are too lazy to publish them for any reason. But this
is an special reason because the person that claims for the authory
of the TWO "PhpNuke SQL Injection" has discovered them at the same
time than me and exploits them _exactly_ the same way than me so I
think that it can not be a coincidence.
I've been testing the methods of explotation this last week and it
is possible that "David Zenter" (the person who write that advisory)
found that kind of attacks , programmed an exploit for them and
finally he wrote the advisory stealing the authory of this 2 bugs
I am not sure of that so I would like him to answer.
I discovered the $user bug one month ago ( In fact I searched the
website and I found that RFP found them some years ago , but he
didn't publish a succesfull way to exploit them).
I contacted Francisco Bucci ,the author of PhpNuke and I suggested
some patches to him ( and he published the patches in his website)
but phpnuke had still a lot of bugs so I waited to finish my job to
publish them.
PhpNuke has been here for a lot of time so I dont't believe that a
person finds the same _TWO_ bugs than me and exploits them in te
same way so I want "David Zenter" to clarify that.
I am developing another vulnerabilities , what is very strange for
me is that the 2 ones that I've developed are the ones that
"David Zenter" published.
Now I attach the two advisories and the two exploits that I had
written for these bugs judge for yourself if you thing that this
can be a coincidence.
PD.- Excuse my poor english :)
;==================================================================
PHPNUKE is_user || is_admin VULNERABILITY
;==================================================================
General Data :
--------------
Aplicacion : PhpNuke.
Versions : <= 6.5 ( withouth the patch).
Vulnerability : Sql injection in the cookies user y admin.
: Access to the application at administration level
OR guess any user password.
Introduccion:
-------------
PhpNuke is a well known content management system programed
in PHP by Francisco Bucci, a lot of people use it because it is very
easy to install and manage.
PhpNuke doesn't chech the integrity of the cookies "user" and
"admin" that it uses to follow sessions, so it is posible to inject SQL
code and get de administration password.These coockies are encoded
using base64 so the "magic quotes" protection of PHP is not working.
Vulnerability:
--------------
The Vulnerable function is found in the file "mainfile.php" :
-------------------------------------------------------------------------------
function is_user($user) {
global $prefix;
if(!is_array($user)) {
$user = base64_decode($user);
$user = explode(":", $user);
$uid = "$user[0]";
$pwd = "$user[2]";
} else {
$uid = "$user[0]";
$pwd = "$user[2]";
}
$result=mysql_query("select pass from $prefix"._users."
where uid='$uid'");
list($pass)=mysql_fetch_row($result);
if($pass == $pwd && $pass != "") {
return 1;
} return 0;
}
-------------------------------------------------------------------------------
The function is_admin is almost like the other one.
There is no other integrity check to the cookie $user in the phpnuke
code so it is posible to inject SQL code in this way :
$user = base64_encode("uiduser' CODIGOSQL:noimporant:passowrd");
Most PhpNuke websites uses mysql 3.x so it is not posible to use UNION
so initialy it seams dificult to exploit.
Way to exploit:
---------------
To get information from that query we need a valid PhpNuke user, but
that is very easy because PhpNuke lets anybody create a user easily. Once we
have a valid userid and a valid password we can send a query like:
SELECT pass from nuke_users where uid='<target_uid>'
AND pass LIKE '<test>' OR uid='<our_uid>'
This SELECT will give the password of "target_uid" if <test> is
correct or our password if that test is not correct. So we can retrieve
information from that query if we see if we are logged or not. This allows us
to bruteforce the target password with LIKE's ( we only check one character
at the same time )
PhpNuke uses md5 in version 6.x ( crypt in versions 5.x ) that gives
an average of 32*(16/2) = 256 tries to get a valid password.
I have tested this method and it is posible to get a valid password
within 10 minutes.
Example of a cookie using this method:
user = base64_encode("2' AND pass LIKE
'a12bc___________________________' OR
uid='5612:noimportant:1234567889012345678901234567890ab");
Where '_' in LIKE's means any character.
Using that method we can find the cookie of _any_ user in phpnuke, in phpnuke
5.x (I think) that is not possible to go further but in phpnuke 6.x we can
use the fact that the admin password is stored in nuke_authors and in
nuke_users.
In the test that I've done , the uid=2 in nuke_users is the uid=1=admin in
nuke_authors.
Patches:
--------
There is a patch for this vulnerability in PhpNuke's website but I
must say that PhpNuke's seams to have some other vulnerabilites not yet
published.
Credit:
--------
I found this vulnerability one month ago , I dind't believe that this
vulnerability could be in PhpNuke!! , because it is very used and a lot of
people had already audited it before me , so I searched in google to find
that vulnerability I found that RFP had discovered that some years ago , in
PhpNuke 4.x !!! WooW , and it is still in PhpNuke!! :? RFP didn't find a way
to exploit that , but he discovered this vuln.
;==================================================================
PHPNUKE Search vulnerability
;==================================================================
General data :
--------------
Aplicacion : PhpNuke.
Versions : <= 6.5 ( withouth the patch).
Vulnerability : Sql injection in the search form.
: Access to the application at administration level
OR guess any user password.
Introduction:
---------
PhpNuke is a well known content management system programed
in PHP by Francisco Bucci, a lot of people use it because it is very
easy to install and manage.
PhpNuke doesn't check the parameter "category" in the search form
to be numeric, and when it builds the SQL query it does not enclose it
with quotes , so it is easy to inject SQL code, quotes will not be allowed
in this code because the "magic quotes" protection of phpnuke would add
slashes to them
Vulnerabilitu:
---------------
The vulnerable code is in modules/Search/index.php in PhpNuke 6.x
and in /search.php in PhpNuke 5.x
-------------------------------------------------------------------------------
if ($category > 0) {
$categ = "AND catid=$category ";
} elseif ($category == 0) {
$categ = "";
}
$q = "select s.sid, s.aid, s.informant, s.title, s.time, s.hometext,
s.bodytext,
a.url, s.comments, s.topic from ".$prefix. "_stories s,
".$prefix."_authors
a where s.aid=a.aid $queryalang $categ";
-------------------------------------------------------------------------------
This query is done using the nuke_authors table , ( with de variable
'a' ). so it is posible to get the admin password using a tecnique similar to
the last advisory.
Explotation Method:
-------------------
As I said in the last advisory PhpNuke mainly uses MySQL 3.x so it is
not posible to use UNION's tot get the admin password ( in this case it would
be possible to get the admin password string directly with unions )
But we can use a similar tecnique to the last advisory but withouth
using quotes , if we inject :
AND MID(a.pwd,characternumber,1) = CHAR( characterascii)
If characterascii is valid the query will give us the search result
otherwise it won't give us anything.This allows us to bruteforce the
administration password, wich can be done with less than 10 minutes.
Other parameters can be retrieved using this tecnique:
* a.uname : needed to log in phpnuke using the admin cookie.
* user() : mysql user , if it is root we can use some
tecniques like creating a file etc ...
* database()
* useyouimagination ...
Patches:
--------
As far as I am concerned there is not an official patch , but a
workarround is very easy , you just have to enquote the 'category' parameter
and test that it is a numeric field.
Credit:
--------
I don't know anybody who has already discovered that If you feel that
I am not correct please contact with me.
Vulnerability developed by : Oriol Carreras - <uriat_private>
--
>===============================
>
> http://ripe.7a69ezine.org
>===============================
This archive was generated by hypermail 2b30 : Fri Feb 21 2003 - 15:01:34 PST