YOU ARE SLAPPED BY?

New Member Joined: Sep 15, 2003 Posts: 3

I don't know how it came about, but would like to thank the top 3 nuke brains for getting together, Bob, chatserv, and raven. And not taking away from the other people here helping to support Sentinel, you all have my utmost respect. The only problem with this is I have been in this business for 30+ years and ya'll are giving me a complex!

To the problem:

Installed Sentinel 2.0.0 with no problems, except it wouldn't ban me when I tried this:
[ Only registered users can see links on this board! Get registered or login! ] UNI0N select counter, aid, pwd from nuke_authors

I got this in return:
YOU ARE SLAPPED BY NUKECOPS BY USING 'UNI0N' INSIDE 'name=web_links&l_op=viewlink&cid=2%20UNI0N%20select%20counter,%20aid,%20pwd%20from%20nuke_authors'.

And not banned.

Before going any further I upgraded to 2.0.1 and tried the same thing with same results.

This is on a 7.3_2.5 fresh install. The only difference I have is running Approve Membership 5.0_7.3 Which in turn has a somewhat different Your Account index.php I did find the 4 places to change the code but they were not the same as the original YA index.php In either case I get the same response as above. YOU ARE SLAPPED...

Question?

1. What did I mess up?

2. Would it be possible to connect up to the .htaccess file if I put it in the root of the server so that all domains can run Sentinel and feed a "super" .htaccess file that would benifit all, or am I going to get into trouble with 666 chmod.

I also ran this:

<?
echo php_sapi_name();
?>

result: apache2filter

Now please put your heads together and feed my inferiority complex so that I can run my nuke sites without getting whacked all the time.

Thanks,
whitestar

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

You either have fortress installed or some kind of an nc script. Uninstall it. You don't need it with Sentinel. Also, upgrade to Seninel v2.0.1

Posted: Sun Aug 08, 2004 11:13 am

Thanks for the quick response raven.

7.3 and 2.5 came from nukefixes, not quite sure how it would have an nc script in it. Can you give me a hint of where to find the script or a different clean download?

Fortress is not installed and have 2.0.1 installed already.

Thanks,
whitestar

Posted: Sun Aug 08, 2004 12:53 pm

Look in mainfile.php for the 'you are slapped' thingy. Make sure that the inlcude("includes/sentinel.php"); is the next line after the opening <? in mainfile.php. Check also Web_Links/index.php.

Insane Joined: Jul 30, 2004 Posts: 85

Union Tap.

The code is located at the top of mainfile.php, if you get rid of it, Sentinal will probably keep your site protected from that exploit. Wink

Posted: Sun Aug 08, 2004 10:18 pm

As rage mentioned the code is in mainfile.php:

Code:

//Union Tap


//Copyright Zhen-Xjell 2004 http://nukecops.com


//Beta 3 Code to prevent UNION SQL Injections


unset($matches);


unset($loc);


if (preg_match("/([OdWo5NIbpuU4V2iJT0n]{5}) /", rawurldecode($loc=$_SERVER["QUERY_STRING"]), $matches)) {


   die("YOU ARE SLAPPED BY <a href=\"http://nukecops.com\">NUKECOPS</a> BY USING '$matches[1]' INSIDE '$loc'.");


}

The same code exists in 7.4 but was modified a bit, the "slap" was replaced with die();

Posted: Mon Aug 09, 2004 4:14 pm

Here' the long and short of this

Quote:

2. Would it be possible to connect up to the .htaccess file if I put it in the root of the server so that all domains can run Sentinel and feed a "super" .htaccess file that would benifit all, or am I going to get into trouble with 666 chmod.

As long as your sub-domains/addon domains reside within the main sites directory structure it will in theory work. The only thing I can think off that might cause you an issue is if the sub-domains/addon domains can access the .htaccess file in the directory above them. In most cases a sub-domain considers it's self as the top level directory so instead of entering .htaccess as the location you would need to use /path/to/your/.htaccess in each sub/addon domains admin panel.

On the 666 question, here again as long as all the sub/addon domains reside within the main sites directory structure it should work without needing to 777 the .htaccess file. I would NOT chmod my .htaccess to 777.

I am going to do some testing on my local server and my live server to see if the theory factor is a true factor and let you know in a day or two.

Posted: Mon Aug 09, 2004 5:08 pm

Okay, had a little time to play around today and here's what I found on your question:

On my test server I have a site called [ Only registered users can see links on this board! Get registered or login! ] with sub-domains or 700.tester.xxx, 710.tester.xxx, 720.tester.xxx, 730.tester.xxx, & 740.tester.xxx . The path to the main site is /home/tester/public_html . The paths to the subs are /home/tester/public_html/### <- put in sub number.

Now in each sub-domain I put a htaccess path of /home/tester/public_html/.htaccess and then set each sub up to trigger on attack. I attacked each site with a similar attack. After each sub attack I checked the main sites .htaccess file and it did write to it. So until I clear my ip out of the main sites .htaccess file I could no longer access any of the sites that reside within the main sites directory structure.

Long story short, the test was a success and locked me out of everything ###.tester.xxx !

Did the same test on my live server with the exact same results.

Posted: Mon Aug 09, 2004 5:10 pm

An after thought. Both my local and live servers are *nix/Apache servers. On a Windows/Apache server the path would be like D:\path\to\your\.htaccess .

Posted: Mon Aug 09, 2004 6:49 pm

Useful information I'm going to give this a try.

Posted: Mon Aug 09, 2004 6:57 pm

Rage wrote:

Union Tap.

The code is located at the top of mainfile.php, if you get rid of it, Sentinal will probably keep your site protected from that exploit. Wink

PROBABLY?

I am tempted to ban insane people from now on Evil or Very Mad

Posted: Mon Aug 09, 2004 6:59 pm

Please don't, i have friends here, would suxx to be banned.

Posted: Mon Aug 09, 2004 7:14 pm

lmao @ Raven!

I did some testing on this shared htaccess and find this:
I have an addon domain [ Only registered users can see links on this board! Get registered or login! ] under [ Only registered users can see links on this board! Get registered or login! ] running phpnuke on a subdomain [ Only registered users can see links on this board! Get registered or login! ] of another domain. Follow?

I set Sentinel to write to the htaccess in the top level domain. It did. Now attacks on the nuke site are only banned from sentinel because the htaccess ban does not propagate into the addon domain or into subdomains on the primary domain such as [ Only registered users can see links on this board! Get registered or login! ] which is a subdomain of [ Only registered users can see links on this board! Get registered or login! ]

Very interesting gives me a greater understanding of the limits and lack of limits while running under the shared server.

Posted: Mon Aug 09, 2004 7:39 pm

Six,

10 to 1 odds the [ Only registered users can see links on this board! Get registered or login! ] is not in the lower directory under webtree.org but is a symlink to a directory elsewhere on the server which would naturally mean the main htaccess wouldn't have any sort of control over it. That little tidal (~) generally means a symlink is what I'm basing this on. Raven can correct me if I am mistaken.

Posted: Mon Aug 09, 2004 8:23 pm

The tilde is a fake actually lol at one time that was on a server where that was true so when I moved the site I kept it that same so the people using that url could still find it instead of pratt.webtree.org

Hangin' Around Joined: Jun 05, 2004 Posts: 41

Quote:

am tempted to ban insane people from now on

Ok you could just ask me to leave Wave

Posted: Tue Aug 10, 2004 9:53 am

No fun in that. I'd rather make you stay and face abuse ROTFL

Posted: Wed Aug 11, 2004 3:18 am

Here's an update:

I uninstalled and installed 2.0.1 several times including the full database. No luck.

Downloaded 7.4 w/2.5 from here and reinstalled the whole site again. That made it somewhat better, tested and got to the good old blank page this time, but still not banned. Went to YA and replaced this:

Quote:

cookiedecode($user);
getusrinfo($user);
if ((is_user($user)) AND (strtolower($userinfo['username']) == strtolower($cookie[1])) AND ($userinfo['user_password'] == $cookie[2])) {

with this:

Quote:

cookiedecode($user);
getusrinfo($user);
if ((is_user($user)) AND ($userinfo[username] == $cookie[1]) AND ($userinfo[user_password] == $cookie[2])) {

Still the blank page when testing. Question: Should this go back to original?

It seems that somehow it just didn't know where to go when being hacked, so I enabled Force Nuke URL and it banned me to both .htaccess and database. But with the following errors:

Quote:

Warning: REG_BADRPT in /home/httpd/vhosts/xxxxx.com/httpdocs/includes/sentinel.php on line 69

Warning: Cannot add header information - headers already sent by (output started at /home/httpd/vhosts/xxxxx.com/httpdocs/includes/sentinel.php:69) in /home/httpd/vhosts/xxxxx.com/httpdocs/includes/sentinel.php on line 71

The referenced code is:

Quote:

// Force to NUKEURL
if($ab_config['force_nukeurl'] == 1) {
$servtemp1 = strtolower(eregi_replace("http://", "", $nuke_config['nukeurl']));
if(substr($servtemp1, -1) == "/") { $servtemp1 = substr($servtemp1, 0, strlen($servtemp1)-1); }
$servrqst1 = strtolower($_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI']);
$servrqst1 = str_replace("/".basename($servrqst1), "", $servrqst1);
if(substr($servrqst1, -1) == "/") { $servrqst1 = substr($servrqst1, 0, strlen($servrqst1)-1); }
if ($servrqst1 != $servtemp1 AND !stristr($_SERVER['REQUEST_URI'], "modules/Forums/admin/")) {
$rphp1 = $_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI'];
$rphp2 = eregi_replace($servrqst1, $servtemp1, $rphp1);
$rphp2 = "http://".$rphp2;
Header("Location: $rphp2");
}

And finally to add to the discussion about .htaccess for all domains (if you consider this a security breach delete it quick) A couple of excellent points from my nephew:

Anyway, I was thinking of the downsides of banning IPs at the drop of a hat
and thought I'd throw this out to you. This isn't to say it's a bad idea,
just shows some ways a crafty hacker can turn it against you.

Once they realize that you are banning IPs on the fly, they can then start
sending requests with spoofed IPs to cause a denial of service. If they
send too many, you'll notice right away, but if they're sneaky you might be
banning lots of people without realizing. And as soon as they start using
spoofed IPs, it'll be hard to find out who is really sending the requests.
On the positive side, they won't get any results from their requests (since
the webserver doesn't know how to get the data back to them) so they can't
do too much other than cause trouble by getting certain IPs banned. For
example, they could start sending requests that look like they are from the
AOL proxies. If we ban one of those proxies we are banning thousands of AOL
users. And if you put the AOL proxies on the "don't ban" list, then they
can hack away all they want from an AOL account (not good).

Also, I wonder if any of those guys have thought about using iptables to
ignore any packets from trouble makers. The .htaccess thing will protect
the website, but having iptables drop all packets from that IP will protect
the server itself from SSH, FTP, or any other service attacks. Has the same
downsides of IP spoofing, but if you don't want these people on your
website, you probably don't want them on your server in any way.

Sorry this took so long but those 7 puppies are about to drive me insane when I try to work on this computer!

whitestar

Posted: Wed Aug 11, 2004 10:35 pm

Let's start with the line 69 from includes/sentinel.php . I forgot to make an exception for the abuse directory so we need to change:

Code:

 if ($servrqst1 != $servtemp1 AND !stristr($_SERVER['REQUEST_URI'], "modules/Forums/admin/")) {

To:

Code:

 if ($servrqst1 != $servtemp1 AND (!stristr($_SERVER['REQUEST_URI'], "modules/Forums/admin/") AND !stristr($_SERVER['REQUEST_URI'], "abuse/"))) {

On the other I'll get a copy of Raven 7.4/2.5 package since it may be slightly different from my 7.4/2.5 package and see what if anything turns up.