Announcements

Security updates, August 2017

The updates released to Akeeba Backup for Joomla!, Akeeba Backup for WordPress and Akeeba Solo in the second half of August 2017 are security updates. These versions fix a number of security issues reported by Aram Nap of Securify, as well as another security issue we have detected ourselves. None of these issues has been used to hack any sites. None of these issues can be used to remotely hack / take control of your site.

 

The short version

Your existing version of Akeeba Backup is secure enough for daily use. What we have fixed are some very improbable cases.

If you want to improve the hardiness of profile settings encryption we do recommend following these steps:

  • Install the latest update to Akeeba Backup or Akeeba Solo.
  • Go to Options (Akeeba Backup for Joomla!) or System Configuration (Akeeba Backup for WordPress, Akeeba Solo).
  • Set Use encryption to No. If it’s already set to “No” do not follow the rest of the steps.
  • Click on Save & Close (NOT Save)
  • Once you are back to the Control Panel page go to Options (Akeeba Backup for Joomla!) or System Configuration (Akeeba Backup for WordPress, Akeeba Solo) again.
  • Now set Use encryption to Yes
  • Click on Save & Close (NOT Save).

If you cannot upgrade to the latest version of Akeeba Backup for Joomla!, e.g. old Joomla! or PHP version, do not worry. None of the issues addressed can realistically be used to hack your site. The only reason we address even improbable, potential, far fetched security issues is that of completeness against any contingency. We are paranoid so you don’t have to be.

Since none of these issues is serious enough (they do NOT lead to remotely hacked sites) we decided to NOT publish any security updates for Akeeba Backup 4.x. Hacking your site using the remaining issue would require the attacker to have read access to your database and the front-end backup feature to be enabled. If you are on an old version of Joomla! or PHP and cannot update to the latest version of Akeeba Backup 5 you should be far more worried about the known security vulnerabilities in your old version of Joomla! and PHP which can and are used to remotely hack sites. We strongly recommend that you update your sites to the latest version of Joomla! and PHP as soon as possible. In any case, if you are stuck on an ancient version of Joomla! and / or PHP you can always disable front-end backups from the component’s Options.

If you are using Akeeba Solo or Akeeba Backup for WordPress you can of course update to the latest version. The minimum requirements have not changed.

Finally, we very strongly recommend that you always use the ANGIE Password feature to prevent any leak of information pertaining to your site (from PHP and Joomla!/WordPress version to the database password itself) when restoring your site. This is an upgrade from our previous recommendation that you should use it.

Affected versions

In the rest of this document we are going to be using the following abbreviations to denote affected versions:

  • AB: Akeeba Backup for Joomla! 5.5.1 or earlier
  • Solo: Akeeba Solo 2.3.0 or earlier
  • ABWP: Akeeba Backup for WordPress 2.3.2 or earlier
  • ANGIE: ANGIE, the backup restoration script included with the aforementioned versions of Akeeba Backup and Akeeba Solo.

Security issues fixed

The rest of the article contains technical information. You are NOT required to read it. It’s provided in the interest of full disclosure and satisfying the curiosity of fellow PHP engineers. If you are not a PHP engineer you can stop reading now.

Settings encryption

Affected: AB

By default and since backup profile settings may contain passwords they are encrypted with AES-128 in CBC mode using a site-specific password which is automatically generated when you install Akeeba Backup. This is done to protect them against a possible vulnerability in third party software or your server which would allow an attacker to read the contents of your site’s database. An attacker would need to have access to both your site’s database and your site’s files, i.e. fully hacked your site, to decrypt these settings and steal the information contained therein.

The security issue lies in the way the site-specific encryption password is generated. Akeeba Backup for Joomla! was using an outdated scheme which didn’t guarantee true randomness. If someone knew the exact point in time the key was generated and had information about the last modification time of some of your site’s files at that point in time they could narrow down the used key within a few million possibilities. The likelihood of that being possible without a fully compromised (hacked) site is minimal, hence this part of the attack is of very low impact.

This issue is fixed by using 64 cryptographically random bytes using a crypto-safe random value generator. By order of preference we will use OpenSSL (the library powering HTTPS communications in most sites you’re visiting) or mCrypt. Those of you paying attention may have noticed that there’s a fallback to a plain PHP method. This would only be used on some really old servers which are statistically insignificant and we do plan on removing support from them in 2019. If your server doesn’t have the PHP OpenSSL module installed, compiled against OpenSSL 1.1 or later ditch your host for someone who knows how to run a secure server. Plain and simple.

If you want to generate a better encryption key for your settings, without losing your settings, please follow the instructions towards the top of this article.

As a side note we’d like to clarify why we consider this a low priority issue instead of high. The security researcher mistakenly claimed that because MD5 was being used in the password’s generation “the complexity of a brute-force attack is decreased from 25632 to 1632. Each byte has 16 possible values due to the hexadecimal encoding, as opposed to 256 possibilities”. This would have been correct had we been using the password as the raw AES key (which is, notably, 128 bits or 16 bytes long, not 32 bytes long), which would be a blatant mistake. However, we did not do that, ever. It’s used as a password from which an AES key is derived. The 32 byte, hex encoded MD5 is a password that has 4 bits per character * 32 characters = 128 bits which is incidentally the size of the AES-128 key. Maybe that’s where the confusion came from. We chose this length because in the end of the day it’s complex enough to deter brute force attacks with technology available in the foreseeable future.

There is a catch, though. This password undergoes a key expansion procedure to generate an 128-bit AES key. There was, indeed, a security issue with that. However, we had already fixed it in February 2017. Before February 2017 key expansion was done in an insecure method (encrypt the password with itself as the key) which would, indeed, compromise the security of the key since only half of its bits (64) were used. That’s still 18 quintillion possibilities, not 1632. Breaking this encryption still takes around 5 to 15 GPU years with current technology - and only if you have the database dump of the Akeeba Backup / Akeeba Solo settings to begin with. That’s why we said this is not a high level security vulnerability. Had we not addressed this issue back in February 2017 it would be a high priority issue since the encryption key could be brute forced in a reasonable amount of time and with a reasonable cost in a matter of months to years.

In any case, after February 2017 we are using the industry standard PBKDF2 key derivation function with a salt generated by the crypto-safe random value generator discussed above. This increases the time required to crack the encryption with modern technology to several billion times the age of the known Universe. That is to say that unless there is a breakthrough in quantum computing -which will reduce all of humanity’s encryption technology based on large prime numbers into a pile of rubbish- or a direct attack to Rijndael (the actual algorithm behind AES-128) that would be secure enough for all practical purposes.

Secret Word for front-end and remote (JSON) backups was stored as plain text

Affected: AB, ABWP, Solo

The Secret Word for the legacy front-end backup method and the remote backup JSON API was stored in the database as plain text. If an attacker was able to dump the database contents using a vulnerability in third party software AND the front-end and remote backups feature was enabled then it would be possible for them to take and most likely download remote backups. As a result they would have an exact copy of your site which they could use to either extract useful data or crack your Super User password to subvert your site for nefarious purposes (sending spam, serving ads, botnet command and control node, …).

We consider this a high priority issue as it is possible for someone who has access to your database to read the unencrypted Secret Word and obtain a copy of your site. It is possible for someone with lower privileges than a Super User to have access to third party software which either by design (e.g. database editor plugins) or a programming error (security vulnerability in the third party software) allow this kind of database information read to take place. As a result this issue could be used for privilege escalation, hence our rating as high priority.

We are now encrypting the Secret Word in the same way we do your backup profile settings. As long as your server supports encryption and you have not manually disabled it in Options / System Configuration the Secret Word will be encrypted the next time you visit the Control Panel page of Akeeba Backup / Akeeba Solo.

Please note that you will no longer be able to see the human-readable Secret Word in the Options / System Configuration page. Instead, you will see something beginning with###AES128### or ###CTR128### and a jungle of seemingly random characters. This is by design, it’s the encrypted form of the Secret Word. You can still see the Secret Word in the Scheduling Information page.

If you are on an older version of Akeeba Backup for Joomla! and cannot upgrade due to an old PHP or Joomla! version we recommend turning off the front-end backup feature from the Options page for maximum security. We do not plan on releasing a new version of Akeeba Backup 4.7 to address this issue. Why? Because these old versions of Joomla! and PHP have more serious, known security issues which can be used to remotely hack your site. No need to find the Secret Word of Akeeba Backup first. Upgrade your sites!

Side note: the security researcher made a claim that since the backup process is resource intensive and there is no lock mechanism it can be used as a means for a Denial of Service attack. He failed to take into account two very important facts that make his point moot and which we have discussed in the past.

First and foremost, you CAN NOT launch a remote backup unless the front-end and remote backup feature is turned on (by default it’s Off), a Secret Word with adequate complexity (to make it practically impossible to guess) is used and you are in possession of said Secret Word. Having the Secret Word gives you the ability to run and download backups, i.e. you have the equivalent of a Super User (Joomla!) / Super Administrator (WordPress) access. In other words, this falls into the category of “if I am Super User I can hack myself”. Yes, by definition you can, that’s what being a Super User is about: unrestricted access to the system. Also, if you have the Secret Word you would have to be a really stupid attacker to use it for Denial of Service -which is easily fixed by disabling the front-end backup feature and leads to your detection, therefore you lose access to the target- instead of using it to take and download a backup, then using the information gained to subvert the site for profit.

The second obvious fact he missed is that there is a locking mechanism BUT starting a new authorized backup resets it. Back in 2008 the locking mechanism did not reset until at least 3 minutes had passed OR the user deleted the lock file. The problem is that we had users whose backup failed, they ignored the message about resetting the lock, they didn’t even click on the button we had provided for this reason and then complained to us or filed a negative review about how “broken” our software was. Long story cut short, the only solution was to have each authorized backup attempt reset the lock on previous backup attempts. This also has the effect that any attempt to step (continue) any of the previous backup attempts will fail without using any resources. For all practical intents and purposes your exposure to denial of service by abuse of this feature is the same as having a lock that prevents a backup taken from the same origina (backend, frontend, JSON API or CLI) and backup profile to start before the previous one from the same origin-profile combination is over.

I don’t know why we have to debate common sense again. Can we all agree that if you need Super User / Super Administrator privileges to do something it’s not a security vulnerability because a Super User / Super Administrator has by definition full control of the system? If you give me root access on a Linux box I can run rm -rf / --no-preserve-root and brick it. I don’t see anyone claiming that –no-preserve-root is a security vulnerability in rm.

The akeeba-altbackup.php / altbackup.php script does not validate SSL certificates

Affected: AB, ABWP, Solo

These scripts are designed to be run in a CRON job on the same server as your site, taking a backup of said site using the front-end backup feature. This is meant to be an alternative to the pure command line backup script akeeba-backup.php / backup.php for certain sites.

The report claimed that since we’re not checking the validity of SSL certificates it would be possible for an attacker “to use a man-in-the-middle attack to capture the front end backup secret word. The attack only works when an administrator has configured automated backups using the akeeba-altbackup.php script, and the server uses a NAT router. By rerouting the server’s connection to itself through an attacker’s proxy on the same network a successful man-in-the-middle attack can be conducted.”

While theoretically possible, it’s a bit of a stretch and very unlikely to exploit in practical scenarios. It’d require an attacker to have gained root access to the NAT server and have another server in the same internal network acting as a proxy (a server in an external network couldn’t be used as a proxy for internal IPs). It’s more likely to win the lottery than finding a real world case where the attacker has achieved this kind of deep network compromise - not to mention that they would then use this to attack your Akeeba Backup Secret Word. I wouldn’t lose any sleep over that.

In any case this is a genuine oversight we should have caught. It’s the one place we missed in an internal code audit back in late 2014. Therefore we fixed it in this version. We’ve also provided the command line switch –no-verify to revert to the old behavior. That’s for sites with self-signed certificates. The security conscious among you may have noticed that self-signed certificates are just as insecure as not using HTTPS at all. Yes, the –no-verify option is there to remove security because not everyone using our software is a security conscious individual or willing to become one when we explain why their practices are insecure. In short, if you want to shoot your own feet here’s your shotgun, don’t blame us when you shoot your feet off.

Improved internal authentication in integrated restoration

Affected: AB, ABWP, Solo

This is a revisit of a security fix from August 2014 with extra hardening applied. We discovered this one ourselves. That said, there is no practical security issue for your site. We had already fixed the security issue.

Long story cut short, the integrated restoration was using AES-128 in CTR mode for authentication purposes between the JavaScript part of the restoration running on your browser and the PHP part of the restoration running on your server. The downside is that because of the way decryption works you may have subtle timing differences when you send random garbage which cannot be decrypted versus legitimate information which can be decrypted. An attacker could send hundreds of thousands to millions of requests to infer the encryption key and use it to extract a ZIP file of their choosing on your site.

Back in 2014 we mitigated this issue in several ways:

  • The secret key used was of better quality, using a crypto-safe random value generator.
  • The error messages returned were fuzzed in such a way that it was several orders of magnitude harder for the attacker to infer timing information. On the fastest available commercial dedicated server it’d take more than 30’ to brute force the password. On most shared servers it’d take hours to years.
  • The restoration was locked to a specific backup archive file.
  • As soon as you hit the “Clean up” button at the end of the restoration the attack window closed.

The solution was deemed good enough by both us and the cryptanalyst who had reported the issue.

This left only one attack scenario: you start integrated restoration, you never use Clean Up (instead removing the installation folder manually), your server is fast enough for an attacker to brute force his way through it, the backup archive is not removed and the attacker uses the integrated restoration to overwrite your site with the backup. It’s extremely unlikely and mildly annoying instead of outright dangerous but it still bothered us.

What all of us missed back in 2014 is that using browser-side cryptography in JavaScript was pointless. It’s the “chicken-egg” problem that the (rather dated) JavaScript Cryptography Considered Harmful article describes: you need to send the password from the server to the browser before the restoration begins. Using cryptography is, therefore, pointless as anyone able to perform a man-in-the-middle attack against you has the key and can abuse the restoration script as described. Even worse, by using cryptography for authentication we open the possibility of a timing-based attack which can compromise the key.

Ironically, the best way to prevent the timing attack is sending the password in plain text from the browser to the server. A man-in-the-middle attack still has the same success in stealing our password. However, we can not and should not attempt to address this issue in client code; this problem can only be solved by using HTTPS on the site. Unlike 2014, this is now trivial thanks to free, commercially signed SSL certificates issued byLet’s Encrypt and the integration of such SSL certificate issuance (and renewal!) in most commercial hosts’ control panel software. If you’re not using HTTPS already, what are you waiting for? Using HTTPS mitigates man-in-the-middle attacks.

Moreover, sending a plain text password allows us to performtiming-safe string comparisons which emphatically neutralize an attacker’s ability to infer our password based on timing attacks. Therefore sending plain text passwords prevents remote attackers from gaining access to the restoration script. They’d have to guess 32 truly random bytes or 2^256 combinations. In practical terms, that is several quadrillion trillion billions longer than forever, where “forever” is the age of the known Universe.

Things which are not vulnerabilities

The report by the security researcher also had a bit which is invalid. It is purely speculative and not backed by a proof of concept or, at the very least, any solid evidence:

“Furthermore, there’s an implementation of AES with CBC and CTR modes. While this implementation may or may not be secure, it has not undergone rigorous testing. Which is categorized as CWE-327 Use of a Broken or Risky Cryptographic Algorithm. Using a custom library increases the risk that the implementation of a cryptographic algorithm contains errors. I have not found any such errors myself, but I’m not an expert.”

Only the AES-128 in CTR mode is a custom, pure-PHP (and pure JavaScript) implementation. As mentioned above, it was used in integrated restoration but not anymore. It is used in old JPS archives, taken with Akeeba Backup and Akeeba Solo versions released before February 2017. It’s used for the remote JSON backup API and for encrypting backup profile settings on very old, insecure servers when neither OpenSSL (preferred; up-to date; secure) nor mCrypt (in itself an obsolete artifact of the past) are available.

We have already scheduled removing the ability to encrypt into AES-128-CTR and using mCrypt for encryption in 2018. Why not remove the code completely? Because our software has dozens of millions of installations and we think that our users would be rather miffed if we deleted all of their settings, broke all of their remote backup scripts and made all of their old backups impossible to extract overnight in the name of righteousness (for choosing a cryptography library is like converting to a religion, there are no guarantees you made the right choice until it’s too late).

For the same reason we cannot just go ahead and use someone else’s crypto library. What we decided to do in late 2016 is takeDefuse PHP Encryption as our guide to a good implementation of AES-128 CBC in PHP, along with several blog posts by established researchers, and refactor our code. The objective was to BOTH support decryption of data encrypted by our software released before February 2017 AND use modern, safe encryption for data which is encrypted by our software released after February 2017. Moreover, unlike the PHP Encryption library version linked above and used by Joomla! itself, we support both mCrypt and OpenSSL, with the latter being the default since mCrypt is no longer maintained.

Therefore we reject the claim that we use a “Broken or Risky Cryptographic Algorithm” as conjecture.

ANGIE will no longer lock its session to prevent information leaks

This is not a security issue but since it can affect the security of your site during restoration we thing we should mention it here.

Akeeba Backup for Joomla! 5.5.0, Akeeba Backup for WordPress 2.3.0 and Akeeba Solo 2.3.0 introduced a new version of ANGIE, our site restoration script, which had an enhanced security feature: if two or more people tried to access ANGIE only the first one would be granted access. This was designed to prevent random visitors on your site from accidentally bumping into the restoration script and get information about your site (including the database password), something which could be a security issue should this information fall to the wrong hands. This is called a “session lock”. Instructions to remove the session lock and switch it to your browser -which require FTP access- were printed on the screen.

Unfortunately, like every best laid plan, it didn’t survive contact with the situation on the ground… A very vocal minority of our users failed to follow the simple instruction of deleting a file and got increasingly agitated. Adding any other “user-friendly” way to reset the lock is equivalent to not having a lock at all. Between that and the ANGIE Password feature already fulfilling the need for security during restoration we decided to completely remove the session lock feature and keep the ANGIE Password feature.

We recommend that you use the ANGIE Password feature instead. This will add a password protection to the restoration script. Unless you know the password you cannot access the restoration script. This prevents the potential security issue while restoring. Alternatively, or additionally, you may use Akeeba Kickstart’s Stealth Mode which prevents access to the site by any IP other than the one you are using. The downside is that the latter method only works on Apache and Lighttpd servers which are not behind proxies. That’s the majority, but not all, servers. Therefore we have to insist that using the ANGIE Password feature is your best option.