Real Talk
One thing I appreciated about this talk is that Kelly and Nikki kept it real. Most blog posts, talks, other externally facing communications by companies who run marketplaces of third-party apps tend to frame things like, “Oh yeah, our marketplace is totally 110% secure, nothing bad could ever happen here.”
Of course it can! Random developers from around the world who you don’t know are writing code that extends your platform. Some of the developers could be malicious. Even the most advanced static and dynamic tooling in the world can’t with 100% accuracy identify all malicious applications, so unless you’ve solved the Halting Problem, there could be malicious apps you haven’t detected.
Kelly and Nikki are upfront about the security measures Slack is taking to secure the App Directory and the fundamental challenges in doing so. I find this openness admirable at it’s an approach I’d love to see more companies take.
Slack Apps and the App Directory
The Slack App Directory is a marketplace for users to download Slack “apps” that extend Slack’s functionality in some way, often by integrating third-party services like Dropbox, GitHub, and Jira, to create a central place where work can be done (i.e. Slack), rather than forcing people to use many disparate applications.
Slack doesn’t charge for Slack apps “and never plans to,” so they have no incentive to let poor quality apps in. Many Slack apps are the result of a partnership between Slack and third-party developers.
Currently humans review every Slack app (more details later), but subsequent versions are not re-reviewed unless their OAuth scopes (i.e. permissions) change.
The Slack App Directory vs. other similar marketplaces:
-
Mobile stores (e.g. Google Play, iOS App Store) – similar in that it’s third-party code, but Google and Apple are receiving the app’s code, the code lives on user devices, they vet new versions of apps, and they have significantly more analysis automation in place (big companies with the time and budget to do so).
-
Browser extensions (e.g. Chrome and Firefox extensions) – similar in that the creator can change a Slack app or browser extension at any time without it being vetted. Extensions tend to be more single purpose or have isolated functionality, while Slack apps often tie into an external web application or service that can present a much larger attack surface.
So to reiterate, Slack faces a number of challenges in securing Slack apps:
-
They don’t get a copy of the source code.
-
They have no ability to see version changes unless OAuth scopes change.
-
Apps are typically backed by large, complex web apps that again, Slack has no visibility into.
Who owns the risk for Slack apps?
Technically, legally, the risk belongs to the creators of the third-party apps and the users who choose to install the apps in their workplace. but Slack feels like they own they risk and have an obligation to keep their users safe.
Securing Slack Apps: Now
Apps are installed in test workspaces and undergo the following tests:
-
Scopes are checked to ensure they follow the principle of least privilege – do the requested scopes make sense given the purpose of the app?
-
The app is scanned with two internal automated tools that look for low hanging fruit like a weak TLS configuration.
-
A small set of apps, those with the riskiest set of scopes, are manually pen tested by the Slack product security team or third-party pen testers.
-
Slack apps are generally backed by web apps, so just because the Slack app itself appears safe doens’t mean the service is overall safe for users.
-
Slack apps change over time.
-
There are a number of security tests that are challenging to perform automatically, for example, many apps have different installation flows.
-
Slack’s ProdSec team is small and this is just one of many of their responsibilities.
Securing Slack Apps: Future Options
There are a number of other things Slack could do in the future, but none of them are perfect.
Pentesting: There are too many apps for the ProdSec team to pentest themselves, but they could pay a third-party to.
-
Who pays for it? This could be cost prohibitive for a small dev shop and isn’t cheap for Slack either.
-
Pentests give you a point in time view, and Slack apps can change at any time.
-
Should just the Slack app or also the backing web app be in scope?
Certifications: Which ones would be appropriate to require or use? In the speaker’s opinion (and mine), certs often don’t really mean anything. Certs are also point in time, how and when would apps get recertified? Certs cacn also be quite costly.
Hosting Slack Apps: Slack themselves could host Slack apps, which would give them visibility into when apps are updated and what action sthey’re performing. However, this would require a fair amount of infrastructure overhead cost Slack would have to take on and running untrusted code in Slack’s environment introduces additional risk.
Compliance-focused vendor review: Slack’s risk and compliance team already vets vendors they use by asking them questions about their security posture. Slack could leverage this team and process for Slack app developers. But what questions should they ask, and wouldn’t they just be taking developers at their word (i.e. not confirm actual security controls and posture)?
Bug bounty: If the company behind a Slack app already has a bug bounty program, they could include their app in scope, or Slack could include apps in their bug bounty’s scope. There’s some precedent for the latter, as Google Play has a program on Hacker One for certain popular apps.
Combined risk score: By borrowing parts from each of the prior ideas, each Slack app could be given an aggregate risk score. There are some UX challenges here, how can the risk score be made understandable and accessible to less security-saavy users? If users see an app is rated “C+,” will they be scared off from using the app? This could negatively impact the creators of some Slack apps, but perhaps this would encourage better practices and be a net win. Could having a risk score especially impact small dev shops?
Q&A
Slack is in the process of building some automated tooling to detect when an app starts doing something unexpected, like making many API calls that are exfiltrating data. Slack is also working on finer-grained scopes.
Slack has an internal kill switch for apps – if an app is misbehaving, they can quickly disable all existing tokens for it.
Slack is pretty aggressive about delisting apps – if an app isn’t working properly or they reach out to an app’s listed point of contact and they don’t respond relatively quickly, Slack will temporarily disable the app.
Slack has an evolving risk score used internally, and one of the inputs is the app’s requested scopes. Some scopes automatically jump an app right to the top of the risk scoring, for example, the admin scope, which enables an app to do anything an org admin can do.