Support

Akeeba Backup for Joomla!

#16201 malware found in joomla 2.5.11 +admintool

Posted in ‘Akeeba Backup for Joomla! 4 & 5’
This is a public ticket

Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.

Environment Information

Joomla! version
n/a
PHP version
n/a
Akeeba Backup version
n/a

Latest post by nicholas on Monday, 27 May 2013 06:04 CDT

user59496
Mandatory information about my setup:

Have I read the related troubleshooter articles above before posting (which pages?)? yes
Have I searched the tickets before posting? yes
Have I read the documentation before posting (which pages?)? yes
Joomla! version: (2.5.11)
PHP version: (5.3.21)
MySQL version: (5.1.68)
Host: (optional, but it helps us help you)
Akeeba Backup version: (unknown)

EXTREMELY IMPORTANT: Please attach a ZIP file containing your Akeeba Backup log file in order for us to help you with any backup or restoration issue. If the file is over 2Mb, please upload it on your server and post a link to it.

Description of my issue:

My joomla website has been detected by Google as malware. I have the most up-to-date joomla version , as well as all plugins, + admin tools. After checking my site i found eval(base64_decode in all of php files under libraries. also under components. How can this happen with admintools?

your quick response is appreciated,

nicholas
Akeeba Staff
Manager
Just because you have Admin Tools installed and a .htaccess file generated doesn't make your site unhackable. The first obvious reason is that no security tool can ever be watertight. All security tools, including Admin Tools, are designed to make it very much harder for someone to hack your site. Making it impossible, though? Not a chance. If there were such a magic solution we'd be selling it for several millions of dollars – just think about how much money big companies lose when their servers are penetrated.

Now, besides that, all security solutions protect you from hacks coming from the outside as long as the requests are routed through them. This has two very important corollaries:

1. It is possible that the attacker is able to execute an arbitrary PHP file or exploit a vulnerability in a directly web accessible .php file. The .htaccess Maker front-end and back-end protection block, by default, access to all .php files except Joomla!'s index.php files. However, you can add exceptions. If you add an exception which allows specific .php files to be accessed and they are vulnerable then you've opened a back door to your site. If you enable direct access to all files (including .php) for a articular directory it is possible that the attacker found a way to upload a malicious script and execute it, hacking your site. If you have a secondary site, e.g. a Wordpress installation, inside your site's root and you allow access to it, it is possible that the attacker hacked it and used it as a back door to hack your Joomla! site. Of course there is also the possibility that if you didn't enable the front-end and back-end protection in Admin Tools .htaccess maker that a hacker found a vulnerability which allowed him to upload and execute a malicious script.

2. There's what I call the "under the radar" attack. On most shared hosts it is possible that if a hacker infiltrates another site on the same server he has write access to your site's files. It all depends on ownership and permissions. If the files are owned by the same user under which the web server runs for all sites hosted on the server (as opposed to being owned by your account's FTP user) then you are definitely vulnerable to this attack. Permissions with their second or third digit set to 6 or 7 (e.g. 664, 646, 775, 757 and so on) may also make you vulnerable to such an attack.

3. If you are using outdated software it is possible that it suffers by a vulnerability which cannot be prevented by a security solution. For example, Joomla! 1.6 and 1.7 allow malicious users to create Super Admin users if the user registration is enabled. Due to the nature of that bug no security solution can prevent this. Check the versions of everything you have installed.

Another possibility is the "exploited yesterday, ready to be hacked tomorrow" method. I've seen that many times. A site was infiltrated by a hacker months ago and they installed a back door. Months later they come back and hack your site. The thing is that all your backups are now "infected" with this back door. Restoring your site from a backup will allow the hacker to hack your site again and again and again.

Of course there is the low tech approach: somehow you admin or FTP credentials were stolen. Stealing admin or FTP credentials is dead simple, as long as the hacker is connected to the same network (wired or wireless) as you and your site does not use HTTPS. Stealing FTP logins can also be performed by malware such as keystroke loggers or by more specialised malware which steals, for example, FileZilla's saved connections INI file which contains the credentials in plain text.

I would recommend following the advice in our Unhacking Your Site walkthrough to first identify the point of entry, unhack your site and patch the security hole which made the hack possible in the first place.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Support Information

Working hours: We are open Monday to Friday, 9am to 7pm Cyprus timezone (EET / EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets outside of our working hours, but we cannot respond to them until we're back at the office.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!