On 29th of September 2017, @pstn reported a medium data leak vulnerability in PrivateBin. Vulnerability write-up done by @rugk and @elrido.
The vulnerability has been fixed in PrivateBin v1.1.1. Admins are urged to check whether they are affected by this configuration issue.
Affected versions
Any ZeroBin and PrivateBin version before 1.1.1
Conditions
- Another web server than Apache has to be used or an Apache server with "AllowOverride None" option set for the virtualhost PrivateBin is hosted under.
- The config and data directories are left in the websites document root path (contrary to the recommendation in the installation document).
Steps to reproduce configuration file leak
- Go to https://paste.exmaple.com/cfg/conf.ini.
- Download the file.
Steps to reproduce paste file leak
- Go to https://paste.example.com/.
- Create a new paste as usual via the UI.
- Assuming the generated paste has been given the random ID fecba9876543210f, go to https://paste.example.com/data/fe/cb/fecba9876543210f.
- Download the file.
Impact
In the circumstances described above, the config file of PrivateBin may have been leaked to third-parties. If a database is used, this includes the database passwords, which were set in the config file.
In reference to the Common Vulnerability Scoring System v3.0 we categorize this as a medium vulnerability. It can be exploited by remote attackers and it can leak confidential data (database passwords), so we consider it's confidentiality low, because it does not always leak such cinifdential data as passwords. In this calculator only the impact is considered, not the (special) condidtions, which we described above.
In setups using the file store instead of databases, the pastes are stored as text files containing raw JSON data structures under the data folder. The server side JSON contains some information that is not exposed to client via the REST API. Using the leaked paste salt and the already known paste ID one can generate a deletetoken using a SHA256 based HMAC function passing the pastes ID as the key and the salt as the message. This allows an attacker to delete any paste, if they know it's ID, even without any knowledge of the paste key or contents. While this does not stricly leak sensitive or encrypted data, it is contrary to the design of the software, that only intends to give the paste creator the ability to delete a paste before it times out. Thus this can be used to cause a kind of "denial of service" attack.
Real-life impact
Prior to releasing/fixing details of the vulnerability, we notified affected server admins, who (are listed on our wiki list).
We identified six affected servers affected by the config data leak. One of these servers also leaked MySQL credentials. We contacted these and provided information in order to fix the data leak.
Out of all contacted sites, four fixed the issue at the time of the publication of this advisory. The site which leaked MySQL credentials has fixed the issue and reported to have changed the credentials.
Mitigation
Since April 29th, 2012 (ba90d0c, while PrivateBin was still a fork of ZeroBin 0.15) we provided a way for server admins to secure their PrivateBin installation by moving important directories out of the web root. When a server admin has done so, they are not affected by this issue.
Secondly we always provided a .htaccess file, which automatically protected systems using the Apache server that do not disable the use of these.
System administrators can also always configure their own web server themselves to protect these special directories.
This vulnerability has been fixed in PrivateBin v1.1.1 released on 2017-10-10 with the commits 9215a96 and 6b87a6e. Additionally we changed our installation instructions to stress our security recommendations.
Further information
Administrators that are affected by this issue and saved confidential data (such as database passwords) in their config file, are strongly advised to change these credentials.
System administrators of the instances, where the cfg/ and data/ directory are accessible, should protect these directories with an appropriate web server configuration or by following these steps.
Timeline
- 2017-09-29 – Reporter asked for contact information, got a tip from collaborator.
- 2017-09-29 – Reporter privately reported issue.
- 2017-09-29 – Receipt confirmed.
- 2017-09-29 – Issue confirmed and preliminary patch provided to reporter.
- 2017-10-01 – Server admins contacted.
- 2017-10-04 – Restructured installation instructions.
- 2017-10-10 – Release published.
- 2017-10-10 – Vulnerability details published.