Successful defacement attack dissected

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

One of the sites I support (though definitely not very actively, unfortunately) was successfully defaced recently - getting by both admin authentication and NukeSentinel. I won't give the attacker the pleasure of naming names or other script kiddies the details to try again, but I will explain how and why the attack was successful, how to prevent future attacks, and how to prevent successful attackers from bragging - or at least confusing those who wish to see the evidence.

Why me?

This site was selected using special search terms to identify sites with possible vulnerabilities. An HTTP referer from the site's access log:

Code:

http://search.yahoo.com/search?p=Copyright+%C2%A9+2003+by+PHP-Nuke&toggle=1&cop=mss&ei=UTF-8&xargs=0&pstart=1&fr=yfp-t-501

This kid was probably picking the sites one by one off the list.

Can I stop them from finding me?

Not completely, but there are some things you can do to make it harder. In this case, changing the copyright notice in the nuke_config table and changing the META Generator tag to use less specific references to PHP-Nuke helps. Later versions of Nuke removed the version number from the Generator tag, but that doesn't really stop them. They often search using familiar "modules.php?name=" terms, but you could stop that by using TegoNuke(tm) ShortLinks or a similar URL rewriting scheme. Of course, the author claims you can't change the META Generator tag or the copyright notice in the nuke_config table. But the GPL license says you can't remove the copyrights from the source code. Period. Otherwise, PHP-Nuke would have to retain references to Thatware (and other included addons, most recently the installer from Joomla) in it's visible copyrights. But, as I mentioned, this doesn't stop them - it just makes it a little trickier to find you. Dedicated (or bored) attackers will find you one way or another, so it's best not to use this as your primary defense.

How did they attack?

When I was 12, I attempted to carve the body of a race car from wood for my Cub Scout pack's Pinewood Derby race (I won first place for design but didn't fare too well in the race - that's another story). Our leader told us to follow two rules: always carve away from yourself and if the blade gets stuck, don't jerk it. Not one to follow directions, I broke both rules and nearly cut off my index finger.

It seems I'm not too good at following the rules for PHP-Nuke security, either. Of course, most PHP-Nuke webmasters know PHP-Nuke security rule 1: Use NukeSentinel to protect your site.

We did, but we broke Raven's Corollary on using NukeSentinel: Always use the latest version. We were several versions back (as I said, it's a site I rarely support). This allowed the attacker to use a uni0n attack that an older version of NukeSentinel didn't catch - and he was able to get the admin user names and encrypted passwords.

We even followed PHP-Nuke security rule 2: Use admin authentication on admin.php and the /Forums/admin directory.

But we didn't follow PHP-Nuke security rule 3: Your admin authentication user and password must be different from your website password.

Obviously, you can prevent most attacks by following the rules - ALL of them, and by keeping your NukeSentinel software current. We didn't, and in less than 5 minutes (the logs don't lie), the attacker had changed the site message.

What happened next?

Well, the attacker had to brag, of course! Within 6 minutes after completing the attack, he posted the results of his attack on a website popular with Turkish script kiddies. The referer (again, the logs don't lie) was something like: http://www.zone-h.org/component/option,com_attacks. Basically, the attacker posts the URL documenting his attack, and it gets reviewed by site administrators. Interestingly enough, zone-h.org uses Joomla and created custom components for tracking attacks. Fortunately, our older version of NukeSentinel blocked the tool they use to verify the attack as a harvester, so the attack was placed on DEFACEMENT HOLD status. In short, zone-h.org wasn't able to verify the attack using it's tools. Since I corrected everything and restored the site before it could be manually verified, the attacker wasted his time (ha, ha!).

What else can you do to tweak the attackers?

Most attacks are performed by script kiddies using well-known attacks without much creativity. I must give credit to the attacker for defeating an admittedly weak admin authentication defense. But I also set up a nice little surprise for those who wish to view sites that have been defaced, designed to waste their time for wanting to guilty pleasure of seeing my defaced site. How? A little .htaccess magic I found (add this to the top of your .htaccess):

Code:

RewriteEngine on


SetEnvIfNoCase Referer "^http://([a-z0-9\-]+\.)?zone-h\.org.*$" banned


SetEnvIfNoCase Referer "^http://([a-z0-9\-]+\.)?warez-turk\.com.*$" banned


# You can copy the previous lines and change the domains for all the sites you wish to ban...





# Nice trick.. => 301-Redirect to themself...


RewriteCond %{ENV:banned} ^1$


RewriteCond %{HTTP_REFERER} ^(.*)$


RewriteRule ^(.*)$ %1 [R=301,L]

This causes links to your site from the banned site to return to the same page where they clicked a link to your site.

Recap

Follow the rules of PHP-Nuke security, and you'll spend less time recovering from attacks:
1. Use NukeSentinel to protect your site.
1b. (Raven's Corollary) Always use the latest version and keep it current.
2. Use admin authentication on admin.php and the /Forums/admin directory.
3. Your admin authentication user and password must be different from your website password.

I'm sure you can add your own suggestions - feel free to do so below...

registered · Posted: Tue Oct 24, 2006 9:49 pm

Yes I've seen that search too. Requiring the copyright code seems to increase the security concerns these days. Maybe we need to campaign against it, making sure people know about it?

It seems these days, they use a robot to search through Google for sites and exploit automatically. Joomla, Mambo, phpBB, .. every script is being exploited. There is a recent thread to stop "libwww-perl" which I suggest everyone apply