Today we have issued security updates of Akeeba Backup for Joomla!, Akeeba Backup for WordPress and Akeeba Solo. The information disclosure vulnerability affects the JSON remote API which is only available when you enable front-end backups. The nature of this vulnerability makes it nearly impossible to exploit unless you are an experienced cryptanalyst and cannot be used to directly hack a site (the attacker can't write to the files or a database). Even though it's extremely difficult to use in a real world situation, we have issued a security update for all versions of our backup software and request all of our users to update as a sane precaution.
Credits: the vulnerability was discovered by Marc-Alexandre Montpas of Sucuri LLC and reported on Monday, August 18th 2014.
FAQ
Q: Is my site in immediate danger?
A: No, it's not in immediate danger. The attack requires a very high level of sophistication, such that only an experienced cryptanalyst can understand it. This is why it went undetected and unexploited for years.
Q: Can this be used to hack sites?
A: It cannot be used to directly hack a site. At worst, a successful attacker would get access to your backups. They would not be able to write anything to your site's disk or database, therefore they can't directly hack your site. A determined, well-staffed and well-funded opponent (criminal network, enterprise actor or state actor) could use this information to manually attempt to detect a different attack vector to hack your site. In so many words, no, it's not realistic to say that your site is in danger.
Q: I have an expired subscription. Do I have to resubscribe to get a security update for my Professional release?
A: No, you don't have to resubscribe. However, you do need to perform a manual fix described further below in this document. On the other hand subscribers with active subscriptions can use the Professional package.
Q: My site was hacked. Is it because of your software?
A: No. As explained, the vulnerability can not be used to directly hack your site and it's so complex that nobody was able to detect it, let alone exploit it in four years. Even if an experienced hacker reads our code fix they won't be able to understand what this vulnerability was all about. You need a cryptanalyst who understands the inner workings of AES to perform this attack. Putting things into perspective, a cryptanalyst is the computer world equivalent of an experienced sniper whereas the typical hacker who hacks your site is the equivalent of a mugger. It's not very likely that someone hired a sniper to mug you, right?
Update instructions for users of Akeeba Backup for Joomla! 3.11.x, Akeeba Solo 1.0.x and Akeeba Backup for WordPress 1.0.x
Just update to the latest available version per the documentation instructions. Just a quick reminder:
- Joomla! users can go to Extensions, Extensions Manager, Updates then install the updates
- WordPress users of the Core version can use WordPress' plugin updates feature to install the update
- WordPress users of the Professional version and Akeeba Solo users can use the integrated updater in the software
Update instructions for users of older versions of Akeeba Backup for Joomla!
Go to our Compatibility page and find the appropriate version of our software for your Joomla! and PHP version. Please remember that version numbers are not decimals. Trailing zeros do matter. 5.3.28 is greater than than 5.3.4. For more information please consult our How to read version numbers page. Install on your site the ZIP file you downloaded, *without* uninstalling your existing version.
Update instructions for Professional users with an expired subscription
Download the latest Core version in the same version family as your existing Professional version. You can find the latest Core versions in our Compatibility page (https://www.akeebabackup.com/compatibility.html).
Extract the ZIP file to your computer. DO NOT install it on your site!
Find the extracted file frontend/models/json.php (version 3.2.8) or frontend/models/json.php (all other versions) and upload it to your site's components/com_akeeba/models directory, overwriting the existing file.
Notes:
- If you have a version earlier than 3.2.7 installed on your site please note that you are affected by a Denial of Service vulnerability we solved about three years ago. Do not follow these update instructions. Instead, disable front-end backup completely.
- If you have a version family which has no update counterpart (3.3, 3.5, 3.7, 3.9, 3.10) you will need to resubscribe and download a new version. Alternatively you may try using the jsons.php file from a newer version but do note that we have not tested this fix and your Akeeba Backup installation may be broken.
Vulnerability disclosure and assessment
The JSON API is using AES encryption to secure the communication between your server and a remote client (Akeeba Remote CLI, myJoomla.com, Watchful.li etc). It also determines whether the remote client has adequate privileges to access the API based on the validity of this encryption using the secret word you enter in the software's Component Parameters (or System Configuration in Solo and WordPress). Moreover, the remote API will respond with an appropriate error message depending on the status of the encryption authentication and the validity of the contained message.
Due to the way the error reporting was implemented it was possible for a malicious remote client to send a small packet of junk and determine whether it would decrypt into valid JSON data or not. Based on this information and the internal workings of the AES encryption algorithm in a specific operation mode, the attacker could obtain an encryption vector without knowing the secret word. This would allow them to see, take and download backups – but not write arbitrary data to your files or database.
Our solution to the vulnerability was to improve the error message implementation in way which increases the number of HTTP requests to get the first bytes of the encryption vector from roughly 2,500 requests to a little over 79,228,162,514,264,300,000,000,000,000 (that's a 29-digit number). The time required to get these bytes of the encryption vector is several billions of billions of billions of the average human lifetime. This makes this kind of attack impossible to mount.
In practice, the attacker would first need to hire a cryptanalyst with advanced knowledge of the internal workings of the AES encryption algorithm. Then they would need to perform thousands of requests to the server to obtain their encryption vector. Given that the smallest encrypted message which does something (list backups) requires 29 bytes the attacker would need to perform over ten thousand requests to very similar URLs on your server. If they tried doing that in full speed on a properly configured server, the server's mod_security2 (or similar) active firewall would have blocked them. Therefore, in the context of the servers most of you are using, a successful attack would take several hours to several days and would be very visible to your host's IT team managing your server through numerous metrics and logs. Therefore a successful attack would reasonably require a cryptanalyst working for the aggressor, a target with an unmonitored server without any kind of protection against suspicious traffic and who enabled the optional remote JSON API because they can’t manage their own CRON jobs. This combination is extremely unlikely. If you are running a critical / high value site on an unmonitored server please do hire an IT team or settle with the knowledge that your site is vulnerable in many ways you can't even imagine.
Bottom line: the aforementioned limiting factors (sophistication of the attacker and impracticality) led to this vulnerability staying undetected for over four years and not having been exploited in a real world situation. It is such a complicated attack that even when someone sees the fix we applied it won't be clear how to exploit this vulnerability in older versions. For good measure we ask all of our clients to upgrade to the new versions as soon as possible. At some point the proof of concept code of the attack will be released. From that point it's a matter of time before hackers wise up and create hacking tools exploiting this attack vector to launch various kinds of attacks, from denial of service and information disclosure to vulnerability discovery in other software running on your site.
At this point we'd like to thank Sucuri LLC and their security analyst Marc-Alexandre Montpas for discovering and reporting this vulnerability, providing the proof of concept code demonstrating the attack and verifying our solution.