While experimenting with different tools for detecting hard-coded credentials, we noticed that some (like GitHub Advanced Security) point out Slack webhooks if they appear in code. At first, we mostly ignored those since they seemed like fairly low risk if any at all. Then, just for fun, we added the pattern to our own home-grown scanner:

https:\/\/hooks\.slack\.com\/services\/T[a-zA-Z0-9_]{8}\/B[a-zA-Z0-9_]{8,10}\/[a-zA-Z0-9_]{24}

It was immediately apparent that no one considered Slack webhooks to be sensitive information. So we got to thinking about whether or not they are.

Are Webhooks Secrets?

According to Slack’s own documentation:

Keep it secret, keep it safe. Your webhook URL contains a secret. Don’t share it online, including via public version control repositories. Slack actively searches out and revokes leaked secrets.

So Slack clearly states that they are secrets and should be protected.

What Damage Could Be Done With A Leaked Webhook?

What can you actually do with a webhook? The short answer is: You can post stuff. So they aren’t credentials protecting data. You can’t read any data or modify any existing data. All you can do is post a message in a specific channel from a specific robot user. In light of that, the first thought was, “Well it should probably be secret, but it’s still low risk”.

Let’s next imagine you’re a malicious user. What interesting things could you do with access to a webhook? The obvious first idea is to spam it. The outcome of that would be that real alerts or messages would be drowned out and go missed. But you’d likely be blocked pretty quickly.

Now imagine there’s a webhook being used for alerts that look like this:

Slack_Webhook_Security_PSA

What if a malicious user were to send the following request:

curl -X POST -H "Content-type: application/json" https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX -d '{
   "attachments":[
      {
         "fallback":"<!channel> There is an increase in lag of event consumption for topic : events.ReservationChanged",
         "pretext":"<!channel>",
         "title":"[Alerting] Kafka consumer lag",
         "title_link":"https://www.mymaliciouswebiste.com/blahblah",
         "text":"There is an increase in lag of event consumption for topic : events.ReservationChanged",
         "fields":[
            {
               "title":"events.ReservationChanged",
               "value":"781.95238095238",
               "short":false
            }
         ],
         "color":"#d63232",
         "footer":"Grafana v8.0.1 Today at 12:34 PM",
         "footer_icon":"https://slack-imgs.com/?c=1&o1=wi32.he32.si&url=https%3A%2F%2Fgrafana.com%2Fassets%2Fimg%2Ffav32.png"
      }
   ]
}'

The above request will result in a new alert being posted in Slack which looks exactly like the real one, however the link takes you to https://www.mymaliciouswebiste.com/blahblah instead of Grafana. All the malicious user would need to do from there is display a simple Grafana login page and wait.

Moral?

Slack webhooks are secrets which should be properly managed (injected at build or runtime). They need to be protected because, not only can leakage result in spam, but even more importantly, leaked webhooks open up a major phishing attack vector.

Hardcoded Slack Webhook Alerter

We have a simple tool that can be used to automatically scan all local code for hardcoded Slack webhooks, and for each one, send an alert to it to inform the team about the dangers of using hardcoded credentials. Check it out here: https://github.com/Sixt/hardcoded-slack-webhook-alerter.