Support

Bullseye! That's the kind of real life threat I designed ATP to block.

On the compromised site: most likely the attacker managed to gain elevated privileges or used a rogue file uploader vulnerability to upload test.txt. If the site owner had used ATP, he'd have prevented that in many ways:
- Rogue uploads are impossible, thanks to UploadShield (it would've blocked a file containing PHP code from being uploaded through Joomla!).
- Access to unprivileged directories (such as cache) is forbidden by .htaccess Maker's default rules
- Common SQLi / XSS attacks used to get elevated privileges get caught by SQLiShield and XSSShield, respectively
- In the unlikely case a non-Joomla! exploit was used, accessing the site's back-end would trigger an email to the site owner, notifying him that something is wrong.

On the target site, ATP helps mitigate the attack, as the RFIShield scans remote URLs. If PHP code is detected, the attack stops dead on its tracks. FYI, many months ago, I had left a known vulnerable version of a popular component on one of my sites for testing purposes. Sure enough, attackers tried to exploit it and were blocked straight away. That's how my proof of concept SQLiShield and RFIShield code graduated from proof of concept to release status. I thrive on dogfooding: I first try the software I develop on my sites, in vitro and in vivo, before releasing it to the public.

With ATP, it's almost always veni, vidi, vici :) The only attacks it can't prevent are those which target non-Joomla! scripts and that's why I've been bitching for over a year that any Joomla! software using rogue entry point PHP files should be banned and rewritten. The only valid case of using a non-Joomla! entry point is when updating the Joomla! core itself, i.e. what Admin Tools does with its Joomla! core updater.

That said, a big step to protecting your site against RFI attacks is disabling the URL fopen() wrappers. I generally consider this PHP feature a Bad Idea(tm). Nobody should need it, as long as cURL is available on the server.

Yes, it does help! Most people have never seen a real life attack. For them, hacking is something "magical". When you get to see how darn easy it is to get hacked, you begin to appreciate the way a solution works even more!

The gold star is awarded at 8,000 posts, he he! If someone reaches that number of posts, I will have certainly already hired him!

That would have already happened at around 150 posts, so you're very close to being awarded a free lifetime subscription, my friend ;)

For a very long time I'm thinking of creating a series of tutorials regarding how common exploits work and how to avoid them. The problem is that you can't demonstrate exploits without, at the same time, teaching people how to hack other people's sites. It's like having to shoot someone to explain what a bullet does to a gunshot victim :( So, I am stuck. I either have to present something generic, which won't shed any more light to what is going on during a hack, or risk of accidentally putting my black hat on.

OK, I think I will start writing this series after all. Follow me on Twitter @nikosdion or @akeebabackup and you'll know when the first articles will be ready :)

Thank you for your kind words!

This is yet another case of why backups taken by the host are never enough. I find it sad that not only the hosting company did not have off-site backups (which raises many questions on its own right as to the competence of many host out there) but also the response for some users. One guy said that he has lost years of work with his site. This means that he trusted all his work to be stored only on a single place and that he did not consider a backup for years! At this point I would like to remind everyone the Three Rules of Life, as pointed out by officer Martin Riggs in "Lethal Weapon":
1. Shit happens
2. Shit happens all the time
3. You'd better get used to the first two rules
That's exactly what's going on. Sites do crash. Sites do get hacked. You can never put your head in the sand and pretend this won't happen to you. On the contrary. However, if you become obsessed with regular, off-site backups and proactive security then the chances of that misfortune happening to you is greatly minimised.

Thank you for sharing this link!

Exactly so! I had one guy tell me yesterday that he prefered using cPanel's backup feature instead of Akeeba Backup because he "only needed to store the backups on the server and cPanel backup is fast". His site and his clients' sites. I guess that when one of those sites gets hacked or the hard drive fails on that server, he'll realise how wrong he was, most likely immediately following his abrupt career change... People never learn.