Akeeba Backup for Joomla! 4.5.0, Akeeba Solo 1.6.0 and Akeeba Backup for WordPress 1.6.0 have just been released. These are feature and security releases. All users are recommended to upgrade. This article discusses important behavior changes and the nature of the low priority security issues addressed in these releases.
Starting with Akeeba Backup for Joomla! 4.5.0, Akeeba Solo 1.6.0 and Akeeba Backup for WordPress 1.6.0 the front-end and remote features will be blocked until you enter a Secret Word that fulfills industry standard password complexity criteria.
The front-end and remote backup features rely on a Secret Word. Anyone knowing this Secret Word can take, download and delete backups. Since full site backups include all information contained on your site the Secret Word is essentially the key to your site itself.
We have observed that clients very frequently use insecure secret words, i.e. very short alphanumeric strings (6 characters or less), dictionary words etc. These can be very easily guessed or brute-force attacked. The only way to be safe is to treat them as any other password: pick one that's secure. As a rule of thumb you should use an at least 16 character long Secret Word consisting of random letters a-Z, A-Z and numbers. The longer, the better.
The behavior change –disabling backups until you enter a strong, lengthy Secret Word– will prevent the backup from executing on many sites. We do it on purpose, to protect you and your sites. For this reason we consider this behavior change a tightening of security rules in our software.
This version of Akeeba Backup and Akeeba Solo supports:
Please bear in mind that not all versions of Joomla! run on all versions of PHP. For example, very old versions of Joomla! (1.6, 1.7) do not play well with PHP 5.5 and later. Joomla! up to and including 3.4 does not run on PHP 7.0, whereas Joomla! 3.5 does run on PHP 7.0 but not on 5.3.09 and earlier. Furthermore we do not support PHP 5.2 even though very old versions of Joomla! (1.6, 1.7 and some early 2.5 releases) used to run on it.
The same applies for WordPress. Not all WordPress versions run on every PHP release. We always suggest using the latest WordPress release.
Finally, please note that restoring a site on a lower or higher version of PHP than the one running on the server you backed up from may cause the restored site to not work. This has to do with the requirements of the software included in your site, NOT Akeeba Backup / Akeeba Solo.
We have rewritten and reintroduced our Live Update system for installing updates to Akeeba Backup for Joomla! without going through the Joomla! extensions updater. This is a generally more stable method of updating Akeeba Backup as it uses our well tested and tried download and archive extraction technologies.
Please note that the actual installation of the update package is performed by Joomla! for legal reasons. The rules of the Joomla! Extensions Directory (JED) stipulate that we are not allowed to create an extensions installer that bypasses Joomla! core libraries completely. If we were to do so we'd get unlisted from JED.
On Joomla! 1.6, 1.7, 2.5, 3.0 and 3.1 the integrated updater –called Classic in the interface– is the only supported way to update Akeeba Backup. If you try using Joomla!'s extensions updater to update Akeeba Backup Professional you will get an error. Unfortunately these ancient versions of Joomla! lack the support for paid extensions.
On Joomla! 3.2, 3.3, 3.4 and 3.5 you have the choice to either use the Built-in (Joomla! extensions updater) or Classic (integrated live updater) update method. It's up to you; we support both. If you want to update Akeeba Backup through third party services such as myJoomla, Watchful or Joomla! Commander you MUST use the Built-in option.
Two very low security issues were reported by Calum Hutton of NCC Group and fixed in this release. While the effects of these issues can be significant they both require the attacker to already possess privileged information (essentially: be a Super User) or have already compromised your site before they can exploit them.
Since they are both variants of "I can hack myself if I'm a Super User" we consider them low priority. Nevertheless we treat them with the same seriousness as any other security incident and voluntarily disclose information about them.
To be perfectly clear: there is no scenario in which an attacker can use these issues to gain unauthorized access (i.e. hack) your site. The condition of using either of these issues is for the attacker to already have full privileged access to Akeeba Backup and/or your site.
Someone who already knows your Secret Word can store XSS in the database if the remote backup is enabled. Discovered by Calum Hutton, NCC Group.
This security issue requires the attacker to already know the Secret Word necessary for running front-end backups. However, if the attacker has the Secret Word he can already take and download backups of your site, exposing you to much higher and immediate risk. A backup can be used to harvest information about you and your users and/or brute force your Super Users' passwords.
In other words, if someone already has the Secret Word of Akeeba Backup they don't need to use stored XSS to hack you: they have already hacked you. Therefore we consider it a low importance issue as it requires your site to be already compromised.
Discovered by Calum Hutton, NCC Group.
Akeeba Backup allows other components on your site to run backups automatically and the redirect you back to the component. This is used by the Backup on Update feature to take a backup after the update is downloaded and before it's installed on your site. This feature can only be triggered by a component running on your site as it needs access to the session security token, available only to extensions running on your site. Furthermore, for this feature to work you need to be logged in as a Super User.
Unfortunately, the redirection parameter sent to Akeeba Backup wasn't properly checked. Instead of only allowing internal URLs –i.e. links to other components running in the back-end of your site– it allowed developers to use any kind of external URL. This could be used for a low priority attack called Open Redirect.
However, this attack only works if launched by a malicious extension installed on your site while you are logged in as a Super User. However, if a malicious extension is installed on your site it can do anything it wants including serving spam and stealing the usernames/passwords entered in login forms. It would be rather daft creating a malicious extension that runs a lengthy backup you don't expect just to redirect you to a phishing site. Therefore we consider it a low importance issue as it requires your site to be already fully hacked.
Note: The same Open Redirect issue affects all Joomla! versions up to and including 3.4.5. Joomla! 3.4.6 has a fix for this issue in place.
None of these issues can be exploited by an attacker to gain unauthorized access to your site. As a result we decided to not release a security update for these old, unsupported versions of Akeeba Backup for Joomla!. There is no risk for your site coming from Akeeba Backup.
However do note that your site is affected by a major Joomla! security issue discovered in December 2015 that allows an attacker to execute arbitrary code on your site. This security issue affects ALL Joomla! versions released until December 13th, 2015, from Joomla! 1.0.0 up to and including Joomla! 3.4.5. Only Joomla! 3.4.6 and later are secure. The Joomla! project has released emergency patches for the unsupported Joomla! 1.5 and 2.5 releases. Please consult the official Joomla! announcement about these patches. If your site is still running on Joomla! 1.0, 1.6, 1.7, 3.0, 3.1, 3.2 or 3.3 there is no patch available and it's certain that you will get hacked.