Newest Forum User Injection?

New Member Joined: May 13, 2006 Posts: 6

Last night I went to check on my website and browse around forums when I noticed Sentinel pl9 had blocked another hack attempt..it was a Filter attack but when I checked the query in Blocked Ip's it showed where they tried to gain access through admin_users.php in Forum admin..so what i'm wondering is if this is the new critical update that yall are working on to be fixed...and could i actually rename my admin_users.php for the time being to help protect against this until a perm fix is set in sentinel..or is it even anything to worry about since they did get blocked?..currently right now I have my forums module folder completely renamed and disabled so i'm just kind of curious the best way to possibly go about it.

Posted: Sun Jun 11, 2006 12:48 pm

looks like sentinel is already set to block them

Posted: Sun Jun 11, 2006 2:39 pm

If you turn things off at the sign of an attack you will not have much active any time soon. And the hackers will have won. As long as their attacks are being blocked I'd leave things running. Renaming the file really doesn't accomplish much, Sentinel already provides good protection for admin file hacks. In addition if you have http_auth or cgi_auth running you have a whole extra layer of protection against admin attacks.

I believe it's fair to say that the biggest threat we've seen in the recent attacks is that the hackers find some "back door" way to get a script file onto your server and then use that to exploit it. Renaming files provides no protection against that. Nor really does Sentinel if they come in by a non-browser means.

Best advice, keep up with Sentinel and check your logs frequently and enjoy your system. edit and oh yeah, have a good backup available because nothing is perfect.

Posted: Sun Jun 11, 2006 3:35 pm

There is some more you can do if you like that:

http://www.ravenphpscripts.com/postt9904.html

registered · Posted: Sun Jun 11, 2006 9:33 pm

Yep, that is what the boys were working on and I implemented Raven's "quick fix" another way, but the same result. Just an extra layer of protection. There may be other variables which need to be "inspected" by NukeSentinel as well as what has already been caught, so having the extra protection on the forum admin directory is a good thing for now.

Posted: Tue Jun 13, 2006 8:45 pm

Ok, thanks for all the replys..also i was checking out the blocked string and checked a link that was included in the blocked screen..when I went to the link my antivirus went off detecting a PHP Backdoor Trojan..I dunno if it would be of any use to any of the staff but let me know if interested.

registered · Posted: Wed Jun 14, 2006 12:16 pm

Best fix is to put
$phpbb_root_path = './../';
After the include for the mainfile in the modules/Forums/admin/pagestart.php

registered · Site Admin Joined: Jun 04, 2004 Posts: 6437

That sounds perfect, technocrat. Was that the recommended change by phpBB?

Posted: Wed Jun 14, 2006 2:37 pm

Ah, no because its not a phpbb problem but a nuke problem. Here is what happens in a nut shell. You go to an admin file, say modules/Forums/admin/index.php
The first thing it does is include modules/Forums/admin/pagestart.php which is where phpbb_root_path gets set for many of the admin files. So it is at the point $phpbb_root_path = './../';

Now if Bruzi did not allow the use of registered globals everything would be fine, but we know that is not the case. So the next line is to include the mainfile.php, which in turn overwrites all the previously set variables with globals, if they exsist. Sad

So now if you url has phpbb_root_path=http://whatever then that is what gets set in the pagestart.php. This would mean $phpbb_root_path is no longer = './../'; but rather $phpbb_root_path = 'http://whatever'; Now your introuble, because after that is an include call which uses the $phpbb_root_path.

As always, its was poor coding on nuke's part. And a mistake on PHP parts for allowing globals to do that. Which will no longer be there in PHP v6. Wink

Posted: Wed Jun 14, 2006 2:50 pm

Makes perfect sense. I understood what the problem was, but your clear explanation is sure you help many. Thank you!

Site Admin/Owner Joined: Aug 27, 2002 Posts: 17088

I run my servers with register_globals OFF and the method of attack still worked. I don't think that's a factor.

Posted: Wed Jun 14, 2006 4:03 pm

There is also talk of their being a bug in certin PHP versions that allowed for globals to overwrite even if off. I can't find the post now that talked about it. Mad

It has to be globals because the attack only works after the mainfile is included and with the shell url in the GET. So that has to be what's going down because phpbb_root_path is no where in the mainfile nor in any included files inside most nuke installs.

Easy enough to prove, var_dump $phpbb_root_path before mainfile and after in pagestart then try the exploit.