Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Cloud

4/15/2020
03:15 PM
Connect Directly
Twitter
LinkedIn
Google+
RSS
E-Mail
100%
0%

Slack's Incoming Webhooks Can Be Weaponized in Phishing Attacks

Researchers report how attackers could weaponize a feature in the Slack collaboration platform to access corporate data and messages.

Security researchers exploring attack vectors in collaboration platform Slack have discovered a way its Incoming Webhooks could be leveraged to launch phishing attacks against employees.

Incoming Webhooks is a feature designed to give people an easy way to share messages from external applications in the Slack platform. Users can send a message to any webhook for which they know the URL, in any workspace, regardless of whether they're a member. Webhooks use normal HTTP requests with a JSON payload, which includes the message and optional details.

Slack webhooks are perceived as a low-risk integration because it's assumed the webhook configuration requires selecting a target channel to share a message, which would limit the scope of abuse to a single channel. It's also assumed the unique webhook URL is a secret and that the webhook only accepts data – and therefore couldn't expose sensitive data on its own.

"A deeper dive into webhooks shows that this is not entirely accurate," writes Ashley Graves, senior security researcher with AlienLabs at AT&T Cybersecurity, in a blog post on her research. Back in January, Graves had been working on a Slack application with webhooks when she realized they didn't work as she expected. This inspired her to take a deeper dive into the tool.

It's important to note Graves did not find a vulnerability in Slack itself; however, she did find subtle ways that attackers could abuse features in the platform to target unsuspecting users. 

For starters, she explains, attackers could override the webhook target channel by adding the "channel" key to their JSON payload. If they gain access to a webhook for one channel, Graves says, they can use the same webhook in others. This may prompt them to send a webhook to #general, #engineering, or another Slack channel likely to have a larger group of people in it. In some cases, this move could override a channel's posting permissions like admin-only posting.

Webhook URLs are considered secret; however, researchers found 130,989 public code results on GitHub containing these URLs. Most of them held the full unique webhook value, she notes.

There are a few reasons why an attacker would want to take advantage of Slack, which Graves points out "is used by a lot of enterprises." Discussions could contain a company's intellectual property, while uploaded files may hold confidential data. "A lot of sensitive discussions go on in Slack and there's the assumption only employees have knowledge of that," she explains in her post. With OAuth, someone could retrieve files and conversations, or send Slack messages of their own. 

How It Works
While data cannot be exposed via webhooks, an attacker can chain steps together to gain access to information and messaging capabilities in a workspace.

The process of launching this attack starts with discovering leaked webhooks, which can be found on GitHub. The next step is to create an app that can be publicly installed. Graves notes an attacker will need a Web server to handle OAuth flow. Slack apps don't require OAuth, but in her example she used Slack's API to access data in workspaces where the bad app is installed.

When users try to download the malicious application, they will be required to approve the requested OAuth scopes the attacker sets. These could be configured for any data they wish to access in Slack; as an example, Graves chose files:read to access a victim's files. Approval is sent to the OAuth client, which retrieves an access token from the authorization server. The token may be used to obtain data using the OAuth scope until authorization is revoked, she explains.

With the app ready, the next step is to message the #general channel linked to the webhook URL. An attacker could say something like "the webhook configuration needs to be updated" and include a malicious link, which would redirect the victim to install the app. The attacker will get a response from Slack with the access token and identifiers for the user and the user's team.

The access token will let an attacker access data on the user's behalf; however, this access is limited to the requester's access and the scope requested by the malicious application. There is no indication a user has interacted with a domain outside Slack. As a result, Graves cautions Slack users to be wary of apps requesting excessive access to files or messaging capabilities.

"It is not difficult to craft the attack," says Graves, noting she was able to do it within a couple of hours. Figuring out how to set up the OAuth client was tougher but still doable. "It's fairly trivial code to write, for someone experienced in reading and writing code," she continues. "What's more difficult to pull off … like all other phishing attacks, the user does have to be convinced to take action." An attacker won't succeed here without some user participation.

These findings were shared with Slack, which responded to say the tools were working as expected. While data cannot be exposed via webhooks, Slack advises workspace admins to invalidate publicly exposed webhook URLs and generate new ones. Slack scrapes GitHub for exposed webhooks to invalidate them so they can't be used in attacks like this one. "Webhooks are safe as long as they remain secret since the webhook URL itself is unguessable," it says.

For Slack admins in sensitive environments, Graves recommends application whitelisting so apps have to be reviewed and approved for downloading. If this isn't an option, they could detect suspicious Slack OAuth application that people are adding to the workspace.

Related Content:

A listing of free products and services compiled for Dark Reading by Omdia analysts to help meet the challenges of COVID-19. 

Kelly Sheridan is the Staff Editor at Dark Reading, where she focuses on cybersecurity news and analysis. She is a business technology journalist who previously reported for InformationWeek, where she covered Microsoft, and Insurance & Technology, where she covered financial ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
NSMKT
50%
50%
NSMKT,
User Rank: Apprentice
7/2/2020 | 1:36:53 PM
Cybersecurity
https://www.netsurion.com/catches/phishing-installs-locky-ransomware I found this one useful too.
COVID-19: Latest Security News & Commentary
Dark Reading Staff 7/9/2020
Omdia Research Launches Page on Dark Reading
Tim Wilson, Editor in Chief, Dark Reading 7/9/2020
Mobile App Fraud Jumped in Q1 as Attackers Pivot from Browsers
Jai Vijayan, Contributing Writer,  7/10/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Threat from the Internetand What Your Organization Can Do About It
The Threat from the Internetand What Your Organization Can Do About It
This report describes some of the latest attacks and threats emanating from the Internet, as well as advice and tips on how your organization can mitigate those threats before they affect your business. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-15105
PUBLISHED: 2020-07-10
Django Two-Factor Authentication before 1.12, stores the user's password in clear text in the user session (base64-encoded). The password is stored in the session when the user submits their username and password, and is removed once they complete authentication by entering a two-factor authenticati...
CVE-2020-11061
PUBLISHED: 2020-07-10
In Bareos Director less than or equal to 16.2.10, 17.2.9, 18.2.8, and 19.2.7, a heap overflow allows a malicious client to corrupt the director's memory via oversized digest strings sent during initialization of a verify job. Disabling verify jobs mitigates the problem. This issue is also patched in...
CVE-2020-4042
PUBLISHED: 2020-07-10
Bareos before version 19.2.8 and earlier allows a malicious client to communicate with the director without knowledge of the shared secret if the director allows client initiated connection and connects to the client itself. The malicious client can replay the Bareos director's cram-md5 challenge to...
CVE-2020-11081
PUBLISHED: 2020-07-10
osquery before version 4.4.0 enables a priviledge escalation vulnerability. If a Window system is configured with a PATH that contains a user-writable directory then a local user may write a zlib1.dll DLL, which osquery will attempt to load. Since osquery runs with elevated privileges this enables l...
CVE-2020-6114
PUBLISHED: 2020-07-10
An exploitable SQL injection vulnerability exists in the Admin Reports functionality of Glacies IceHRM v26.6.0.OS (Commit bb274de1751ffb9d09482fd2538f9950a94c510a) . A specially crafted HTTP request can cause SQL injection. An attacker can make an authenticated HTTP request to trigger this vulnerabi...