This is the second installment in a series focusing on our 2023 State of SaaS Security report. The first post in the series is here.
Despite the frequency of breaches, attackers are fairly predictable. They’re opportunists. They’ll go to where valuable data and useful identities live. Today, more than ever, that leads them to SaaS applications. There are a number of ways SaaS breaches can occur. Here are a few of the most common we see:
Multi-factor Bypasses
Multi-factor authentication isn’t the silver bullet to preventing identity-based attacks it’s sometimes made out to be. More secure forms of MFA work well for securing human identities. The real world is messy, however.
Overlooked misconfigurations leave MFA disabled or unenforced. OAuth tokens grant access without authentication factors. Machine-to-machine SaaS connections can’t use MFA, as there are no humans to enter secondary factors. Same with service accounts. MFA bombing and SIM-swapping attacks have been successfully used to bypass less secure forms of MFA.
Info stealer malware steals authenticated SaaS sessions and sells them in marketplaces. No need for usernames, passwords, or 2FA tokens.
Example: CircleCI Breach
The CircleCI case was just one of many recent examples where session tokens were stolen from an engineer’s laptop by malware. ‘Information stealer’ malware is designed to scoop up credentials and session tokens, to be abused directly, or sold by initial access brokers on the black market.
In this particular case, an engineer’s 2FA-backed SSO session gave attackers access to generate access tokens to production CircleCI environments. This access led to the theft and abuse of GitHub OAuth tokens (SaaS-to-SaaS) belonging to CircleCI customers.
Since these session tokens are intended to be used transparently, without user intervention, MFA won’t slow an attacker down in this type of scenario. Looking at it another way, the attackers don’t necessarily need to defeat MFA if they can just go around it.
Unnoticed Platform Abuse
If an attacker created a new user account with administrator rights on your most critical SaaS platform, would you notice? What if someone was systematically downloading all customer data? What if privileges were escalated without reason or justification? Are SaaS services suddenly being used from a new location, or in a different way?
Sometimes logging isn’t enabled on these platforms. When it is, the logs often aren’t collected or reviewed. Even if events are reviewed, it’s possible for staff to miss critical events. Behavioral anomalies might create patterns only visible when analyzed at a larger scale.
Monitoring for platform abuse is difficult, particularly with hundreds of privileges, trust relationships between platforms and dozens or hundreds of SaaS applications in use.
Example: Okta/Sitel Breach
Just because the technology changes doesn’t mean attacker behavior needs to. Twenty years ago, attackers and penetration testers often found it necessary to create accounts. This could be to extend access in the compromised environment, pivot into another environment, or provide persistence - alternate means of accessing the target’s systems if the original intrusion points are closed off by defenders.
When Sitel, a third-party contractor with access to Okta customer data, was breached, the behaviors observed were classic adversary TTPs that go back decades. They occurred in a Microsoft 365, but this same story could be told in the early 2000s, in an on-prem Windows Active Directory environment. The attackers:
- Accessed credentials stored in plain text file
- Created new accounts
- Added new accounts to groups with Admin privileges
- Created mail forwarding rules to capture communications
These old techniques still work on modern SaaS platforms. Sadly, IT and security teams still miss them.
Stolen Trust
Adversaries know that one of the best ways to get past defenses is to look like a trusted party. After all, business grinds to a halt without some trusted relationships and paths in place. Compromise a trusted partner, service provider, or third-party vendor, and an attacker knows they can ride in undetected.
Exploits, stolen credentials, social engineering and other direct attacks are the more expected paths. The truth is that insider attacks, whether from an actual insider or someone that has taken over their identity are extremely common as well. This kind of attack can take many forms as well.
- A stolen OAuth key, sold on the black market
- Using a third party’s credentials to publish an app integration
- Stolen API keys and/or certificates
Example: The OiVaVoii Campaign
Threat intelligence has always been difficult to operationalize, but it becomes worthless when attacks come from a trusted, or benign source. In the OiVaVoii campaign, attackers leveraged compromised Microsoft 365 accounts to create malicious OAuth apps. These apps were then used effectively in social engineering attacks against other organizations.
This campaign resulted in the successful takeover of many C-level executives’ accounts, including CEOs, general managers, former board members and presidents. These accounts were presumably then used to further abuse privileges and launch social engineering attacks. The full impact is not publicly known.
Configuration Confusion
In the same vein as stolen trust, misconfigurations are also highly likely to lead to breaches or data loss. Some common causes for misconfigurations:
- Insecure default settings
- Confusing documentation
- Poor UI/UX
- Vulnerabilities in the SaaS product itself
- SaaS administrators with no IT or security experience
- Poor operational practices (overprioritizing convenience over security)
There can also be a fine line between a “vulnerability” in a SaaS platform and “working as intended, but the customer is using it wrong”. Who might be to blame is irrelevant when the outcome is the same, however.
Example: Leaky Salesforce Community Sites
When focused on malicious attacks, it’s sometimes easy to overlook the level of damage that can be caused by accidents. According to the Verizon 2023 Data Breach Investigations Report, roughly 10% of all breaches are caused by unintentional errors.
Much could be said about the impact of S3 bucket misconfigurations over the past decade, but more recently, Salesforce misconfigurations were making the headlines. Security researchers discovered numerous misconfigured Salesforce Community sites. As with S3 bucket snafus in the past, website admins assumed these sites were only accessible by authorized users. Unfortunately, the website data was accessible to anyone that knew of a method to exploit Salesforce’s overly permissive controls.
Check out the 2023 State of SaaS Security Report
These are just a few highlights from this year’s State of SaaS Security report from Valence Threat Labs! This blog series will continue to explore and share interesting insights from the report, but why wait? Check out the full report for more details and real-world examples of SaaS breaches now!
.jpg)
