Stashcat
CWE 598 Use of GET Request Method With Sensitive Query Strings (aka CVE-2020-13129)
200517
Advisory for Stashcat CWE 598 Use of GET Request Method With Sensitive Query Strings
200518
Mitre assigns CVE-2020-13129
200519
NIST NVD publishes CVSSv2 Score of 9.0 HIGH and CVSSv3 Score of 7.2 HIGH
200520
The vendor has published his statement on the issue on his website for stashcat and the same statement for schul.cloud.
200527
Comment:
The vendor statement ignores basic attack vectors that are clearly described in the official CWE 598 definition extended description. It might help to read this basics! Arguing that a POST would not help in a man in the middle scenario is not wrong but it ignores all other described possibilities (e.g. log files, referer strings) where the information can pop up unintentionally.
The vendor's self estimate on the severity does not match the CVSS level that several independent organisations scored.
200615
Vendor published new version 3.10.0
CWE 359 Exposure of Private Personal Information to an Unauthorized Actor
200518
Advisory for Stashcat CWE 359 Exposure of Private Personal Information to an Unauthorized Actor did not qualify as CVE because CVE does not deal with issues in the API
200520
The vendor has published his statement on the issue on his website for stashcat and the same statement for schul.cloud
200527
Comment:
The vendor states that all transmitted information is essential to the function of the messenger. The API does not leak any information that the user is not authorized to access. To stop getting access to the email address of other users the vendor offers a hot fix.
The email is exactly what should not be transmitted to other users. It is not shown to the user in the user directory and it has no obvious function for the application. A user id is also transmitted, so no need for an email address. The statement with regards to the hotfix does not tell which functionallity impact will be included.
One might argue that stashcat is used by closed communities and the users use their respective organisational or company email adress, but an educated guess is that more than 50% of the users are using their private email address. This users are easy targets for fishing campaigns as they acutually expect system mails from stashcat on this email account.
200610
The vendor has published a new statement for schul.cloud that email adresses had been transmitted to other users and that this was supposed to happen only to admin accounts.
200616
Comment:
They state that during an internal audit they happened to find this issue on 10. June 2020 14:00 hrs. Bravo! On 2. May 2020 I informed them that emails are transmitted. They linked and commented on my advisory CWE 359 which is public since 18. May 2020. And it clearly states that email adresses are transmitted in the user list for all users. In the meantime the text of the statement for CWE 359 was changed. The text about a hotfix that will be installed on request to ensure that email adresses can not be accessed by other users was removed!!
CWE 312 Cleartext Storage of Sensitive Information (aka CVE-2020-13637)
200515
Vendor was informed
200527
Mitre assigns CVE-2020-13637
200527
Advisory for Stashcat CWE 312 Cleartext Storage of Sensitive Information
200615
Vendor published new version 3.10.0
The webclient has now a checkbox at login to select for the session id to be stored in the local (persistent) storage or the session storage of the browser.
200616
The vendor has published his statement on the issue on his website for stashcat and the same statement for schul.cloud