The Inside Story of Cloudflare’s Battle Against an Auth Token Breach and How It Could Have Been Prevented

Last October, Okta, the $1.8 billion identity and access management (IAM) giant, revealed that it had been targeted in a complex and multifaceted cybersecurity attack that exposed vulnerabilities in the company’s digital identity security. The attack highlights the risks associated with managing sensitive user data. It also demonstrates the necessity of robust digital SaaS identity security measures, along with the importance of rapid detection, communication, and response to those kinds of threats. This article looks at what happened, and how it could have been prevented.

First, to truly understand the Cloudflare breach, we need to see the timeline of events:

October 2023: Okta  Breach

Early October: Okta’s breach occurred, resulting in the compromise of various customer credentials, including those belonging to Cloudflare.

The breach began with an attack that exploited a stolen cookie from Okta’s support system, leading to unauthorized access to Okta’s support case management system. This system, separate from the main Okta service, is used for managing customer support tickets and related data, which includes sensitive HTTP Archive (HAR) files containing cookies and session tokens crucial for maintaining user sessions.

The breach led Okta to revoke session tokens embedded in shared HAR files, disable the compromised service account, and implement measures to prevent employees from signing into personal accounts on Okta-managed devices. These steps were part of Okta’s broader effort to enhance security and combat the threat of session token theft against administrators. Those crucial measurements can be performed through a centralized SaaS Security platform, such as Suridata.

October 18, 2023: Cloudflare’s Okta instance was specifically breached using the authentication token stolen from Okta’s support system, affecting files belonging to 134 customers, including Cloudflare.


November 2023: The Cloudflare Attack & Response

November 14, 2023: Attackers first gained unauthorized access to Cloudflare’s self-hosted Atlassian server, marking the beginning of the direct attack on Cloudflare.

November 22, 2023: The attackers established persistent access through ScriptRunner for Jira, accessing the source code management system, and attempting to access a console server linked to an undeveloped data center in São Paulo, Brazil.

November 23, 2023: Cloudflare detected malicious activity within its systems.


Post-Attack Actions

November 26, 2023: Cloudflare’s cybersecurity forensics team initiated a detailed investigation into the incident.

In the following weeks: Cloudflare undertook extensive remediation efforts, including credential rotation, system segmentation, forensic triage, and a comprehensive reboot of systems across its global network.

January 5, 2024: Formal remediation efforts were concluded, although Cloudflare maintains ongoing efforts in software hardening and security improvements.


Insights and Summary:

The Cloudflare breach was initiated through the exploitation of stolen authentication tokens and service account credentials from a prior Okta breach. Attackers targeted Cloudflare’s self-hosted Atlassian server, gaining unauthorized access to its Confluence, Jira, and Bitbucket systems. Despite the attackers’ efforts, the breach did not affect customer data or systems. Cloudflare undertook extensive remediation efforts, including credential rotation, to prevent future intrusions.


How Could have Suridata Prevented this Attack?

  1. The breach highlights the complex challenge of managing and securing authentication tokens and service account credentials in a landscape where sophisticated attackers continuously seek to exploit any vulnerabilities. Suridata protects tokens and API keys by proactively monitoring those digital assets, revoking their access, deleting them, setting expiration dates, granting specific scopes, and alerting for the need for rotation of tokens and credentials. In this case, Suridata could have detected the access permissions granted through the token, its usage, and who granted and used the token. Suridata could have then alerted the relevant admins or the security team regarding the suspicious activities and high-risk score, thus preventing the misuse of the tokens.
  2. Suridata, which integrates with critical systems such as Okta, Confluence, Jira, and Bitbucket, could offer substantial benefits in the early detection and mitigation of cybersecurity risks. Suridata’s capability to connect with these systems means it can continuously monitor for new risks, anomalies, or changes in user or token behavior, providing a proactive stance against potential security threats.
    This means that any unusual behavior or deviation from the norm, such as the misuse of authentication tokens or unexpected changes in user privileges, could be quickly identified. This level of surveillance is crucial for early detection of security incidents, potentially even before any data compromise occurs.

Conclusion

A breach of this magnitude is a serious problem for any business. For a company like Okta, whose brand is largely based on its reputation for guarding identity credentials, this breach proved to be a major embarrassment—and a significant distraction and resource drain in the remediation process. No system is ever completely bulletproof, but an examination of the attack chain suggests that certain countermeasures, such as those provided by Suridata, could have mitigated the threat.


Shiran Rachman

Product Lead

Back to list

Watch also