Slack is a relatively new messaging platform commonly used in workplace communications, and also commonly used as a ChatOps bridge between monitoring systems and operations teams. Slack has become particularly popular as it enables direct messaging, internal company public forums (called channels), private limited channels, and shared channels for participation with external parties as well.
It’s extremely common to see Kubernetes-based applications leverage Slack in conjunction with monitoring tools such as Prometheus , AlertManager and many others, in order to send automatic alerts directly to users.
Slack is feature-rich, and offers additional functionality such as video calling, file sharing, and screen sharing, in addition to its large marketplace containing thousands of third-party applications and add-ons.
Many Slack integrations leverage Slack Incoming Webhooks in order to post these automatic messages from the applications directly to Slack. Message posting is done by specifying a unique URL, message body, and a destination channel.
Slack webhooks are considered a low-risk integration for the following reasons:
- Users select a target channel, which reduces the scope of possible abuse to a single channel.
- The unique webhook URL is secret and handled as such
- The webhook only accepts data, and thus on its own, it cannot expose sensitive data to third parties.
However, in her article A deeper dive into webhooks, Ashely Graves shows that this is not entirely accurate. As it turns out, it is possible to override the limitation of adding an app to a single channel by adding the “channel” key to the app’s JSON payload.
As part of the research, a GitHub scan revealed more than 130,000 public code results that contained Slack webhook URLs, most of them containing the full unique Slack Webhook value. In other words, 130,000 instances of different apps were discovered to be publicly exposing their channel webhook URLs. This opens a door for targeted phishing attacks.
In such a scenario, an attacker would take these leaked URLs, create a malicious Slack app and allow its public installation. Once installed, the attacker could then bombard the leaked webhooks with malicious messages, and track who installed the malicious application, using that information to exfiltrate their private data.
Detect Misplaced Slack Tokens and Slack Webhooks In Kubernetes Resources
Alcide sKan, available at github.com/alcideio/skan , can be used to detect both Slack tokens and Slack Webhooks in non-secret resources regardless of the Kubernetes application builders’ choice of deployment tools. Whether this is via Helm charts, Kustomized resources or plain Kubernetes resource files (YAML/JSON). Developers can use sKan as a command-line resource analysis tool, or integrate Alcide sKan as a CI pipeline step.
Additionally, the Alcide Advisor comes to serve the same purpose, identifying Slack Webhook leaks, but with a different implementation. Alcide Advisor, an API-driven Kubernetes configuration, security & risk scanner identifies those misplaced Slack webhooks as well as running many other checks either by scanning the cluster as the last step in a CD pipeline, allowing all the resource transformations to take place, or alternatively by running the scans periodically based on your configurations.
Whether secret consumption and secret life cycle management is done using Kubernetes Secrets or with the help of an out-of-cluster solution, deployment automation tools such as Helm Charts and Operators, if implemented wrong, could render secrets into insecure locations such as ConfigMaps or Pod environment variables. Teams must handle that risk by introducing security controls that offer the best safety and mitigation techniques against misconfiguration related risks. By integrating Alcide Advisor into your Kubernetes Cluster you can kill all birds with one stone and focus on delivering real, secure, value to your customers.