[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ownCloud Unencrypted Private Key Exposure



Hi,

thanks to everyone for the input. Agreed, some clarification would be nice.

I have verified that ownCloud 7.0.1 on Debian Wheezy is vulnerable, happily exposing unencrypted 4096 bit RSA private keys in PHP session files upon user login. But it seems that an attacker needs three things to decrypt the user's data.
1) The encrypted data
2) For each encrypted file, he needs a corresponding key file used for the symmetric file encryption 3) The leaked RSA private key which is used to encrypt/decrypt the key files

If we take that into account, it _may_ be possible to make sense of the two excerpts from the manual which you quoted. Let's say the user data and file encryption key files are stored in one directory tree which is on "external storage". Let's then say that the PHP session files are created in a different directory tree on the local file system. This means two things. 1) The provider of the external storage has access to the encrypted data and the encrypted file keys, but cannot access the RSA private keys. Thus he will not be able to decrypt the data. 2) The administrator of the ownCloud server however has access to all three if the "external storage" is mounted into the file system. So he has everything he needs to decrypt or "intercept" user data.

That is highly speculative on my part though and implies a distinction between the provider of the "external storage" and the "server administrator". If it is really meant like that though, it still seems like a huge restriction to me, and it's hard for me to believe that this is actually as intended. Because I'd think that most people would assume that if there is server side encryption, it is there to protect the data from anyone with filesystem access. And that includes the server administrator in my book.

Regards
Frank


Am 05.08.2014 20:09, schrieb Jack Brennan:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

A valid concern.

HTTPS should be used to secure traffic from a client to the server,
solving any problems related to eavesdropping.

Encrypting the content of the account data should solve two problems.

1. Secure data from curious system administrators.

2. Secure data in case of an account breach, Lost password or phishing
(ect.)

3. Secure data that is copied off the server and taken offsite.

The current solution doesn't solve any of those problems. Firstly the
users password is the encryption key. Secondly, in the case of number
3, an attacker that can get your raw data will either have your
account password or server side access.

- From the OwnCloud Manual:
http://doc.owncloud.org/server/6.0/user_manual/files/encryption.html

"Server-Side encryption is especially useful if you use external
storages. This way you can make sure that the storage provider is not
able to read your data."

I'm not quite sure what they are suggesting, because if we read a
little further:

"Encryption and decryption always happens server-side. This enables
the user to continue to use all the other apps to view and edit their
data. But this also means that the server administrator could
intercept your data."

With that in mind it would be nice to get some clarification as to
what threat the encryption solution is designed to mitigate.

Jack.

Den 04.08.2014 16:00, skrev Frank Stanek:
Hi,

thank you for this announcement. I have a (very naive) question
about this. As a consequence of this vulnerability an attacker with
access to the ownCloud server's file system can compromise the
encrypted data stored on the server. There does not seem to be a
workaround for that and there will be no fix. Thus, data on an
ownCloud server is always accessible to an attacker with access to
the file system, regardless of whether ownCloud's encryption
feature is enabled or not. Is that correct so far?

It seems to me that one of the encryption feature's main purposes
is to prevent an attacker with access to the server's file system
from immediate access to the user data. If my understanding above
is true, then this purpose is void since the encryption is useless
in that scenario. If this is somehow not part of the vendor's
threat model, isn't it at least an important restriction? Or did I
completely misunderstand something?

Regards Frank


Am 04.08.2014 08:38, schrieb Senderek Web Security:

Senderek Web Security - Security Advisory

ownCloud Unencrypted Private Key Exposure
=========================================



https://senderek.ie/archive/2014/owncloud_unencrypted_private_key_exposure.php



Revision:         1.00 Last Updated:     3 Aug 2014


Summary:

In consequence of an insufficient threat model, ownCloud is storing
all user's private RSA keys in clear text in PHP session files.
These unencrypted private keys can be accessed by every web
application that has the privilege of the web server user. The
affected files exposing cryptographic keys will be stored in the
PHP session directory for a number of hours until they are
removed.

This issue was reported to ownCloud via encrypted email on Tue, 11
Mar 2014. I received a reply to this report from the vendor on Wed,
12 Mar 2014.

On Tue, 22 July 2014 the vendor confirmed, that they will not
address this problem, because the protection of user encrypted
files from remote attackers that have read access to the file
system with web server privilege is not - and will not be - part of
their threat model. Consequently, the vendor does not consider this
to be a vulnerability or security issue.

Severity: High


Affected Software Versions:

All versions of ownCloud since the introduction of the encryption
module in version 5.0.7 including version 7.0.0.


Impact:

An attacker, who is able to read the PHP session files by
exploiting another web application that is running on the ownCloud
server, will be able to gather the unencrypted private key of every
ownCloud user. All encrypted files that are stored in a user's
home directory can be decrypted with this RSA private key, stored
in the PHP session files in plain text. If the user's encrypted
files are synced to other devices or shared with other servers -
for hosting or backup - an attacker will be able to decrypt all
user data that is being intercepted, even if the attacker has no
longer access to the server's file system.


Fixes:

In addition to the ownCloud encryption module users are advised to
encrypt their sensitive files separately with a standard
server-side encryption mechanism like GnuPG using a passphrase,
that is not stored on the server except while being used in
memory.

One software solution that extends ownCloud with GnuPG-based
server-side encryption can be downloaded here:


https://senderek.ie/downloads/release/cloud/wee-owncloud.tar

A detailed installation tutorial is available at:

https://senderek.ie/wee/cloud/wee-owncloud.php

This general web application extension addresses a more
comprehensive threat model, that includes the possibility of
read-access to web server accessible files on the server. However,
it does not protect against malicious actions of server admins, as
this cannot be prevented by web applications.


Security Advice Policy:

Complete information about reporting security vulnerabilities can
be found here:

https://senderek.ie/responsible.disclosure.policy.php

All information in this security advisory is copyrighted because of
the time and effort in analysing and documenting the vulnerability
described here.



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQIcBAEBAgAGBQJT4R3oAAoJEPpQKPtuKWnoFjwQAMWMuZbv0Ew1EH78SziqWrn9
rWyh/fN6WUJWfX8igjNzNUPDG8/t2WPauFzcjPCdDal/l12EuZwfGF/9HqZQ2yEn
jv9EndaEz2qB5gI1Y1Mu0YjBRMq6yc4vHmoyVV2B1nT/1Bl0inbMCRBw5gQ6xrcH
TwokU0ozbWoJ6X3e+ZVpRwe47+h96cb73F2Djw+vOlAt4DVwSkQ7WJANg4UCNvtT
/KQExQMpw2MfFMu+F4Sn4CW3rad6NavcipLoA2yplAixUkoNdjl0aqmoR2mXhtQl
0MTgpDVit+fbFAQilqcZt9xQQ8F3yJ5/maQAOymZ+v/L+ADJztf4aK/C9SmK6p4c
ebCsinUJdG+TxsGrRVWdFaiXX8StFV134s54XqVNMb99qe8/8kZ7DnFNzZgFeZLv
3TeS0RiZd/oF4OIiy1VpYhIV2hy1LJVRe8YCuCXPUxHLXLaMiulspOSp2eDnGux6
CwhGP8qO1Zw3HR1f6P0cdhdnrWSJgAJmFevJGnvKNVKrtF/OZS+NjasxG/PjQSnR
4J1CtAkZKvBjTyNBYsL5UkZC1xEL2uD5QZ/oWWPyif6Qq9JQ//3t4qmroOglFO99
K+LXOGasCDigVZukimNxsmfL6LlwcbVW3yBBitbpfQliqMPD4IicSD2XGewum8f9
3EKxh1/JN09NV7aaBxiS
=PSVy
-----END PGP SIGNATURE-----