UPDATE — Jan. 5, 2023: Since the original publication of this article, Slack disclosed a similar source code breach. We’ve made several updates to reflect this news.
The attacks against SaaS providers have continued to increase in 2022, and recent breach disclosures by Okta (Dec. 21, 2022), LastPass (Dec. 22, 2022), and Slack (Dec. 31, 2022) represent more focused attacks on identity and credential providers. While these events may appear to be a series of attempts to expand access to systems via account takeovers, they also fall within the context of an advanced persistent threat (APT) against the IT infrastructure supply chain.
Both Okta and LastPass have been breached multiple times this year, and both companies have also had source code stolen. This is a continuing trend in supply chain source code theft. Targeted attacks against SaaS providers throughout 2022 include:
- March 7, 2022: Samsung source code stolen
- March 23, 2022: Microsoft source code stolen by Lapsus$
- April 15, 2022: Private GitHub repos compromised via stolen Heroku and Travis CI OAUTH tokens
- August 10, 2022: CloudFlare targeted in phishing attacks
- November 1, 2022: Dropbox source code stolen from GitHub
These attacks are only a subset of the escalating threats we’re seeing against SaaS solutions and their users.
What Attack Methods and Threats do SaaS Platforms Face?
To make matters worse, SaaS breaches have continued to increase with dozens of data breaches and leaks this year as well as compromises via “third-party vendors.” (Vague references to “third parties” in breach disclosures are often shorthand for SaaS platforms.) Further, third-party application plug-ins and OAuth connections via third parties seem to be a common attack vector in many of these breaches.
Security practitioners must understand that SaaS data breaches are not prolonged kill chain events. These attacks do not necessarily involve weaponization and exploits (although that could be a longer-term objective of the above source code thefts).
In many of these instances, the SaaS platform is misconfigured or accounts are compromised, data is exposed, and the data is taken. Therefore, focusing on the attack surface and configuration controls of SaaS environments and the access model is crucial.
What Can Organizations Do to Protect Their SaaS Data?
While this is hardly an exhaustive list, the following recommendations will help organizations respond to five major areas in the wake of these attacks.
1. For LastPass, assess configurations for enterprise deployments and mandate master password and mass credential rotation.
The basic sequence of events in the LastPass breach are:
- Source code was stolen via a compromised developer account.
- That information led to theft of customer information such as company names, end-user names, billing addresses, email addresses, telephone numbers, and the IP addresses from which vaults were accessed.
- Subsequently, encrypted password vaults were stolen from cloud storage via stolen keys from prior attacks. Password vaults contain website URLs in the clear, exposing more information to threat actors.
Our recommendations for affected LastPass customers include the following:
- Immediately change your master vault password to a complex password / passphrase of 14 characters or more. LastPass allows for passphrases up to 100 characters or more. (While LastPass mandates complexity of 12 characters and claims that would protect against brute force attacks for “millions of years,” current estimates offer a much lower timescale for passwords of that length.)
- Assume any contents of your vault can and will be decrypted. Cracking a master password is not a trivial task, but vault secrets should be considered compromised. That means mass credential rotation.
- LastPass enterprise customers should configure for Federated Login via SSO.
- Set MFA to mandatory.
- Audit re-use of passwords in vaults and reset passwords to critical systems.
- As website URLs in the stolen vaults are exposed, credential stuffing attacks with stolen credentials are likely. Organizations should monitor excessive failures and ensure that employees with detected stolen credentials in the dark web reset passwords.
- Rotate master passwords with a complex password in excess of 14 characters, in spite of assurances regarding security of the encrypted vaults.
2. Okta customers should assess configurations for enterprise deployments, and continuously monitor configuration changes and anomalous activity.
Okta provides an extensive set of security configurations and policies that can minimize exposure to account compromises and help control blast radius of ATOs. Recommendations include the following:
- Enforce mandatory MFA for all users.
- Enforce mandatory MFA on all applications.
- Mandate hardware keys such as a Titan Security Key or Yubikey as the MFA primary method.
- Assess configurations for network blocks and network zones and monitor for exceptions.
- Identify inactive users on applications and de-provision users.
- Monitor roles and groups for changes, exceptions, and new users.
- Assess conditional rules and monitor for changes and exceptions.
Exceptions in rules can be dangerous for your organization. For example, an admin could put an exception into MFA for their super admin account if they’re feeling lazy. Or an attacker could put an exception for a network zone for a country such as Belarus, for example. These are methods that threat actors may use to bypass controls in a SaaS application or gain privileged access.
If your organization doesn’t use LastPass, Okta, or Slack, these next steps are recommended for any companies that rely on SaaS.
3. “Really” enforce single sign-on (SSO) and multi-factor authentication (MFA).
When it comes to MFA, the details matter. There are different implementations that help prevent account takeovers (ATO) and compromise.
Beyond configuring your identity provider (IdP) and applications for SSO, many SaaS providers have an “optional” MFA setting. Ensure that this is configured to mandatory. We have encountered several instances where an organization has invested significantly in an IdP solution only to find months later that applications are bypassing the MFA requirement.
In addition, use MFA options such as a hardware key. In the August 2022 Cloudflare incident mentioned above, the attacks were unsuccessful due to the mandatory use of hardware keys at that company. Alternatively, opt for time-based, one-time passwords (TOTP) like Google or Microsoft Authenticator as a second factor.
Avoid the use of SMS as a second factor as there are known methods to compromise SMS channels. And finally, continue to educate your users on identifying MFA portals. Attackers continue to improve their sophistication (and spelling for that matter), and attacker in the middle portals are becoming harder to detect for casual users.
4. Assess and secure your software repositories.
Software repos such as GitHub can be monitored in several ways, and organizations should implement a set of best practices to minimize access and send alerts on misconfigurations. Below are some recommendations specific to GitHub, but they can be applied to other software repository solutions.
- Enable mandatory MFA to your software repos. This is currently NOT a mandatory requirement for GitHub, although it is targeted to be mandatory by the end of 2023. See these instructions on configuring 2FA for GitHub for more details.
- Assess repo settings and ensure they are set to “private.”
- Set alerts on repos getting modified to “public.”
- Assess third-party application integrations into GitHub.
- Assess OAuth usage and age of tokens, permission scopes of the integration, and users using specific third party apps.
- Set alerts for modifications to permissions groups, formation of new teams, and new users added to groups.
- Configure proper audit log streaming from GitHub. Many organizations may rely on webhooks for auditing, but this mechanism does not allow for the proper capture of audit events. See these instructions on configuring audit log streaming for more details.
- Monitor for “repo_clone” and “repo_download.zip” events in audit logs.
5. Assess third-party application plug-ins across your SaaS applications and consider a holistic approach to SaaS security assessment and continuous monitoring.
SaaS applications are here to stay. Organizations worldwide rely on them to run their businesses, and that reliance will continue to grow in the future. Businesses must make SaaS security a priority in order to responsibly manage their growing SaaS ecosystems.
Consider methods to operationalize the security monitoring of these applications, just as you would a traditional business application. By doing so, you will better understand where risks may exist, the scope of said risks, and how best to implement a mitigation strategy.
AppOmni is here to help. Get a free SaaS risk assessment.