Cloudflare Hacked Following Okta Compromise

Originally published by Valence Security.

Cloudflare disclosed that the Okta breach that occurred several months ago led to a suspected ‘nation state attacker’ gaining unauthorized access to their Atlassian servers. According to Cloudflare, the attackers that gained their initial access due to the Okta compromise back in October, were able to leverage a service token and service account credentials to access Cloudflare’s Atlassian servers. This exposed Cloudflare’s sensitive data such as Jira tickets, wiki pages, source code, and potentially more data sources.

This breach disclosure comes several days after Microsoft published a recent incident that led to unauthorized access to their corporate email by Russian state-sponsored threat actor Midnight Blizzard (also known as NOBELIUM or APT29). Even though the source of the breach is significantly different, the attackers used similar techniques that leveraged human and non-human identities to build their attack vector. The number of incidents that involve SaaS applications and their identities have skyrocketed in 2023 and seems like this trend is continuing into 2024.

What do you need to know?

• Back in October 2023, Cloudflare shared that it was breached due the Okta compromise
• Following the Okta compromise, the Cloudflare security performed an in depth forensics analysis and rotation of more than 5,000 production credentials
• Unfortunately, the team missed 4 credentials of a service token and service accounts that belong to SaaS applications and other services
• Almost a month after the original breach, the threat actor used these credentials to gain access to the Cloudflare servers
• The attackers were able to access Jira tickets, wiki pages, source code and other data
• The attackers then established persistency by making administrative changes in Cloudflare’s environment
• One of these changes triggered an alert that initiated an investigation by the Cloudflare security team that remediated the threat

‍Non-human identities and where to miss them

Following the Okta compromise, the Cloudflare security team assumed the attackers had limited access, but was extra cautious regarding the potential blast radius of that breach. The team rotated more than 5,000 production credentials and performed in depth forensic analysis of their systems. The team missed during the credential rotation one service token and three service accounts that were leaked during the Okta breach. These credentials weren’t rotated because they were assumed to be unused. It’s unfortunate, but in this case it was enough to miss 4 out of more than 5,000 credentials to lead to this breach - every credential counts!

In our 2023 SaaS Security Report we reported that on average, over half (51%) of an organization’s SaaS third-party integrations are inactive. In most cases, security teams assume the inactivity means no risk - this is obviously not the case. In many cases non-human identity tokens that are inactive or even were never used in the past, are still stored somewhere. It doesn’t matter whether it’s in your internal systems or a third-party vendor’s systems - if they fall in the hands of a bad actor, they can use them to gain unauthorized access to your environment. The rule of thumb here should be simple - if it’s inactive and not needed - revoke it, don’t take the chances.

‍It’s all connected - the interconnectivity of business applications

Once the attackers had access to these credentials, they were able to leverage the Moveworks service token to authenticate through the Cloudflare gateway and into their internal systems. From there, the attackers leveraged a service account credential that was granted to allow the SaaS application Smartsheet to have administrative access to Cloudflare’s Atlassian. The attackers were able to access Jira tickets and wiki pages hosted on the Atlassian server. This exposed sensitive information about Cloudflare’s internal security practices such as secret rotation, MFA bypass, network access, password resets, remote access, and more.

Valence has been referring to the risks of business applications or SaaS applications interconnectivity for many years. API keys, non-human identities, OAuth tokens, SaaS-to-SaaS, service account, third-party apps, no/low-code automation workflows, and many other integration forms are leveraged by organizations to increase productivity and automate their day-to-day tasks. These integrations are typically not treated with the same security measures that human identities have. For example, you can’t enforce MFA or SSO or any form of strong authentication on a non-human. In addition, enforcing least privilege access is difficult due to complex relationships with other identities and lack of data from the business application vendors. Lastly, monitoring activities and detecting anomalous activities is challenging due to the amount of actions these integrations perform and the lack of proper data collection. Managing the relationships between your business applications is critical more than ever in our modern hyper-automated enterprise.

‍Beyond non-human identities - the need for holistic risk management

The attackers didn’t stop with Jira tickets and wiki pages. They knew that they needed to establish persistence that would allow them to continue their attack effort even if the credentials they originally used were no longer available or valid. The attackers leveraged the Smartsheet service account to create a new Atlassian account that mimicked a regular Cloudflare user and added it to several Atlassian groups. The attackers then leveraged a Jira plugin to install a command and control tool to ensure they kept their connectivity to the Atlassian server. This allowed them to attempt to further move laterally within the Cloudflare environment, access Atlassian Bitbucket sources code repositories, and more. Eventually the attackers added the Smartsheet service account to an administrator group which triggered the Cloudflare security team, initiated the investigation and incident response, and eventually led to removal of all the threat actor’s access.

Even though this breach involves a combination of SaaS and on prem business applications, it shows the importance of managing holistic risks when it comes to these applications. The attackers leveraged non-human identities to gain access to sensitive data, create new human accounts and make high privilege administrative configuration changes to gain access to sensitive applications and move laterally within the enterprise environment. These types of breaches require security teams to gain an understanding of their various resources within applications and to ensure they contextualize their posture management and threat detection efforts with the required information. Connecting between the dots of all related configurations, risks and changes is crucial to properly prepare for a potential breach and to effectively respond in case of a breach.