Exploiting Slack’s video embeds to achieve e2ee communication

Introduction

Some time ago, while exploring Slack’s Block Kit reference, I noticed something peculiar: the video block. When I saw that it accepted a video_url, the first thing I thought was: how does it distinguish between any content and an actual video? Would there be any particular requirement or limitation in the embed? Foreign sources?

Yeah, no. There is no runtime check, other than checking the provided video_url is accessible and responds with a 2xx or 3xx code. After those checks, it’s nothing more than a simple iframe.

So, a few days ago I got an idea. What if there was an app that allowed you to encrypt messages with a key pair and send them through Slack?

The idea is simple. Inside your client, using the browser crypto APIs, you create a key pair, encrypt the private key and send it to the server. Then, any time you want to do an operation (sign, encrypt, decrypt), the server will send you back your key and, inside a video block, you will decrypt your key and do the operation.

This way, the server never gets the decrypted key but via the key-pairs, you can encrypt messages for anyone.

Implementation

For this app’s development I chose TypeScript. For no other reason than that I’m used to it and I’m able to iterate fast with it.

During the implementation of the Slack app, I spent a decent amount of time until realizing that video blocks can not be included in ephemeral messages. This behavior is not documented anywhere.

Regarding the encryption, first, I tried writing all the encryption logic myself. Using the subtle crypto API from the browser (which is fully available in the Slack video block). Shortly I noticed how difficult that was. How many techniques and cases I would need to be aware of.

Fortunately, before suffering more, I found openpgpjs. An amazing library maintained by Proton (yes, the email people) that does all the cryptography operations I need.

I wanted the server to save as little data as possible by storing most of the data in slack metadata fields. I have already done this in honest-impressions (an anonymous stateless slack bot). All the slack messages or views may store a metadata field which is never shown in the client. Because of the length of encrypted messages, I wasn’t able to use this feature.

For serving the iframes, I ended up using a slug system. On each call that needs client interaction, a unique slug which holds the necessary data for the action to be done is stored in a KV db. When the video embed is loaded, this information is embedded with the client code so all cryptographic operations can be done locally

As an example, the flow for encrypting a message is simple:

1. First, the Slack command /e2ee send is executed. A Slack modal opens, requesting the recipients of the message.
2. After that modal is submitted, a slug is generated, containing: the author private key & the recipients public key.
3. When clicking on the video block inside Slack, the local-client is loaded with the above information.
4. The author decrypts their private key via his passphrase (locally).
5. The author writes the message, encrypts it for the recipients and signs it with his key (locally).
6. The author sends only the encrypted message.
7. The server sends envelopes to each one of the recipients of the message.

By the way, while developing this project, I discovered some of the wonders modern nodejs has to offer. Did you know node natively supports .env files now? I didn’t!

Result

You can check out the project right now, the source is at gh:v1ctorio/e2ee-slack. And self-host it for your slack workspace in ~5 minutes.

This project ends up being a hack since it doesn’t fully comply with Slack’s design constraints. But it kept me wondering. With all the flexibility that web technologies give us. Wouldn’t it be nice if major services supported fully-featured apps inside their client?

I mean, Discord already does something similar with ‘Activities’ or Telegram with ‘Mini Apps’. Wouldn’t it be interesting to see more mainstream services adopt this approach?