Ravens PHP Scripts: Forums
 

 

View next topic
View previous topic
Post new topic   Reply to topic    Ravens PHP Scripts And Web Hosting Forum Index -> Security - PHP Nuke
Author Message
ladysilver
Hangin' Around


Joined: May 03, 2004
Posts: 49
Location: Cyberspace

PostPosted: Mon May 03, 2004 1:00 pm Reply with quote

Is there a way to edit /db/mysql.php so as to not disclose an error path? I've been running sql injection and xss attacks against one of my test sites using PHP-Nuke 7.2 with chatserv's patches and hackattempt.php. Everything failed against the site except one attack, which I won't post here.

I decided to try djmaze's union/uni0n fix (http://nukecops.com/postt27474.html) and that stopped it, but I got an sql error message that exposed the server path. I would like to prevent that from displaying on a production site.

My test sites mimick my production sites; same hosts, versions of apache/php/mysql, directory structure, ect..., so it's not critical to me in debugging to have the error messages display on production sites.
 
View user's profile Send private message Visit poster's website ICQ Number
Raven
Site Admin/Owner


Joined: Aug 27, 2002
Posts: 17086

PostPosted: Mon May 03, 2004 1:13 pm Reply with quote

In almost all cases if you do something like this you can nullify all displayed MySQL messages
Code:
$result = @mysql_query($sql) or die();
Or, actually,
Code:
$result = @mysql_query($sql);
That should give you enough to go on. If not, get back to me as MySQL is one of my forte's. You could, of course, do a redirect to index.php or display a message like die('no way') or whatever. Also, would you please PM me the attack that got through?
 
View user's profile Send private message
ladysilver
PostPosted: Mon May 03, 2004 2:10 pm Reply with quote

Thank you! Very Happy I'll send you a PM on the exploit & info on my test site setup.
 
Raven
PostPosted: Mon May 03, 2004 3:53 pm Reply with quote

LS, I believe if you apply chatserv's 7.2 fixes (replace the modules/Private_Messages/index.php) that should stop it. I can't reproduce it Confused Do you need to be logged in or do you try that as a visitor?
 
ladysilver
PostPosted: Mon May 03, 2004 5:00 pm Reply with quote

I wasn't logged in at the time. I didn't try the exploit with my usual browser, I was using Windows IE 6, if it makes a difference. Thanks for checking so quickly, and letting me know your results. As I'm writing this, I downloaded index.php from the private messages folder on my test site and ran a comparison between it and chatserv's fixed version and then cross-compared both of those to a fresh copy from 7.2 original. I wanted to see if I screwed up somehow and didn't upload the right index.php. The one I'm using matches chatserv's fixed version except for my modifications.

The two modifications I have in privates messages index.php are adding new colours to the forum posts with additional 'L_COLOR' lines, and email the full text of private messages if a user chooses to be notified on new private messages arrives. For the last, after line 1398 I added these two lines.

Code:
SENDER_USERNAME' => $userdata['username'],

                                        'PM_MESSAGE' => str_replace("\'", "''", $privmsg_message),


Could that have affected it in any way?
 
Raven
PostPosted: Mon May 03, 2004 5:11 pm Reply with quote

The simplest way to find out is to rename yours and just use Chat's. Did it stop it or not?
 
ladysilver
PostPosted: Mon May 03, 2004 5:37 pm Reply with quote

No, I just upload the original 7.2 mysql.php and replaced my index.php in private messages with chatserv's. I cleared the browser cache, deleted cookies, and destroyed the session to be try to be sure I didn't have anything that could be tapped into to give a false positive on the exploit. I still got in. I'm going to take a look through everything that could have an effect on Private Messages to see if I can find how this is getting through on my test site. It has to be something in my files there, if it's not getting through on other sites.

Thanks again for the information on nullifying the sql messages. Here is how I implemented it in djmaze's fix.

Code:
$query = eregi_replace('UNION','UNI0N', $query); 

$this->query_result = @mysql_query($query, $this->db_connect_id) or die('Improper request.');


This hid the debug message and path disclosure.
 
Raven
PostPosted: Mon May 03, 2004 5:42 pm Reply with quote

The only problem with his method is that I (and many others) presently am writing real applications using UNION. It is much faster than the 1.3.x MySQL work arounds. The real issue is the passing of UNION in variables that shouldn't have them. That's what needs to be addressed. Cleansing input Wink
 
ladysilver
PostPosted: Mon May 03, 2004 5:55 pm Reply with quote

I try never to rest on temporary solutions. Wink I'll keep testing and looking for better mousetraps. I look forward to seeing what scripts you develop. Smile
 
Display posts from previous:       
Post new topic   Reply to topic    Ravens PHP Scripts And Web Hosting Forum Index -> Security - PHP Nuke

View next topic
View previous 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
You can attach files in this forum
You can download files in this forum


Powered by phpBB © 2001-2007 phpBB Group
All times are GMT - 6 Hours
 
Forums ©