Shhlack, message encryption for Slack

A common problem about centralized messaging solutions is the sharing of sensitive information during day by day use, preserving, at the same time, message integrity and privacy.

Sometimes two parties may need to share some information that is confidential and should not be accessed by a third party.

A third party could be, for example:

• a service provider
• an external attacker
• a malicious operator of the platform

Conversations may be exposed to third parties, for example, in case of account compromise or by storing Slack backups insecurely.

How many users share passwords directly via Slack private messages?
I hope just a few, but the sad truth is... probably many.

 

Protecting Slack users Privacy after Policy Update

Scenarios are getting more complex after the introduction of GDPR and new Slack privacy policy.

Starting April 20, under the updated privacy policy, Slack compliance reports are being discontinued and the downloading options expanded. Those who buy the Plus plan can request access to “a self-service export tool” to download “all data from their workspace.” This includes “content from public and private channels and direct messages.”

And most important:

Automatic notices to employees will be discontinued. The employer will now decide whether users will be told their conversations are being exported.

Employers may decide to not inform users about conversation export; therefore company Slack users may not be informed of the export with a result of not being alerted of the potential data exposure.

Even if this feature could have its benefits, it could also be abused by a malicious third party to access conversations without alerting company users.


For more information regarding the analysis of Slack privacy policy update:

•  https://www.nbcnews.com/better/business/slack-updates-privacy-policy-employers-can-read-private-dms-without-ncna862811

Summing up the latter news and our previous concerns about centralized storage of sensitive information, we decided to create something on top of Slack in order to add per message encryption via pre shared keys, that's why Shhlack was created.

 Shhlack is an opensource tool available on GitHub:

• https://github.com/mindedsecurity/shhlack

Shhlack: Welcome to the era of encrypted Slack!

Shhlack is an extension for Slack and brings end-to-end encrypted messages in Slack workspaces.

Shhlack is available as

• Google Chrome Extension,
• Firefox Addon 
• Slack Standalone Patcher (Windows/MacOS/Linux).

Shhlack is not a Slack bot. Instead it injects itself in the Slack web UI and uses Slack internal client APIs to encrypt/decrypt messages on the fly by choosing a passphrase from a set of stored keys owned by the user using cryptojs.AES JS library.

When a user receives an encrypted message and owns the correct PSK, message will be shown as preformatted text:

On the other hand any user that receives the message but hasn't Shhlack installed or doesn't own the correct PSK, will see the content as a bunch of base64 encoded "garbage":

It supports the usage of multiple keys, meaning that a user can have more than one key that can be shared with other users.

At the moment Shhlack relies on pre-shared keys that need to be exchanged between users to get the ability to send and receive encrypted messages.

To facilitate PSK exchanging it is possible to import/export the keys as base64 encoded JSON object.

Creating Messages 

In order to create a new message click on the Shhlack icon near the message bar or press Alt+S and a dialog box will appear:

Then:

• To give Slack the opportunity to index some clear text data for future text based search it is possible to add a title that will be kept as clear text
• then the user can choose a particular PSK from the storage
• finally the super secret message can be written and sent.

NB:

Slack servers won't see anything in clear text, nor Slack Bots. Only users - and bots - owning the correct PSK will be able to get the unencrypted content.

Improvements and Future Expectations

If, as we hope, this project will get some traction from the public and a community will help us maintaining the code and add new features, there's a very exciting TODO list such as:

• Use of browser WebCrypto features to encrypt the PSK set on the client itself with a secret masterkey.
• Per channel encryption
• Improve message rendering features, encrypt snippets and releated
• Asymmetric message encryption via public/private certificates
• your feature request!

Enjoy Shhlack and experiment as much as you want!

We'll be looking forward to get your feedback.

DOM XSS in Google VRView library

While testing the VRView web application we discovered a DOM Based Cross-Site Scripting Vulnerability in the handling of errors through an inappropriate use of the "innerHTML" property. The use of this property must be combined with the encoding of the data before it is used for data assignment, and in this case it wasn't used safely.

Since the vulnerability also affects two of the most used Wordpress vrview plugins, an attacker could take control of the remote system that uses these plugins through a code analysis, or through automated tools.

Depending on the type of vulnerability and the role of the vulnerable component within the system, it can lead to trivial effects on the complete ownership of the server and the compromise of any data contained in it. The aspect to always keep in mind is that for the execution of the external components the principle of the minimum privilege is almost never applied.

About VRView

Vrview is a library developed by Google for embedding immersive media into traditional websites.

As described on the main website: https://developers.google.com/vr/concepts/vrview

VR view allows you to embed 360 degree VR media into websites on desktop and mobile, and native apps on Android and iOS. This technology is designed to enable developers of traditional apps to enhance the apps with immersive content. For example, VR view makes it easy for a travel app to provide viewers with an underwater scuba diving tour as they plan a vacation or for a home builder to take prospective buyers on a virtual walk-through before the home is built.

The Vulnerability

The vulnerability lies in the management of library errors, in fact, if it is specified through URL parameters: url or image, a nonexistent resource, the library returns an error including in the error message the resource specified in the request without executing the output encoding .



As can be seen from the code below, the user input data passed through the GET request parameters is passed to the "innerHTML" property without performing the parameter encoding output. In this way, an attacker can specify an XSS payload instead of the requested resource, the library will interpret the resource as non-existent and respond with an error indicating the XSS payload entered by the attacker, thus generating an arbitrary code execution Javascript.

The following shows the vulnerable code in the VRView library:

URL: https://github.com/googlevr/vrview/blob/master/src/embed/main.js

/* [...] */

function onSceneError(message) {
    showError('Loader: ' + message);
}

function onRenderError(message) {
    showError('Render: ' + message);
}

/* [...] */

function showError(message, opt_title) {
   // Hide loading indicator.
   loadIndicator.hide();

   var error = document.querySelector('#error');
   error.classList.add('visible');
   error.querySelector('.message').innerHTML = message;

   var title = (opt_title !== undefined ? opt_title : 'Error');
   error.querySelector('.title').innerHTML = title;
}

/* [...] */

Proof of Concept

The links below shows the vulnerability in real world example, the vulnerability includes other sub/domains that have not been mentioned such as "storage.googleapis.com".

URL: https://vr.google.com/earth/vrview/?url=%3Cimg%20src=x%20onerror=alert(document.domain)%3E

URL: http://googlevr.github.io/vrview/index.html?image=%3Cimg%20src=x%20onerror=alert(document.domain)%3E

Please note that the links above contains a patched version of the library.

Vulnerable Wordpress Plugins

Following are the two vulnerable Wordpress plugins found during the vulnerability analysis.

1) WP-VR-view - https://it.wordpress.org/plugins/wp-vr-view/

WP-VR-view is a plugin that allows you to display Photo Sphere images and 360 video on wordpress pages, posts, etc.
Website visitors will be able to navigate through your panoramas.
Smartphone users can use Google cardboard to look through in Virtual reality way.

Proof of Concept:
http://example.org/wordpress/wp-content/plugins/wp-vr-view/asset/?image=<img%20src=x%20onerror=alert(document.domain)>


2) VRView - https://it.wordpress.org/plugins/vrview/

VRView makes it easy to embedd Googles VRView into your WordPress installation.
Embed 360° Videos and VR Videos as Well as panorama photos into your WordPress-Installation.

Proof of Concept:
http://example.org/wordpress/wp-content/plugins/vrview/vrview/?image=<img%20src=x%20onerror=alert(document.domain)>

Please refer to section A9 of the OWASP Top 10 to check if the application makes use of external components, libraries, frameworks and dependencies from modules that are affected by known vulnerabilities:

A9 - Using Components with Known Vulnerabilities
https://www.owasp.org/index.php/Top_10_2017-A9-Using_Components_with_Known_Vulnerabilities

Disclosure Timeline

• 19-01-2017 – Report to Google Security Team;
• 20-01-2017 – Received a first feedback said that the report was triaged;
• 20-01-2017 – Received a second feedback said that the vulnerability exists;
• 14-02-2017 – Reply from Google Security Bot - The panel has decided to issue a reward of $3133,7;
• 16-03-2018 – The vulnerability was fixed (https://github.com/googlevr/vrview/pull/308);
• 23-04-2018 – Public disclosure.

Acknowledgement

Google VRP panel has decided to reward with a high reward as the vulnerability is included not only in sandboxed domains but also google.com.
Vulnerability Found and Reported by Federico Fazzi.