Message-ID: <LCYsFG8--3-0@tutamail.com>
Date: Tue, 15 May 2018 14:58:02 +0200 (CEST)
From: <sosumi@...amail.com>
To: Fulldisclosure <fulldisclosure@...lists.org>
Subject: [FD] Keeper Commander

Product:
Keeper Commander

Project URL:
https://github.com/Keeper-Security/Commander <https://github.com/Keeper-Security/Commander/>

Author/Vendor website:
https://keepersecurity.com <https://keepersecurity.com/>


[[[ Summary ]]]

Possible flaw may allow someone controlling the Keeper API server to gain access to the the decryption key to the user's Keeper Vault which in turn is intended to contain account passwords and other sensitive information.


[[[ Timeline in 2018 ]]]

Jan 9  Disclosed possible issue to vendor and entered discussion with CTO

Jan 16 Requested update.  Also requested how to contact Director of Security to get guidance on vendor’s full disclosure policy

Jan 26 Vendor blog post re-iterates that Keeper’s Zero-knowledge architecture means only the user has access to decrypt the Keeper vault

Jan 30 Ask if additional information from me is required.

Feb 1 All emails to CTO and Director of Security result in a SMTP 550 errors saying the policy has prohibited the mail

Feb 6 Sent email to support@...persecurity.com <mailto:support@...persecurity.com> asking if the SMTP errors/policy was a misconfiguration.  Still have not gotten a response.

Mar 13 Vendor post another blog entry indicating the zero knowledge means the information can only be decrypted at the user’s device.

Apr 19 Received email from CTO asking me to join Bugcrowd.  Response to his email still results in a SMTP 550 error.

Apr 21 Contacted Keeper Security live chat to find out if the SMTP error/policy is a misconfiguration.  Told to email support@...persecurity.com <mailto:support@...persecurity.com> again.

Apr 21 Sent another email to support@...persecurity.com <mailto:support@...persecurity.com> and again did not get a response.

May 11 Attempted again to send email to the CTO and again got a SMTP 550 error.


[[[ Why disclose now ]]]

This is my first time performing a full disclosure.  I was hoping for more advice or guidance from the vendor but have not been able to get that since they are now blocking my emails.

The vendor does have a Security Disclosure web page which includes the guideline for disclosure of:

“give us reasonable time to analyze, confirm and resolve the reported issue before publicly disclosing any vulnerability finding”

What exactly is considered reasonable time is not stated in the web page or in any of the communications I had with the vendor.  There was also no soft or hard deadline to produce a fix.  Google Project Zero states it has a 90 day disclosure deadline and indicated that 85% of bugs were fixed in 90 days.  They also indicated they are willing to provide a 14 day grace period for vendor that indicate a patch is coming.  Additionally they indicated the Zero Day Initative (ZDI) provides 120 days.

Originally it seem reasonable to use the 104 day deadline of 90 + 14 grace days as used by Google Project Zero.  However, after the CTO emailed, it seem more reasonable to allow enough time to at least exceed ZDI’s 120 day time period.

After 120 days, I hoped any one of the following to happen:

A. Vendor would provide proof that the claims in my disclosure were incorrect

    OR

B. Vendor would update the Keeper Commander git repository with a fix

    OR

C. Vendor would email a vendor self-imposed deadline to a fix

    OR

D. Vendor would update it’s Security Disclosure web page or blog to provide transparency to the customers as to the current product limitations and when to expect a fix

None of the outcomes that I hoped for took place.


[[[ What is Keeper Commander ]]]

Keeper Commander is a MIT licensed application written in Python 3 that has been hosted on github since November of 2015.  This script can retrieve the Keeper vault with is a series of encrypted entries of Keeper Security’s API server.  It can then modify the password entries in the vault and update the API server with those modifications.  Since it is under the MIT license and the source code is provided, it allows users to extend it to support automated password rotation of a number of different services.

The Keeper Security API server then also acts as a central point of synchronization across Keeper Security products.  Passwords rotated by Keeper Commander will result in updates appearing in any Keeper Desktop or Keeper Filler products used with the same account.

Keeper Commander does not seem to act as a stand-alone product but rather is design to augment the capabilities of the Keeper Desktop and Keeper Filler products.  As such, initially creating a Keeper Vault seems to not be a function that Keeper Commander is written to provide.  However, the source code does provide some insight into the Keeper Security’s API server and the format of the Keeper Vault.  Therefore, reviewing the Keeper Commander open source licensed code should provide an idea how the Keeper Security Zero-Knowledge architecture is being provided.


[[[ No Proof of Concept Permitted? ]]]

Keeper Security’s Terms of Use state:

“Not to use the SDKs and APIs for any application that replicates or attempts to replace the essential user experience or functionality of the Software for another product or service.”

This seems to prohibit any proof of concept which would replicate the API server’s login process to confirm what products contain the flaw or when they are fixed.  No testing has been performed with Keeper Desktop or Keeper Filler.  However, given that Keeper Commander is designed for use by their most security conscious enterprise customers, it seems reasonable to expect any roll-out of a fix would include updating Keeper Commander accordingly.  

While further advice regarding these terms from the vendor was desired, getting such guidance was no longer possible.


[[[ Security Disclosure ]]]

It may be possible to violate how Keeper Security defines it’s Zero-Knowledge Architecture.  According to their Security Disclosure page, the ability to decrypt entries never leaves the user’s device.  What seems to appear in the code of Keeper Commander from November 2015 to today is blind trust of the API server.  If this disclosure is correct, the API server can induce Keeper Commander during login to reveal how to decrypt the vault.  This would mean a security breach of the API server or a court order may result in an user’s vault information being compromised.

To best understand the nature of the flaw, it is best to look at the api.py file in the Keeper Commander github repository.

The login function supplies the account username to the API server and is given back the parameters of salt and key derivation iterations.  The account’s master password is used with these server provided parameters in the popular key derivation function PBKDF2 with SHA256 to produce a 32 byte authentication verification.  This result is then provided back to the API server.

If authentication is successful then the Keeper Vault is provided to the Keeper Commander script and the script moves on to the decrypt_data_key function which is also in api.py

This function then uses another key derivation iteration and salt parameters which had been provided by the API server.  The same master password is again run through PBKDF2 with SHA256 to produce a 32 byte intermediary decryption key.  The intermediary key then is used to decrypt the Keeper Vault encrypted data key.

Since the API server stores the account vault’s parameters of key derivation iterations, salt and encrypted data key, all someone controlling the API server needs is the intermediary decryption key to access the vault entries.

Since Keeper Commander’s login function calls the same PBKDF2 with the same master password, hash function and 32 byte length for result, all that is needed is for the iterations and salt intended for the decrypt_data_key function to be supplied during authentication.  The result the login function will send back to the API server will be the intermediary decryption key.

There are a number of ways this could be fixed such that the results of the login function can never produce the intermediary decryption key regardless of the parameters given at login.  However, such a fix would require modifications to the Keeper Desktop and Keeper Filler products which are closed source.

Hopefully this disclosure can help promote discussion on if the flaw really does pose any threat and if it does how Keeper Security should best address it.



_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists