[<prev] [next>] [day] [month] [year] [list]
Message-ID: <78458bc75399fa9645085abf5e527aa1@ciphron.de>
Date: Mon, 31 Jul 2017 15:12:13 +0200
From: Karsten König <kk@...hron.de>
To: fulldisclosure@...lists.org
Subject: [FD] CIPH-2017-1: Advisory for StashCat
1. Introduction
===============
* CIPHRON-ID: CIPH-2017-1
* Product: heinekingmedia StashCat
* Status: Patch available
* Affected versions:
* Android: <= 1.7.5
* Web: <= 0.0.80w
* Desktop <= 0.0.86
* Vendor-URL: https://www.stashcat.com/
* CVE: CVE-2017-11129 bis CVE-2017-11136
During an independent investigation researchers of CIPHRON found
vulnerabilities in cryptographic and security functions of the instant
menssenger StashCat of heinekingmedia GmbH.
CIPHRON follows the principle of responsible disclosure and has informed
heinekingmedia beforehand. heinekindmedia has reacted to the disclosure
and has developed patches. These patches are available and will be
distributed in successive.
CIPHRON follows an own disclosure policy. This is available at
https://ciphron.de/vulnerability-disclosure-policy
2. Description of software
==========================
StashCat is developed by heinekingmedia GmbH and has the aim to give
customers an instant messenger which encrypts the communication between
clients End-to-End like it is known, for example, from WhatsApp or
Telegram. It is worth mentioning that the messenger provides a web and a
desktop client in addition to the Android and iOS app.
According to heinekingmedia the messenger aims especially at the use by
the police and authorities.
More information are available at
https://www.stashcat.com/
According to the web client website at
https://app.stashcat.com
we investigated version v0.0.80w
The investigated Android versions were the versions 1.5.18 and 1.7.5.
According to the installation file we investigated the version 0.0.86 of
the desktop client.
3. Description of vulnerabilities
=================================
The vulnerabilities were found during a half-day code review of the web
client. This was possible because the client is written in angular and
the client-side JavaScript code is directly available on
https://app.stashcat.com
The desktop client is build with Electron and is based on the web client
code for the base functionality.
We found vulnerabilities in the Android app via reverse engineering,
too. The finding from the code review of the web client were verified
through the reverse engineering if the protocol is affected.
The vulnerabilities have assigned CVEs. These are CVE-2017-11129 to
CVE-2017-11136.
CIPHRON has asked an independent third party, the Niedersachsen-CERT
(N-CERT), to verify the findings, what they did.
We gave heinekingmedia the change to comment the findings.
3.1 Communication decryptable through vendor
--------------------------------------------
CVE-2017-11136
One can see that the private key of the RSA-key pair, which is created
on the clients and is used to exchange passwords for symmetric
encryption of the communication channel, is transmitted to the
StashCat-server.
The password which is used to encrypt the private key are the first 32
bytes of the SHA512 hash of the user passsword. But this is transmitted
to the vendor server, too, as it is the login password.
This allows to decrypt the private key of StashCat users and therefore
the formaly encrypted communication channel for everyone which has
access to the vendor server because the password for the symmetric
encryption can be eavesdropped.
__Comment of heinekingmedia__
Passwords to secure the private key are now independent of the used
account password.
RSA keys are now 4096 bit in addition.
3.2 No key derivation function used
-----------------------------------
CVE-2017-11131
Instead of using a key deriviation function to create the password for
authentication, the user password is hashed directly with SHA512.
Moreover, only the first 32 bytes are used. State-of-the-art is to use a
key derivation function like PBKDF2 to generate from a source of low
entropy a password with high entropy.
Moreover, rainbow table attacks are mitigated through this
__Comment of heinekingmedia__
RSA-keys are encrypted according to PKCS#8. PBKDF2 is used internally.
3.3 Passwords generated with math.random()
------------------------------------------
CVE-2017-11133
The communication ist encrypted with AES in CBC-mode. The passwords to
encrypt the communication channel and the IV which are exchanged by the
communicating parties with RSA-key pairs are generated with math.random.
Newer versions are using CryptoJS.lib.WordArray.random() which uses
math.random() internal as well. This method ist not secure in a
cryptographic sense. Instead such generated passwords have to be treated
as deterministic what could lead to a compromise of the communication
channel.
__Comment of heinekingmedia__
Channel and conversation secrets are are no longer generated by
CryptoJS.
3.4 Integrity and authenticity not ensured
------------------------------------------
CVE-2017-11130
The integrity and authenticity of encrypted messages is not ensured.
This allows, for example, replay attacks in man-in-the-middle scenarios.
__Comment of heinekingmedia__
Responses created by the server are signed and can be verified by the
public key of the server.
3.5 Logout without authorisation
--------------------------------
CVE-2017-11135
Logouts of users can be done without authorisation because only the
device ID is needed.
__Comment of heinekingmedia__
The logout needs only the device_id. This is intentional and leads to
the deletion of of data on the logouted device.
This is by no means a vulnerability.
__Remark of CIPHRON__
From our point of view this can lead to a problem if an attacker could
enumerate all device IDs. This could be used for a denial of service
attack.
3.6 Android-keystore uses hard coded password
---------------------------------------------
CVE-2017-11129
The Android-keystore uses a hard coded password. This allows to read out
contained passwords through third parties which gained access to the
keystore.
__Comment of heinekingmedia__
A hard coded password is not used from now on.
The previously hard coded password for the Android-keystore is now
replaced by a randomly generated password. The password is created by a
random string of 32 characters which is generated by a secure random
method. The random string is stored in the shared preferences of Android
and is deleted with every logout. The stored random string is XORed with
the manufacture and model code of the device. The result is used as the
encryption key. From this the keystore password is derived in
conjuncture with the device ID.
3.7 No certificate pinning
--------------------------
CVE-2017-11132
The Android-app uses no certificate pinning. Instead, only the signature
of the Certificate Authority is checked. This eases man-in-the-middle
attacks.
Remark: This finding was fixed independently of the disclosure process
in Android-versions after 1.5.18.
__Comment of heinekingmedia__
All apps use certificate pinning or HPKP to complicate man-in-the-middle
attacks.
3.8 Login data in the logs
--------------------------
CVE-2017-11134
The Android-app saves login data in the logs what could help attackers
to gain access to this data.
__Comment of heinekingmedia__
In the case of exceptions the request was saved to the log on the
device.
The log entries are now cleared beforehand.
4. Solution
===========
heinekingmedia has accepted the findings and will distribute patches
successively which are already available.
5. Credits
==========
The code review and the reverse engineering was done by Karsten König of
CIPHRON. Sebastian Horzela and Lennart Henke supported.
The Niedersachen-CERT verified the findings of CIPHRON as an independent
party.
6. Greets
=========
Greets to the team of CIPHRON, especially Martin, Jan and Frithjof for
the good discussions and the good atmosphere in the office.
7. Timeline
===========
10.03.2017 Vendor contacted
15.03.2017 Second contact attempt because no response received
15.03.2017 Phone call with heinekingmedia
15.03.2017 Findings communicated
06.06.2017 Note that findings are solved
28.06.2017 Communication of the prepared advisory for coordination
11.07.2017 Advisory communicated to N-CERT because CIPHRON received no
response
17.07.2017 Coordination with heinekingmedia about further procedure
18.07.2017 Commentary of the vendor about the findings received by
heinekingmedia
19.07.2017 Remarks about the commentary communication to heinekingmedia
19.07.2017 Communication of the updated advisory draft including the
commentary
19.07.2017 Coordindation of the advisory publication
19.07.2017 Note that the findings will be fixed until the end of next
week
28.07.2017 Note that patches of the findings are ready
28.07.2017 Discussion of the patches
31.07.2017 Publication of the advisory
8. About CIPHRON
================
The CIPHRON GmbH was founded in 2003 and is a consultancy for
information security with its central office in Hannover, Germany. As a
consultancy for information security, CIPHRON does penetration tests,
code reviews and individual research about security topics.
More information are available at
http://ciphron.de
--
Karsten-Kai König, IT Security Consultant
CIPHRON GmbH
Tel.: +49 (5 11) 51 51 33 - 0 Fax: +49 (5 11) 51 51 33 - 29
Web: http://www.ciphron.de/ Support: +49 (5 11) 51 51 33 - 11
Ust.Id.: DE263362886 Geschäftsführer: Sebastian Horzela
Amtsgericht Hannover, HRB 203590Dear
_______________________________________________
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