CyberWire Daily - Click here to update your webhook. [Research Saturday]

Episode Date: June 20, 2020

Slack is a cloud-based messaging platform that is commonly used in workplace communications. Slack Incoming Webhooks allow you to post messages from your applications to Slack. Generally, Slack webhooks are considered a low risk integration. A deeper dive into webhooks shows that this is not entirely accurate.  Joining us in this week's Research Saturday is Ashley Graves from AT&T Cybersecurity's Alien Labs to discuss her research.  The research can be found here:  Slack phishing attacks using webhooks Learn more about your ad choices. Visit megaphone.fm/adchoices

You're listening to the Cyber Wire Network, powered by N2K. of you, I was concerned about my data being sold by data brokers. So I decided to try Delete.me. I have to say, Delete.me is a game changer. Within days of signing up, they started removing my personal information from hundreds of data brokers. I finally have peace of mind knowing my data privacy is protected. Delete.me's team does all the work for you with detailed reports so you know exactly what's been done. Take control of your data and keep your private life Thank you. JoinDeleteMe.com slash N2K and use promo code N2K at checkout. The only way to get 20% off is to go to JoinDeleteMe.com slash N2K and enter code N2K at checkout. That's JoinDeleteMe.com slash N2K, code N2K. Hello, everyone, and welcome to the CyberWire's Research Saturday.

I'm Dave Bittner, and this is our weekly conversation with researchers and analysts tracking down threats and vulnerabilities and solving some of the hard problems of protecting ourselves in a rapidly evolving cyberspace. Thanks for joining us. And now, a message from our sponsor, Zscaler, the leader in cloud security. Enterprises have spent billions of dollars on firewalls and VPNs, yet breaches continue to rise by an 18% year-over-year increase in ransomware attacks and a $75 million record payout in 2024. These traditional security tools expand your attack surface with public-facing IPs

that are exploited by bad actors more easily than ever with AI tools. It's time to rethink your security. Zscaler Zero Trust plus AI stops attackers by hiding your attack surface, making apps and IPs invisible, eliminating lateral movement, connecting users only to specific apps, not the entire network, continuously verifying every request based on identity and context. Simplifying security management with AI-powered automation. And detecting threats using AI to analyze over 500 billion daily transactions. Hackers can't attack what they can't see. Protect your organization with Zscaler Zero Trust and AI.

Learn more at zscaler.com slash security. Slack offers integration with third-party tools. Using OAuth, you can share different types of data between your Slack workspace and other users. That's Ashley Graves. She's a cloud security researcher at AT&T Alien Labs. The research we're discussing today is titled Slack Phishing Attacks Using Webhooks. Webhooks specifically are a type of Slack app that lets you post certain information to a channel. So given a secret URL, if someone knows that URL,

they can send a message to the channel using that. I see. And so the research that you've done here explores some potential vulnerabilities that come from that functionality. Yeah, I wouldn't categorize it as vulnerability. I would categorize it more as abuse of a feature. I see. Well, let's walk through it together.

Take us through what you've outlined here. How does this functionality work? Sure. So as I mentioned, there's two features that this uses. There's webhooks and there's third-party integration via OAuth. So basically, if users can send these messages to a Slack channel with the pseudo-secret URL, then they could, in theory, send a phishing message that is used to convince users to grant access to their Slack data using OAuth

or that thing that allows third-party integrations. Well, let's walk through this step-by-step. You lay it out here in the research here. Walk me through the steps here. Yeah, of course. First, on the victim's side, the victim has, say, created a webhook. So the victim knows the webhook URL. They may accidentally share that URL, whether it's posting it through GitHub or having it in a document that they shared by accident. So once this webhook is known by an attacker, that attacker can send a message containing a phishing link similar to how you would send a phishing link through email.

The unique thing about the second part of it is the third-party app integration. So instead of sending a link to, say, a phishing site that's asking for your credentials, you would send them the link to your third-party OAuth application. So this application would be built with the purpose of exfiltrating some data from Slack or somehow interacting with Slack. So for example, you might want to steal all the user's uploaded documents. You might want to access their chat. So if a user clicks this link and grants access to the third-party application, that third-party then has access to whatever data the application scopes define. Yeah, that's the part that really fascinates me here

because my understanding is that the webhooks functionality is designed to basically have data flow in one direction only to be used to be able to post things to a Slack channel. Is that correct? Yes, that's correct. And so how do we get from that functionality to the ability to exfiltrate data? It's the creation of this custom app? to the ability to exfiltrate data. It's the creation of this custom app? Yeah. So the webhook itself,

the only purpose of the webhook is to send that information in one direction, to send that malicious link to the victim's Slack workspace specifically. So once they click the link, from there on out, it is all this third-party OAuth application that is doing the heavy lifting. I see. And so one thing you outline here is a potential sort of formatting of that message,

making it look like it would be something that just in the course of their day, they probably wouldn't think twice about clicking on. How do you have that described here? Yeah. probably wouldn't think twice about clicking on. How do you have that described here? Yeah. So in this case, if someone already has a webhook set up and you have that webhook URL and you send a message to that URL, it'll use the webhook's name as they would normally see it. So if someone had an incoming webhook, in my example. It's just called incoming webhook. But so if you are already familiar with this application being in your channel, you might not think twice if there's an error that says click here to update your webhook. And maybe the person who owns it will click it.

That is the person who owns the original webhook. Maybe someone else will click it. It doesn't really matter as long as they fall for it. And so when they click on that, that's when the access tokens are exchanged. Can you sort of shed some light on that part of it? What happens next? Sure. So the tokens are obtained right that moment. First first the user, well, the potential victim will click on that URL. They will be prompted with an OAuth screen that basically requests a certain amount of access from them. So it'll say, for example, incoming webhooks needs to access your basic information. Incoming webhooks needs to message your private channel data, something like that.

And then the user can either reject that or accept it. If they do accept it, that is when the token exchange happens. The user will be none the wiser. They're sent back to their Slack workspace as normal, not to any phishing page, not to any obvious phishing page anyways. And from there, the token access is available. And one of the things you point out here is that that page that they're sent to, by all accounts, it looks like it comes directly

from Slack. Yes, that's like it comes directly from Slack. Yes, that's because it is directly from Slack. Right. So there's no indication that anything is amiss here. Right. The only indication that exists would be the person's gut feeling that it doesn't seem right, that this app should not be requesting this level of data. And so once the bad folks get the access token, I mean, that's the ballgame, right?

Then they have access to be able to exfiltrate data. Yes. Once the attacker has access to the access token, they can access that scope of data on behalf of the user until that token no longer works. And the user themselves would have no indication that this data was flowing out of their Slack instance, for example. That's correct. Wow. Well, let's talk about some of the mitigations here. I

mean, for folks who are using Slack, and that's a lot of people, how can they protect themselves against this? Well, there's kind of two sides of the coin here. Slack administrators need to take certain actions if they want to prevent this, and then end users need to have some responsibility or, well, some awareness around what type of risks are associated with Slack or at least third-party applications. On the administrator side, Slack offers something called application whitelisting. So users would not be able to add a new third-party app until an administrator is able to approve that app. And when the administrators get those requests, they will see the application name, some data around it, and what scopes of access the application is requesting. I see. And then on the user side, in terms of awareness, as you said, you know, that sense that something might not be quite right. What sort of tips do you have for them?

Yeah, for them, there's two things. Improved awareness around secrets handling. So I think some people legitimately don't understand how much access an attacker can gain when credentials are leaked. And even more so when a webhook secret is leaked. can gain when credentials are leaked, and even more so when a webhook secret is leaked. Because people, since this is a one-way communication, they don't see it as sensitive as, say, your AD credentials would be. The other side of it is understanding what you're giving third parties access to. So knowing to read those OAuth scopes, understanding how the application that you're using might use that access. Like it wouldn't make sense to me at least for a webhook to need access to my documents.

they have to look over and have some sort of understanding around whether it's some self-learning, whether it's included in security awareness training or something like that. Yeah, it really seems to me like this is one of those examples where you have that tension between the need for security, but also, you know, folks just want to get their work done. And there's that impulse when something like this pops up and it says, hey, I need your permission to access this, that, or the other. I guess there's a lot of people out there who would just say, well, I've got stuff to do. Yes, yes, yes. And they just click through. Yeah, absolutely. And I think you see similar things when it comes to the Cambridge Analytica issues with Facebook, the Google Docs phishing attack that happened in the past where there were some other issues at the core of Cambridge Analytica, of course. But there were a lot of people saying, oh, I never authorized that app.

I never authorized that access when realistically they did have to go through an OAuth prompt. They did have to allow access to their basic information using that app. And some of it is just clarity issues on the application side. Maybe those companies could have done a better job making it really obvious what kind of data you're handing over. But of course, at the end of the day, if you want these automation tools and these accessibility tools to work and integrate with your cloud platforms, you need to understand how they're interacting and what you're giving away. Yeah. Now, you have heard from Slack. They responded to your research. What was their reaction? Yeah, so they responded positively. They repeated most of the recommendations that we offer in the article, which is that you should look for

exposed webhooks and invalidate them, that Slack themselves proactively scrapes GitHub so that if they find webhooks there, they themselves will invalidate them. And also that Slack admins should do due diligence as far as whitelisting. Do you find the response adequate? I mean, is it a satisfying response? Do you feel as though Slack is stepping up here and doing what they can? response? Do you feel as though Slack is stepping up here and doing what they can? I'm happy with the response, and I appreciate that they allowed us to put out this research. I think that every company, including Slack, can still do better when it comes to explaining these issues. I highlighted a number of things that Slack did not directly respond to, such as the

ways that they could possibly improve this interaction. And again, this is something that a user has to fall for. The user has to take some sort of action. And I think that makes people think that an issue is less severe. But again, we've seen in similar attacks in the past that users can be easily tricked and that it's not stupidity. It's not even ignorance. to a lot of people, and the prompts are not always clear, and there's a lot of small text about how they work. So I think that companies need to, I suppose, make as much effort as possible to help people understand the impact of their actions. I think it's important to mitigate the scope of potential abuse. So in this example, webhooks being single channel only could help mitigate the potential damage done if someone does get access to a working webhook. Improving clarity around secrets handling and how important a secret is. And limiting access that unverified apps can have, such as scope or user limitations. So, for example, after the Google Docs phishing attack, Google limited the number

of users who could access a certain app if that app wasn't verified or trusted or went through validation in some way. So they also redid a lot of their OAuth prompts. So the clarity improved. So those type of things are something that only the vendor can do. Our thanks to Ashley Graves from AT&T Alien Labs for joining us. The research is titled Slack Phishing Attacks Using Webhooks. We'll have a link in the show notes. Cyber threats are evolving every second, and staying ahead is more than just a challenge.

It's a necessity. That's why we're thrilled to partner with ThreatLocker, Thank you. and ensuring your organization runs smoothly and securely. Visit ThreatLocker.com today to see how a default-deny approach can keep your company safe and compliant. The CyberWire Research Saturday is proudly produced in Maryland out of the startup studios of DataTribe, where they're co-building the next generation of cybersecurity teams and technologies. Our amazing CyberWire team is Elliot Peltzman, Puru Prakash, Stefan Vaziri, Kelsey Bond, Tim Nodar, Joe Kerrigan, Carol Terrio, Ben Yellen, Nick Valecki, Gina Johnson, Bennett Moe, Chris Russell, John Petrick, Jennifer Iben, Rick Howard, Peter Kilpie, and I'm Dave Bittner. Thanks for listening.