Cloudflare revealed that its internal Atlassian server experienced a breach perpetrated by a suspected 'nation-state attacker', resulting in unauthorized access to its Confluence wiki, Jira bug database, and Bitbucket source code management system.

The threat actor initially infiltrated Cloudflare's self-hosted Atlassian server on November 14, proceeding to gain entry into the company's Confluence and Jira systems after conducting a reconnaissance phase.

Cloudflare Hacked: What Happened?

In November, Cloudflare encountered a security breach, allowing attackers persistent access to their Atlassian server and source code management system. Leveraging stolen access tokens and service account credentials from a previous Okta breach, the attackers attempted unauthorized entry into Cloudflare's infrastructure, including a data center in São Paulo. Cloudflare swiftly identified and contained the breach, conducting thorough forensic analysis, rotating over 5,000 production credentials, and reimagining compromised systems.

Who was affected?

Cloudflare was the main victim of the breach, which involved unauthorized access to their Atlassian server, Confluence, and Jira systems.

Were the customers affected?

According to Cloudflare, the breach had no impact on customer data, systems, services, global network systems, or configuration.

Role of Access Token

An access token is a security token that is used to authenticate and authorize access to protected resources. When a client application wants to access an API, it first needs to obtain an access token from the API provider. This token is then included in the API requests to prove the client's identity and permissions.

An authorization server typically issues access tokens and have an expiration time. They are used in authorization protocols like OAuth and provide a secure way for clients to access resources on behalf of a user without exposing their credentials.

The attacker in the Cloudflare breach exploited old access tokens obtained from a previous Okta breach. In this case, the attacker leveraged stolen access tokens and service account credentials to gain unauthorized entry into Cloudflare's infrastructure. By using these tokens, the attacker was able to bypass authentication mechanisms and gain persistent access to Cloudflare's Atlassian server and source code management system.

Why did it happen?

To understand why it happened, you need to understand credential rotations. Rotating credentials refers to the process of regularly changing or updating the access credentials used to authenticate and authorize access to a system or service. This is done as a security measure to mitigate the risk of unauthorized access in case credentials are compromised. By frequently rotating credentials, organizations ensure that even if a credential is stolen or leaked, it becomes invalid after a certain period of time. This reduces the window of opportunity for attackers to exploit it.

In Cloudflare's case, they made a mistake by not rotating the credentials, which allowed the attacker to use credentials from the Okta breach in Cloudflare's systems leading to another breach.

Here's how you can perform credential rotation for your organization:

1. Identify Credentials: Determine which credentials need updating, such as passwords, API keys, or access tokens.

2. Generate New Credentials: Create new credentials to replace the old ones.

3. Update Systems: Apply the new credentials to relevant systems and applications. For example, create new passwords for user accounts or generate new API keys for accessing services.

4. Enforcing Access Controls: Implement access controls to ensure only authorized individuals or systems have access to the new credentials. This may include role-based access control, multi-factor authentication, or other security measures.

5. Repeat Regularly: Maintain a regular schedule for this process to stay ahead of potential security threats.

Cloudflare Response

“Even though we understand the operational impact of the incident to be extremely limited, we took this incident very seriously because a threat actor had used stolen credentials to get access to our Atlassian server and accessed some documentation and a limited amount of source code," said Prince, Graham-Cumming, and Bourzikas.