The downside of having popular software is that we frequently get bogus security reports. Typically it's someone running an automated vulnerability scanner while lacking the technical skills to understand the report and put it in perspective. This happened again yesterday, March 7th, 2017. Do not fear. Akeeba Backup is secure. Please read on for the more technical explanation.
TL;DR
Akeeba Backup is secure as ever. There is no security issue. There is nothing to do because there is no security issue to begin with.
The "report"
In this article I am talking about this report which has been reproduced in several sites without verification. Let me start by saying that the only truthful element in the report is that there is a bug in Akeeba Backup for Joomla! - and also Akeeba Backup for WordPress and Akeeba Solo. This bug has been there since Akeeba Backup 3.0. However, this bug is NOT a vulnerability.
What is the bug
There is some code which produces a file and directory listing and annotates it with file filter information. This code is used by the Files and Directories Exclusion page to render its interface. Due to an oversight, one of the parameters to this code accepts values containing double dots. This lets you list the contents of directories above the configured site root to backup (which may or may not be the site's root). It does not let you read the contents of the files.
While this sounds pretty bad, once you consider the conditions under which the bug can be triggered you'll see that it's actually pointless.
Requirements for "exploitation"
I. Your server must allow listing the contents of files and folders above your site's root and / or above your account's home directory. This is ultimately up to the configuration of your server. This is something that your host handles, not Akeeba Ltd. Kindly note that the server configuration determines what is possible by all software running on the server, not just our backup software.
II. You must be a Super User or have the Manage and Configure privileges, i.e. you need unlimited access to the site. That's the main reason this is not a vulnerability. This bug will not trigger if you are not already logged in as a Super User (Administrator in WordPress) or as someone who has the Manage and Configure permissions on the software (Akeeba Backup for Joomla and Akeeba Solo only). If you try to reproduce this bug as an unprivileged user or without being logged in you will simply get an error and no information will be disclosed.
When you are a Joomla! Super User or a WordPress Administrator you can access and modify all of the configuration and content of the site. Furthermore, you can install and execute any kind of arbitrary code. For example, you could use these privileges to install a file manager component / plugin which gives you a more user-friendly interface to the same content which would be exposed by this bug.
In case you were given the Manage and Configure privileges to Akeeba Backup or Akeeba Solo you can access all of its configuration interface. This allows you access to the same information or worse. That's because the backup software has three legitimate, documented features which allow you to handle content outside your site's root.
1. Directory browser in the Configuration page. The Configuration page allows you to select an Output directory where the backups will be stored. In our documentation we recommend that this folder be outside your site's root. Ideally, it should be completely outside the web root. Therefore we let you configure an off-site directory, as long as it's writable per your server configuration.
Next to that field we have a Browse button. Clicking it lists the contents of folders, starting with the one configured in the Output directory field. As a result you can choose any folder, as long as your server allows you to browse its contents. Therefore you don't need to try exploiting a bug to produce a directory listing. We give you a graphical interface by design.
2. Off-site directories inclusion. The Professional versions of our backup software allow you to include any arbitrary directory - especially those outside your site's root - in the backup. This is by design. It's a very useful feature when you have configuration files or privileged assets outside the site's root that you need included in your backups.
If you have the Configure privilege you can use this feature to include any directory you want into the backup. Moreover, you can access the Configure page and change the Post-processing Engine to move the backup to a remote storage of your liking, such as Dropbox, Google Drive, OneDrive, S3, FTP, SFT, etc or even by email. Therefore it's trivial an easier to get full access to the contents of the files using the provided features than to merely list their names exploiting a bug. This makes exploiting the bug pointless and obsolete.
3. Override root. The Professional versions of our Akeeba Backup software and all versions of Akeeba Solo allow you to select the configured site's root for backup purposes. We let you assign any directory outside where our software is installed. There's a good reason for that: people have multiple sites inside the same hosting account but want to back them up separately, from the same installation.
Again, having the Configure privilege you can use this feature to point the backup to a specific folder and set up the Post-processing Engine to move the backup to external storage under your control.
Why this is not a vulnerability
As I have explained in the past, a bug becomes a vulnerability when at least one of the three "C / I / A" principles of the system is compromised.
Confidentiality. You need to be a fully privileged user to trigger this bug. As such the Confidentiality is not applicable (you are privy to all secrets of the system). Moreover, the system already provides you other, more user-friendly, legitimate means to access the same information which would be exposed by the bug. Therefore Confidentiality is not compromised.
Integrity. You can not modify any kind of data as a result of this bug. Therefore the Integrity is not compromised.
Availability. You can not cause denial of service or even hamper service provisioning as a result of this bug. Therefore Availability is not compromised.
None of the three principles is compromised, therefore this is not a vulnerability.
Mitigation
We will fix the bug in the next release of the software. Since there is no imminent security threat whatsoever we will not issue a release immediately.
Our clients need to take no further action. THERE IS NO SECURITY ISSUE. YOUR SITE IS SAFE.
How pointless was that report, anyway?
Let me give you an analogy.
You have Joe a copy of your house key, because Joe is a good friend you trust and he is staying at your house. One day Joe uses his key to let himself into your house. Then he uses a fiber optic mini camera to peek through the keyhole of the unlocked door of your kitchen and sees that you have onions at the bottom self of the rack across the wall. Joe goes around the town and says that doors of this make and model are insecure because he could peek through the keyhole with a cumbersome, fiber optics mini camera.
People in the town think that Joe is an idiot but they start asking the door manufacturer if having such a door inside their house would let people from the outside peek at their onions. The door manufacturer has to unfortunately reply to these comments and explain that Joe is a complete moron and probably drunk because a. he had the key to the house to begin with, b. the door was unlocked so he could just open it and c. if he is inside your house he can most certainly peek at the onions you left in plain sight lest you put them in a locked cabinet that you and only you have the key to (being the host and all).
March 8th, 2017
Nicholas K. Dionysopoulos
Director, Akeeba Ltd