Why core SaaS applications are still vulnerable to attack

Few organizations develop their own business applications anymore. Why bother? Off-the-shelf SaaS services are available for nearly every conceivable business function. According to BetterCloud, SaaS will consist of 85% of the software that organizations use by 2025. And the Netskope July 2021 Cloud and Threat Report found that organizations are currently using 805 SaaS applications on average.

Many organizations build extensive business processes around core SaaS applications such as Salesforce, Slack, Jira, Microsoft 365, GitHub, and Google Workspace. Workers can spend their entire day in a single SaaS platform. These core SaaS applications are valuable because they are extensible. SaaS vendors make it very easy to add additional capabilities and encourage their users to easily integrate third-party extensions into the original SaaS application to do even more. The Valence Security 2022 Shadow SaaS-to-SaaS Integration Report found that the average organization has 917 SaaS-to-SaaS third-party integrations, 4-5 times the amount estimated by CISOs.

Take Salesforce as an example. In its own right, businesses use Salesforce to build better relationships with their customers. But it’s made even more powerful when homegrown or third-party apps are “snapped in” like Lego pieces. The Salesforce AppExchange lists hundreds, perhaps thousands, of software products that tie directly into Salesforce and into customers’ private data repositories. These extensions cover categories such as finance, human resources, and marketing. It’s very little effort to add one of these third-party integrations to make the original CRM system so much more useful to the user organization. And most users can onboard a new third-party extension without any approvals.

Think of Salesforce as just one core SaaS platform with an extended ecosystem. The same goes for Microsoft 365, GitHub, Slack, and many others. But as useful as these extensions are, they are exactly what can make your SaaS application vulnerable to attack. 

Third-party applications can introduce risk

These core applications – those that act as the hub for all the add-ons – are inherently secure. Salesforce didn’t become a powerhouse by not investing heavily in security. Same for Microsoft, Google, GitHub, and many others.

The vulnerability comes in when third-party applications are not secure, or the API or automation workflow that allows the app to interact with the core SaaS application has not been created in a secure way. This can lead to a SaaS supply chain attack in which a bad actor exploits vulnerabilities or excessive permissions found in third-party add-ons.

 As an example for such a supply chain attack, dozens of customers of the code hosting platform GitHub had data exfiltrated from their private repositories after a threat actor used stolen OAuth app tokens issued to Heroku and Travis-CI to steal sensitive data such as roughly 100,000 accounts of the software registry npm. Even though no vulnerabilities were exploited in GitHub and the victims weren’t directly breached, their sensitive data stored on GitHub was stolen because of a third-party integration.

In another recent breach, companies mostly in the cryptocurrency and financial sectors were exploited via an attack on the Mailchimp SaaS application, which itself was breached through an internal tool. A Mailchimp spokesperson said threat actors gained access to API keys for an undisclosed number of the mail platform’s customers, allowing the attackers to potentially send spoofed emails and phishing campaigns from customer accounts.

 As these examples illustrate, an attacker can infiltrate many customer accounts by moving laterally within a mesh of integrated cloud applications. And they do it with virtual impunity because so few organizations consider the risk of letting third-party applications into their private SaaS instances and data.

How to protect a SaaS platform from supply chain attacks

The risk surface gets very broad in the SaaS supply chain. Most security teams have little to no visibility into the shadow OAuth apps, tokens, low-code/no-code workflows and APIs of these integrations. These connections take place in the cloud, outside of any security controls an organization has.

Even when CISOs are aware of their SaaS integrations, they tend to vastly underestimate how many connections exist. My company has polled a group of CISOs and on average they say their companies have up to 200 integrations. The true number is closer to 900, if not more. It’s not surprising given that anyone can add an integration through a SaaS marketplace or use a low-code/no-code workflow tool like Workato and Zapier to create one.

 Organizations wanting to close this attack surface and secure their SaaS applications need to follow the principles of discovery, monitor, and remediation.

Start by discovering what SaaS-to-SaaS connections exist, including each connection’s usage and privileges. Is an integration even used, or was it set up long ago and forgotten? Does the company have a legitimate business need to have the connection? Do the apps have excessive permissions into the core SaaS application? For example, an add-on to Salesforce may have just has access to basic customer information, when in fact it can access much more sensitive financial information. This excessive privilege is an opportunity for abuse.

The security team should engage with the SaaS app’s business users and stakeholders to understand the context of these add-on integrations. They are the users who should know why a third-party app gets used, and what data it needs to access. In many cases, business users evaluate 3-4 alternative solutions, chose one vendor, but never remove access to the unchosen alternatives.

 Having gained visibility and discovered the status of third-party apps, remediation comes next. This includes off-boarding unused and unneeded apps and restricting access for over-provisioned apps. Automation can help circulate notices to the business users and stakeholders to get their input or action to resolve issues. This offsets the effort of remediation by pulling the end user into the process and letting them off-board their own apps. Moreover, it avoids having the security team do a blanket shut-down of apps that results in blocking legitimate business needs.

Finally, continuously monitor new and existing integrations to ensure they don’t pose a risk in the SaaS ecosystem. As a computing model, SaaS has gone mainstream. Organizations must recognize the inherent risk surface with SaaS and implement the security controls that minimize risk while enhancing business operations.

Yoni Shohet, co-founder and CEO, Valence Security