Who Hacked Slack? Security Risks in Business Applications

An unfortunate new frontier

Automated phishing attempts via a hijacked Slack app. Malicious applications in the Microsoft App Store. API keys leaked on the dark web. Welcome to cybersecurity’s newest front: your most vital business applications.

It’s only logical that malicious actors would intrude here next. Software as a service (SaaS) has gone from a fringe concept to the default within just over a decade. The SaaS market has grown 1,170%, from $13.4 billion in to $157 billion in just 12 years. The average organization now has 843 SaaS applications, and companies increasingly rely on them to house, enforce, deploy, and run their core operations.

But while most companies are thinking about how to expand their use of that software, few are thinking about the security vulnerabilities that come with it. Recent headlines are a good reminder: Everyone, including product owners, should be more vigilant.

In this guide, we’ll explore some of the biggest, unsecured threats in Salesforce, NetSuite, and Jira, your role in closing them, and how to continuously monitor the situation.
‍

‍

The SaaS app security gap

Today’s business applications are built to spread throughout your organization. They feature sharing widgets, free trials, and payment-free sign-ups designed to allow users to launch and integrate them quickly. Case in point, upon first sign-in, most applications today prompt new users to invite their team.

Many such third-party applications feature simple, one-click integrations which makes connecting them to Salesforce, NetSuite, or Jira, simple. But all this simplicity and reliance on end users to share with others creates a security gap.

‍

By definition, end users within the business are not concerned with security or compliance. They’re not thinking about potential phishing scams someone could run by hijacking an integrated third-party app, which has happened on Slack. And they aren’t supposed to be. These individuals are thinking about connecting things as quickly as possible to get their work done.

Users, and even administrators, are also accustomed to thinking of the top business systems as walled gardens safe from intrusion. Most assume that anything in the Microsoft App Store must be copacetic, and that integrations or invitations are reversible. But even a cursory analysis of these systems reveals serious issues.
‍‍

1. Salesforce users can “connect” an app without actually installing it. If they do this, they can use that app, but the information is logged under the user, not the application, which makes it much more difficult to track. It’s much more difficult to detect or investigate issues. (Salesforce documentation.)
2. If users disconnect and reconnect an app without deleting it first, it typically does not invalidate the old API key. If the key has been lost, leaked, or stolen, reinstalling the app doesn’t close the vulnerability. Furthermore, these old tokens are now concealed and inaccessible to the user via the interface, so the product owner may not even be aware they exist.
3. If a user installs an AppExchange app to Salesforce, then leaves the company, that app will probably remain installed. If that app emails important information to that individual’s personal email, it can be used to exfiltrate sensitive data.

Furthermore, no top business system is an island. Nearly all aspire to be “the” central platform around which a constellation of other integrated apps revolve, which makes them vast repositories of sensitive, shareable data. Potentially, with problematic third-party applications.

To date, companies like Google and Microsoft have done a generally good job of securing their own platforms, but not the ecosystem they operate within. And while Salesforce does provide this functionality via a product called Shield, this offering is generally understood to be prohibitively expensive, adding 40-50% onto the entire price of Salesforce. In the end, most companies are left without a complete view of whether their org has vulnerabilities or the tools to understand and remediate them.

‍
‍

Multi-factor authentication (MFA) is a start, but most API tokens and service accounts don’t feature MFA.

SaaS applications lack visibility into security gaps

How does the owner of a business system monitor all connections to and from their system?  Today most cannot, without serious custom coding. Companies tend to lack both macro visibility and micro visibility.

• Macro visibility is the ability for administrators to see what “shadow” SaaS services they have today. They know their top business systems, but very rarely have a full grasp of the connected third-party applications, or where API tokens are shared.
  
• Micro visibility is the ability to understand what each SaaS service does. What permissions does it have? What second-degree permissions does it have? (E.g. read-write access to a sales enablement tool that can sync, unchallenged, to Salesforce.) How does it communicate with other SaaS services? How does it behave? How has it behaved historically?
  ‍

Imagine all the endpoints of all your business systems, from tier 1 down to tier 10, and you have a sense of how many entry points malicious actors have.

‍

Without this visibility, it becomes exceedingly difficult for administrators to understand how that constellation of applications is behaving—and whether they’re missing important signals and malicious activity. This sort of visibility would have helped the following companies avoid the high-profile hacks they faced:
‍

A misconfiguration in the popular JIRA project management software exposed a great deal of data on hundreds of companies - Security Week
‍The project management tool Jira made a seemingly benign update to the system's permission defaults which inadvertently made dashboards, email IDs, project details, and more, public—for thousands of customers. Worse, these exposed URLs were crawled by Google, which is how a whistleblower found all this sensitive data.

Among those impacted were NASA, Google, Yahoo, Gojek, HipChat, Zendesk, Sapient, Dubsmash, Western Union, Lenovo, 1Password, Informatica, the United Nations, and the governments of Canada and Brazil.

‍A white-hat hacker stole IKEA’s Salesforce API token in just a few steps. - Medium
‍Most sales and customer success teams are trying hard to use Salesforce data and integrations throughout more of their systems—for example, capturing information from online forms to generate help tickets. But very few of those teams are considering that forms are exploitable endpoints. One bug hunter took a subdomain from IKEA’s social media posts, followed it back to a form, and attempted to upload a file which, predictably, gave an error. That error message revealed IKEA’s Salesforce API token.

Over 100,000 GitHub repos have leaked API or cryptographic keys - ZDNet
‍North Carolina State University scanned 13% of all public GitHub repos and found over 100,000 of them contained API keys and cryptographic tokens, which hackers can use to extract data from those respective systems.

‍
‍

‍

‍

Your responsibility in managing these threats

A big part of the trouble is that business systems are built to “land and expand” within your business. They actively encourage users to add others and integrate additional applications. But there are a few issues with this approach. One is that these systems are built with the tools to monitor themselves, or, in many instances, even allow system administrators to know what’s currently configured. And two, perhaps product owners shouldn’t also be responsible for security—it should be automatic.

Let’s explore the threats this creates in Salesforce, NetSuite, and Jira.
‍

Salesforce does not offer administrators one simple way to search through all configurations. Rather, administrators must either rely on its developer mode, which offers some DevOps features and some visibility, or search through the ever inelegant XML code. The result is if the security team asks a Salesforce administrator to audit all their present connected AppExchange apps, users, and extant API keys, there’s no simple way to do it. That friction obscures what’s happening in the system.

And anyway, should administrators be responsible for security? Again, we argue that it should be automatic.
‍

NetSuite also features what might be termed “observability gaps.” Its changelog doesn’t log all metadata of all changes by all users. Sometimes, it just logs that an action was taken by someone—without any details of what was done, or who did it. This is a stumbling block for any company seeking SOX compliance, which demands they log that data. Potentially, malicious actors who enter the system could make untraceable changes.
‍

Jira is similar to Salesforce in that there’s no easy way to understand what’s currently implemented. It can store sensitive information such as security bugs and information on customer escalations, yet you can’t natively search your entire configuration, nor easily tell which user has access to what information.

On top of this, Jira is a complex tool, and it’s bidirectionally integrated with other related systems such as Zendesk, Slack, Opsgenie, and PagerDuty, which makes the risk of a sensitive data leak even worse. And if you audit for configuration changes, in most cases, Jira will only tell you that a change was made for a certain configuration element, but no more detail than that.

So, the question becomes, how do you know if a configuration is malicious if you don’t even know what’s configured in the first place? Or, if you can’t compare a before-and-after view? Or, if you can’t revert to a prior configuration, to erase whatever compromise occurred?

And that’s really just the beginning, because that only covers what’s deployed in production. But what about all the data hosted in sandboxes, developers’ notes, and all manner of less secure testing environments? Many product owners use sandboxes to store copies of the actual product for tests, and while some systems like Salesforce can automatically redact some types of sensitive data, it’s no guarantee. The ability to observe what’s happening is a big missing key to patching your business system security.

So what’s a business engineer like yourself to do? For one, partner with your security team to ensure nobody ever hacks Slack—or Salesforce, or NetSuite, or Jira, or any of your company’s 843 SaaS business systems.

To confidently monitor systems, business engineers must be able to:

• Read and understand what’s currently implemented
  
• Document changes
  
• Maintain and control versions of your business applications
  
• Use multiple environments to develop and test
  
• Review change requests
  
• Manage releases
  
• Roll back changes
  
• Get alerts for important changes
  
• Document changes
  
• Search the configuration across all systems